# CommandSection

title: DESCRIPTION
content:
The <b>grub-render-label</b> command is a utility provided by the GRUB (GRand Unified Bootloader) suite. Its primary function is to render a given text string, typically a label intended for a GRUB boot menu entry, into an image file. This is particularly useful for creating custom graphical boot menus where text labels need to be displayed as part of a background image or as standalone graphical elements.<br><br>The command allows for extensive customization of the rendered text, including font selection, font size, foreground and background colors, and the dimensions of the output image. It supports various image formats, making it versatile for integration into different GRUB theme designs. Essentially, it transforms textual boot menu descriptions into visually appealing graphical components.


title: CAVEATS
content:
<ul><li><I>Font Availability:</I> The specified font file must be accessible and readable by the command. Incorrect font paths or unsupported font types will lead to errors.</li><li><I>Image Format Support:</I> The range of supported output image formats depends on the GRUB build and its underlying library dependencies (e.g., FreeType, ImageMagick).</li><li><I>Transparency:</I> Transparent backgrounds (<I>--bgcolor=transparent</I>) are only effective if the chosen output format (e.g., PNG) supports alpha channels. Other formats might render a solid background color.</li><li><I>Text Wrapping:</I> The <I>--wrap</I> option works best when <I>--width</I> is specified, as it helps determine the maximum line length for wrapping.</li></ul>


title: USAGE IN GRUB THEMES
content:
This command is primarily used by GRUB theme designers or scripts that automate theme creation. It allows for the dynamic generation of graphical text labels for boot menu entries, which can then be overlaid onto background images or used as standalone menu items, enhancing the visual appeal and customization options of the bootloader interface.


title: INPUT TEXT CONSIDERATIONS
content:
The <I>TEXT</I> argument can be a simple string. If the text contains spaces or special characters, it should be enclosed in quotes to be treated as a single argument. Newlines (<I>\n</I>) within the input text can be used to render multi-line labels, especially when combined with the <I>--wrap</I> option.


title: HISTORY
content:
The <b>grub-render-label</b> command emerged as part of GRUB's evolution towards more sophisticated and customizable graphical boot menus, particularly with the advent of GRUB 2. As GRUB themes became more prevalent, there was a need for utilities to dynamically generate graphical elements like menu labels from plain text. This command facilitates the creation of visually integrated boot screens by allowing theme designers to render text directly into image formats that can then be used within a GRUB theme's visual assets, simplifying the process of updating text content without manual image editing.


title: PARAMETERS
content:
<b><b>FILE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the GRUB script file to be checked for syntax errors. This parameter is mandatory.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and then exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <b>grub-script-check</b> utility and then exits.<br><br>


title: DESCRIPTION
content:
The <b>grub-script-check</b> command is a vital utility within the GRUB2 bootloader suite, specifically designed to parse and validate GRUB configuration scripts. Its primary function is to inspect a given GRUB script file (commonly <b>grub.cfg</b> or custom configuration snippets) for syntax errors, malformed commands, and adherence to the GRUB scripting language rules. This tool is exceptionally useful for debugging GRUB configuration issues <I>before</I> attempting a reboot, thereby mitigating the risk of an unbootable system due to a faulty bootloader configuration. When executed, <b>grub-script-check</b> will report any detected errors, often pinpointing the exact line number where the issue lies, which significantly aids administrators in identifying and correcting mistakes in their GRUB setup. It acts as a static analysis tool for your GRUB boot configuration.


title: CAVEATS
content:
While <b>grub-script-check</b> is excellent for syntax validation, it does <I>not</I> perform a logical or runtime check. A script can be syntactically perfect but still cause issues at boot time if the logic is flawed or if it refers to non-existent devices/paths. It also doesn't simulate the full boot environment, so some issues related to specific modules or hardware detection might not be caught. Always test critical GRUB changes in a virtual machine or a non-production environment first.


title: USAGE IN AUTOMATION
content:
The command returns an exit status of 0 if no syntax errors are found, and a non-zero value if errors are detected. This makes it ideal for use in automated scripts and continuous integration pipelines to validate GRUB configuration files before deployment or system updates.<br><br>Example: <b>grub-script-check /boot/grub/grub.cfg && echo 'GRUB config is OK' || echo 'GRUB config has errors!'</b>


title: ERROR REPORTING
content:
When errors are found, <b>grub-script-check</b> typically outputs diagnostic messages to standard error (stderr), indicating the file name, line number, and a description of the syntax error, which is extremely helpful for pinpointing and fixing issues.


title: HISTORY
content:
The <b>grub-script-check</b> command emerged as an essential component with the development of GRUB2. Unlike its predecessor, GRUB Legacy, GRUB2 introduced a significantly more powerful and intricate scripting language for its configuration (<b>grub.cfg</b>). This complexity necessitated a dedicated tool for validating script syntax. Its inclusion reflects the GRUB2 project's commitment to providing robust and manageable bootloader configurations, allowing system administrators to debug configuration files proactively rather than reactively during a critical boot sequence.


title: PARAMETERS
content:
<b><I>entry</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target boot entry to set as the default. This can be:<br>1.  A <b>zero-based numeric index</b> corresponding to the position of the entry in the GRUB boot menu (e.g., <code>0</code> for the first entry).<br>2.  A <b>full title string</b> of the entry as it appears in the GRUB boot menu (e.g., <code>"Ubuntu, with Linux 5.15.0-78-generic"</code>). Enclose titles with spaces in quotes.<br>3.  The special keyword <code><b>saved</b></code>, which instructs GRUB to remember the last manually selected entry and use it as the default for subsequent boots. This requires <code>GRUB_DEFAULT=saved</code> to be set in <code>/etc/default/grub</code>, which this command can facilitate.<br><br>


title: DESCRIPTION
content:
<code>grub-set-default</code> is a utility used to persistently change the default operating system or kernel entry that GRUB (Grand Unified Bootloader) will boot into. Unlike <code>grub-reboot</code>, which sets a default for the <i>next</i> boot only, <code>grub-set-default</code> modifies the <code>GRUB_DEFAULT</code> variable in the <code>/etc/default/grub</code> configuration file. This change ensures that the specified entry becomes the permanent default choice for all subsequent reboots until it is changed again. After using <code>grub-set-default</code>, it is crucial to run <code>update-grub</code> (or <code>grub-mkconfig -o /boot/grub/grub.cfg</code>) to generate a new <code>grub.cfg</code> file that incorporates the modified <code>GRUB_DEFAULT</code> value. This command is particularly useful for users who frequently switch between multiple operating systems or different kernel versions and wish to set a specific one as their primary boot option. The argument can be a zero-based index of the desired entry, a full title string of the entry as it appears in the GRUB menu, or the special value "saved" to use the last chosen entry.


title: CAVEATS
content:
<ul><li>Changes made by <code>grub-set-default</code> are <b>not effective immediately</b>. You must run <code><b>update-grub</b></code> (or <code>grub-mkconfig -o /boot/grub/grub.cfg</code>) after executing this command to generate a new GRUB configuration file and apply the changes.</li><li>This command <b>requires root privileges</b> to modify the <code>/etc/default/grub</code> file.</li><li>If you set the default to <code><b>saved</b></code>, GRUB will remember the last chosen entry. However, to <i>change</i> that saved entry without rebooting, you would typically use <code>grub-editenv</code> (e.g., <code>grub-editenv set default <I>index_or_title</I></code>). <code>grub-set-default</code> sets the <i>initial</i> or <i>fallback</i> default in the configuration file.</li></ul>


title: HOW IT WORKS:
content:
The <code>grub-set-default</code> script primarily modifies the <code>GRUB_DEFAULT</code> line within the <code>/etc/default/grub</code> file. For example, if you run <code>grub-set-default 1</code>, it changes the line from <code>GRUB_DEFAULT=0</code> to <code>GRUB_DEFAULT=1</code> (or similar). This file is then read by <code>update-grub</code> to generate the final <code>/boot/grub/grub.cfg</code> configuration.


title: EXAMPLES:
content:
<ul><li>To set the first entry in your GRUB menu as the default:<pre>sudo grub-set-default 0</pre></li><li>To set a specific operating system by its title as the default:<pre>sudo grub-set-default "Ubuntu, with Linux 5.15.0-78-generic"</pre></li><li>To make GRUB remember the last manually selected entry as the default:<pre>sudo grub-set-default saved</pre></li><li>After any of the above, always run:<pre>sudo update-grub</pre></li></ul>


title: HISTORY
content:
The <code>grub-set-default</code> command, as a distinct utility, became prominent with the advent of GRUB2. While the concept of a default boot entry existed in GRUB Legacy, GRUB2's modular configuration and the introduction of <code>/etc/default/grub</code> as a central point for user-defined variables led to the creation of helper scripts like this. Its purpose is to simplify the modification of the <code>GRUB_DEFAULT</code> variable, abstracting away the direct editing of configuration files for users, and ensuring the change is persisted across reboots by modifying the primary GRUB configuration source.


title: PARAMETERS
content:
<b>--output=FILE, -o FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the generated GRUB configuration to <i>FILE</i> instead of standard output.<br><br><b>--prefix=DIR, -p DIR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the GRUB prefix directory for the generated configuration.<br><br><b>--root=DIR, -r DIR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the root directory for the generated configuration.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print verbose messages during the conversion process.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print detailed debug messages, useful for troubleshooting.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>SYSCONFIG</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the Syslinux configuration file to convert. If omitted, the command reads from standard input.<br><br>


title: DESCRIPTION
content:
<i>grub-syslinux2cfg</i> is a utility designed to convert a Syslinux configuration file into a GRUB configuration file. This tool is particularly useful for users migrating from a Syslinux-based bootloader setup to GRUB, or for environments where dual-booting with previously Syslinux-configured systems is required. It parses Syslinux entries, such as those defined by <i>LABEL</i> and <i>MENU LABEL</i>, and attempts to translate them into equivalent GRUB menu entries. While it aims to facilitate the transition, users should be aware that it is an <b>experimental</b> command and may not support the full spectrum of Syslinux features or configurations. The converted output is typically sent to standard output unless an output file is specified.


title: CAVEATS
content:
This command is <b>highly experimental</b> and does not support all features of Syslinux. It should be used with <b>caution</b>, and the generated GRUB configuration should be reviewed and tested thoroughly before deployment.


title: USAGE EXAMPLE
content:
To convert a Syslinux configuration file named <i>syslinux.cfg</i> and save the output to <i>grub.cfg</i>, you would use: <br><code>grub-syslinux2cfg syslinux.cfg -o grub.cfg</code><br>This command can also be piped input, for example: <br><code>cat syslinux.cfg | grub-syslinux2cfg -o grub.cfg</code>


title: HISTORY
content:
<i>grub-syslinux2cfg</i> emerged as part of the GRUB project to assist in the migration and interoperability between different bootloader systems. Its inclusion reflects the GRUB developers' effort to provide tools for transitioning from other bootloaders, such as Syslinux, which was historically popular for its simplicity and use on various media (like floppy disks and older USB drives). Given the complexity of bootloader configurations, this command serves as a utility for automated conversion, though its experimental status highlights the ongoing challenges in translating diverse boot configurations perfectly.


title: SYNOPSIS
content:
<b>grub2-mkpasswd-pbkdf2</b> [<b>-i</b> <i>ITERATION</i>] [<b>-s</b> <i>SALT</i>] [<b>--pbkdf2-algorithm</b> <i>ALGORITHM</i>] [<b>--password</b> <i>PASSWORD</i>]


title: PARAMETERS
content:
<b><b>-i</b> <i>ITERATION</i>, <b>--iteration=</b><i>ITERATION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of iterations (rounds) for the PBKDF2 algorithm. A higher number increases security but also computation time. The default is typically 10000 or more.<br><br><b><b>-s</b> <i>SALT</i>, <b>--salt=</b><i>SALT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the salt to use for the PBKDF2 algorithm. If not provided, a random salt will be generated automatically. Using a unique, random salt for each password is a security best practice.<br><br><b><b>--pbkdf2-algorithm=</b><i>ALGORITHM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the underlying hashing algorithm to use for PBKDF2. Common choices include <i>sha512</i> (the default), <i>sha256</i>, etc. It's recommended to use a strong algorithm like <i>sha512</i>.<br><br><b><b>--password=</b><i>PASSWORD</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the password directly on the command line. For security reasons, it is generally recommended to avoid this option as the password might be stored in shell history or visible to other users via process lists. Instead, let the command prompt for interactive input.<br><br><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;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
The <i>grub2-mkpasswd-pbkdf2</i> command is a utility designed to generate highly secure, PBKDF2-hashed passwords specifically for use with the GRUB2 bootloader.<br><br>GRUB2 (Grand Unified Bootloader, version 2) can be configured to require a password for accessing certain menu entries, preventing unauthorized users from modifying boot parameters, or even accessing the GRUB command line. Unlike older hashing methods (e.g., MD5 or SHA-1) that are susceptible to modern cracking techniques, PBKDF2 (Password-Based Key Derivation Function 2) adds significant computational cost to the hashing process. This 'key stretching' makes brute-force attacks and rainbow table attacks much more difficult and time-consuming, enhancing the security of your bootloader.<br><br>The command takes a password as input (either interactively or via an option) and outputs a string containing the salt, iteration count, and the PBKDF2 hash. This string is then used in the <i>grub.cfg</i> configuration file to secure GRUB2 menus or the GRUB console. Proper configuration of GRUB2 with these strong passwords is a crucial step in securing the boot process of a Linux system.


title: CAVEATS
content:
Using the <i>--password</i> option on the command line is highly discouraged due to security risks, such as the password being exposed in shell history, process lists (e.g., <i>ps</i> output), or system logs. Always prefer interactive password input when possible.<br><br>The generated password hash must be correctly integrated into the GRUB2 configuration file (typically <i>/boot/grub/grub.cfg</i> or <i>/etc/grub.d/</i> scripts) for it to take effect. Incorrect placement or syntax will prevent the password from working.<br><br>Ensure a sufficiently high iteration count (e.g., 10000 or more) is used for robust security against brute-force attacks.


title: USAGE IN GRUB.CFG
content:
The output of <i>grub2-mkpasswd-pbkdf2</i> is a string like 'grub.pbkdf2.v1.username.salt.iteration.hash'. This string is then used within your <i>grub.cfg</i> file (or a file included by it, like <i>/etc/grub.d/40_custom</i>) to set a password for GRUB. A common setup involves defining superusers and associating the hash with a username, for example:<br><i>set superusers="myuser"</i><br><i>password_pbkdf2 myuser grub.pbkdf2.v1.myuser.salt.iteration.hash</i><br>This secures specific menu entries using the <i>--users</i> option or the entire GRUB console.


title: HISTORY
content:
The adoption of PBKDF2 for password hashing in GRUB2 represents a significant security enhancement over older, less secure hashing methods like MD5 or SHA-1. This command, <i>grub2-mkpasswd-pbkdf2</i>, was introduced to facilitate the generation of these stronger passwords, aligning GRUB2's password protection capabilities with modern cryptographic best practices. Its development reflects the ongoing effort to secure all layers of a Linux system, including the crucial boot process, against evolving security threats.


title: SYNOPSIS
content:
<b>grubby</b> [<i>OPTIONS</i>] <br> <b>grubby</b> <i>--add-kernel=PATH</i> [<i>OPTIONS</i>] <br> <b>grubby</b> <i>--update-kernel=PATH</i> [<i>OPTIONS</i>] <br> <b>grubby</b> <i>--set-default=INDEX|PATH</i> <br> <b>grubby</b> <i>--info=INDEX|PATH</i> <br> <b>grubby</b> <i>[--default-index | --next-index]</i>


title: PARAMETERS
content:
<b>--add-kernel=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new kernel entry to the boot configuration based on the specified kernel image path.<br><br><b>--update-kernel=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates an existing kernel entry identified by its path, modifying its associated arguments.<br><br><b>--remove-kernel=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified kernel entry from the boot configuration.<br><br><b>--set-default=INDEX|PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default boot entry for the next boot, using either its numerical index or the kernel image path.<br><br><b>--info=INDEX|PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific boot entry, including its kernel path and arguments.<br><br><b>--args=ARGS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds specified arguments to the kernel command line for the entry being operated upon.<br><br><b>--remove-args=ARGS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes specified arguments from the kernel command line for the entry being operated upon.<br><br><b>--make-default</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the newly added or updated kernel entry the default boot entry.<br><br><b>--copy-default</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies kernel arguments from the current default boot entry to a newly added or updated entry.<br><br><b>--default-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the numerical index of the currently configured default boot entry.<br><br><b>--next-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the numerical index that the next new kernel entry would occupy in the boot menu.<br><br><b>--bootloader-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the detected GRUB bootloader version that <b>grubby</b> is interacting with.<br><br><b>--config-file=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <b>grubby</b> configuration file to use instead of the default.<br><br><b>--grub-config=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative GRUB 2 main configuration file (e.g., <I>/boot/grub2/grub.cfg</I>) for operations.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational and warning output, showing only critical error messages.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output, useful for troubleshooting issues with <b>grubby</b> operations.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <b>grubby</b> utility's version information and exits.<br><br>


title: DESCRIPTION
content:
<b>grubby</b> is a command-line tool designed to query and update the GRUB 2 bootloader configuration. It provides a safer and more automated way to manage boot entries, especially for kernel installations and removals, than directly editing <I>grub.cfg</I>. System administrators and package management tools often use <b>grubby</b> to ensure that new kernel versions are correctly added to the boot menu and old ones are cleaned up. It abstracts away the complexities of GRUB 2's configuration files, allowing for programmatic manipulation of boot entries, default kernel selection, and modification of kernel command-line arguments. This is particularly useful in environments where automated updates are critical. It typically works by maintaining a configuration or database that GRUB then uses to generate its <I>grub.cfg</I>.


title: CAVEATS
content:
<b>grubby</b> primarily manages entries within GRUB 2. While it abstracts <I>grub.cfg</I>, direct manual edits to <I>grub.cfg</I> or <I>grubenv</I> can lead to inconsistencies or be overwritten by <b>grubby</b> or other system tools during updates. It is often specific to Red Hat-based distributions and might not be present or behave identically on other Linux families (e.g., Debian/Ubuntu, Arch). Using it incorrectly can lead to unbootable systems, so caution is advised.


title: CONFIGURATION FILES
content:
<b>grubby</b> works by managing boot entries that are then reflected in the main GRUB 2 configuration file, typically <I>/boot/grub2/grub.cfg</I>. It might also interact with <I>grubenv</I> for default boot entry persistence. Unlike direct <I>grub.cfg</I> editing, <b>grubby</b> often uses a more robust internal mechanism or specific files (e.g., in <I>/etc/grub.d/</I> or within <I>/boot/grub2/</I>) to ensure changes are properly integrated and persistent across <I>grub2-mkconfig</I> runs.


title: INTEGRATION WITH PACKAGE MANAGERS
content:
One of <b>grubby</b>'s primary uses is its integration with package management systems such as DNF or YUM. When new kernel packages are installed or old ones removed, scripts triggered by the package manager invoke <b>grubby</b> to automatically add or remove the corresponding boot entries, ensuring the boot menu is always up-to-date without manual intervention.


title: HISTORY
content:
<b>grubby</b> emerged as a utility on Red Hat-based Linux distributions (like Fedora, RHEL, CentOS) to simplify and automate the management of GRUB 2 boot entries. Before tools like <b>grubby</b>, maintaining boot configurations, especially after kernel updates, often involved manual editing of complex GRUB configuration files, which was error-prone. <b>grubby</b> provides a high-level abstraction, allowing package managers (like <I>dnf</I> or <I>yum</I>) to seamlessly integrate kernel installations and removals into the boot process without human intervention. Its development was driven by the need for robust and automated bootloader management in enterprise and frequently updated desktop environments.


title: SYNOPSIS
content:
<I>grumphp &lt;command&gt; [options]</I><br><br>Common commands include:<br><br><I>grumphp init</I><br><I>grumphp run [--skip-success-text] [--test-suite=&lt;suite&gt;]</I><br><I>grumphp git:deactivate</I>


title: PARAMETERS
content:
<b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help for the specified command or lists available commands.<br><br><b><I>--version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the application version.<br><br><b><I>--config=&lt;path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom path to the <I>grumphp.yml</I> or <I>grumphp.yaml</I> configuration file.<br><br><b><I>--test-suite=&lt;suite&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only runs tasks associated with a specific test suite as defined in the configuration.<br><br><b><I>--tasks=&lt;tasks&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only runs a specific list of tasks (comma-separated names) instead of all configured tasks.<br><br><b><I>--skip-success-text</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the 'GrumPHP is sniffing your code!' success message during execution.<br><br><b><I>--no-interaction</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ask any interactive questions during command execution. Useful for automation scripts.<br><br><b><I>--env=&lt;environment&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the environment for which to run tasks (e.g., <I>dev</I>, <I>prod</I>).<br><br>


title: DESCRIPTION
content:
GrumPHP is a powerful, flexible tool designed to automate code quality checks within a Git workflow. By leveraging Git's pre-commit, pre-merge, and pre-push hooks, GrumPHP allows developers to define a series of tasks—such as linting, static analysis, code style checks, or unit tests—that must pass before a commit or push is finalized. This proactive approach helps maintain high code standards, catches errors early, and ensures consistency across a development team. It's highly configurable, supporting a wide array of PHP tools like PHPStan, PHPLint, PHP_CodeSniffer (PHPCS), PHPUnit, and more, making it an essential part of a robust Continuous Integration/Continuous Delivery (CI/CD) pipeline for PHP projects. Its primary goal is to prevent faulty or non-compliant code from entering the shared codebase, thereby improving overall project quality and developer efficiency.


title: CAVEATS
content:
Requires a PHP environment with Composer installed and a Git repository. Can introduce a slight delay to commit or push operations, depending on the number and complexity of configured tasks. Configuration can become intricate for complex projects or highly customized task definitions. Primarily designed for PHP projects and Git-based version control systems.


title: CONFIGURATION
content:
GrumPHP's behavior is entirely controlled by a configuration file, typically named <I>grumphp.yml</I> or <I>grumphp.yaml</I>, located in the project's root directory. This YAML file defines which tasks to run, their specific configurations, and which test suites they belong to.


title: INSTALLATION
content:
GrumPHP is installed as a development dependency via Composer. After installation (<I>composer require --dev phpro/grumphp</I>), it is activated in the Git repository using the command <I>grumphp init</I>, which sets up the necessary Git hooks.


title: SKIPPING CHECKS
content:
In urgent situations, GrumPHP checks can be temporarily bypassed during a commit by adding <I>--no-verify</I> to the <I>git commit</I> command (e.g., <I>git commit -m "Emergency fix" --no-verify</I>) or by including <I>[skip grumphp]</I> or <I>[GrumPHP skip]</I> in the commit message if configured in <I>grumphp.yml</I>.


title: HISTORY
content:
GrumPHP was initially developed by the team at <I>Phpro</I> and first released around 2014-2015. It emerged as a solution to streamline code quality enforcement in PHP projects, addressing the need for automated checks directly within the Git workflow. Its design focuses on flexibility and extensibility, allowing developers to easily integrate various code analysis and testing tools. Over the years, it has gained significant traction within the PHP community, becoming a widely adopted tool for pre-commit hook management due to its robust features, active development, and strong community support.


title: PARAMETERS
content:
<b>--force, -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces tasks to continue execution even if warnings or errors are encountered.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs verbose information during task execution, useful for debugging and understanding the workflow.<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colored output in the terminal, useful for environments that don't support ANSI colors.<br><br><b>--base=<path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative base directory for Grunt to resolve paths from, instead of the current working directory.<br><br><b>--gruntfile=<path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the <B>Gruntfile.js</B>. Useful when the Gruntfile is not in the default location.<br><br><b>--tasks=<paths></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more comma-separated directories where Grunt should look for custom task files.<br><br><b>--version, -V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of Grunt CLI currently installed.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message, listing available command-line options for Grunt.<br><br>


title: DESCRIPTION
content:
<i>grunt</i> is a powerful JavaScript task runner, primarily used in web development to automate repetitive and time-consuming tasks. It operates as a command-line tool, running on <B>Node.js</B> and installed via the <B>npm</B> (Node Package Manager).<br><br>Developers define their project's build processes and development workflows in a configuration file called <B>Gruntfile.js</B>. This file specifies various tasks such as minification (reducing file size), compilation (e.g., Sass to CSS, TypeScript to JavaScript), linting (checking code quality), concatenation (combining files), and unit testing. When the <i>grunt</i> command is executed in a Linux terminal, it reads the <B>Gruntfile.js</B> and performs the defined operations.<br><br>While not a native Linux system utility, <i>grunt</i> is an integral part of the JavaScript development ecosystem on Linux, streamlining development, enhancing efficiency, and ensuring consistency across projects.


title: CAVEATS
content:
<i>grunt</i> requires <B>Node.js</B> and <B>npm</B> to be installed on the system. Its functionality heavily relies on community-contributed plugins, which need to be installed as project dependencies. For very large or complex projects, its configuration can become intricate, and its synchronous task execution model can sometimes be slower than stream-based alternatives like Gulp or modern bundlers like Webpack.


title: GRUNTFILE.JS
content:
The <B>Gruntfile.js</B> is the central configuration file for <i>grunt</i>. It's a JavaScript file where developers define and configure tasks, load necessary plugins, and specify how their project should be built or processed. This file typically resides in the root of a project and is essential for <i>grunt</i> to function, dictating the entire automation workflow.


title: PLUGINS ECOSYSTEM
content:
<i>grunt</i>'s versatility comes from its extensive plugin ecosystem. These plugins, distributed via <B>npm</B>, provide pre-built tasks for almost any common development operation, such as <B>grunt-contrib-uglify</B> for JavaScript minification, <B>grunt-contrib-sass</B> for Sass compilation, and <B>grunt-contrib-watch</B> for monitoring file changes. Developers install and configure these plugins within their <B>Gruntfile.js</B> to tailor <i>grunt</i> to their specific project needs.


title: HISTORY
content:
<i>grunt</i> emerged in the early 2010s as a pioneering tool for automating front-end development tasks in the JavaScript ecosystem. It quickly gained significant adoption, becoming a standard choice for build processes before the rise of other task runners like <B>Gulp</B> and module bundlers like <B>Webpack</B>. Its structured approach to task definition through <B>Gruntfile.js</B> and a rich plugin ecosystem made complex workflows manageable. While its dominant position has shifted with newer tools, <i>grunt</i> remains a fundamental part of many legacy projects and holds an important place in the history of web development tooling.


title: SYNOPSIS
content:
<B>gs</B> [<I>options</I>] [<I>input_files</I>]<br><br>Common usage to convert PDF to PNG at 300 DPI:<br><B>gs</B> <I>-sDEVICE=<B>pngalpha</B></I> <I>-o <B>output.png</B></I> <I>-r<B>300</B></I> <I><B>input.pdf</B></I><br><br>For batch processing multiple pages to JPEG:<br><B>gs</B> <I>-dNOPAUSE</I> <I>-dBATCH</I> <I>-sDEVICE=<B>jpeg</B></I> <I>-r<B>150</B></I> <I>-o <B>page%03d.jpg</B></I> <I><B>document.ps</B></I>


title: PARAMETERS
content:
<b><B>-sDEVICE=name</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the output device for rendering. <I>name</I> can be <B>pngalpha</B>, <B>jpeg</B>, <B>pswrite</B>, <B>pdfwrite</B>, etc.<br><br><b><B>-o file</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output filename. Use <B>%d</B> or <B>%0Xd</B> for page numbering with multi-page devices.<br><br><b><B>-rresXresY</B> or <B>-rres</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the X and Y resolution (DPI) for rendering bitmap devices. If one value, it's used for both.<br><br><b><B>-dname</B> or <B>-dname=value</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a PostScript name with a true value (boolean flag) or a specific value. E.g., <B>-dNOPAUSE</B> (no prompts), <B>-dBATCH</B> (exit after files), <B>-dSAFER</B> (safe mode).<br><br><b><B>-sname=string</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a PostScript name with a string value. E.g., <B>-sPAPERSIZE=a4</B>, <B>-sOutputFile=%stdout</B>.<br><br><b><B>-gwidthxheight</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the graphics region (page size) in pixels for bitmap devices.<br><br><b><B>-q</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in quiet mode, suppressing informative messages and the Ghostscript prompt.<br><br><b><B>-f</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes `gs` to interpret subsequent arguments as file names to be processed, rather than options.<br><br>


title: DESCRIPTION
content:
<I>The `gs` command, short for Ghostscript, is a powerful and versatile interpreter for PostScript and PDF files. It can render these page description languages to various output devices, including printers, display devices (like X11 windows), and image files (e.g., JPEG, PNG, TIFF). It's widely used for viewing PostScript/PDF documents, converting them between formats, processing them for printing, and creating images from them. Ghostscript also includes utilities for creating PDF files from PostScript and for processing PostScript code programmatically.</I>


title: CAVEATS
content:
<I>Ghostscript can be resource-intensive, especially when rendering high-resolution or complex documents. Running `gs` with untrusted PostScript or PDF files can pose security risks, as these formats are Turing-complete and can execute arbitrary code. It's crucial to use the <B>-dSAFER</B> option when processing untrusted documents to disable file system access and other potentially dangerous operations.</I>


title: DEVICES
content:
<I>Ghostscript's output capabilities are managed through "devices." Each device specifies how PostScript/PDF output should be rendered (e.g., to a specific image format, a printer driver, or an on-screen display). Users select a device using the <B>-sDEVICE</B> option, enabling flexibility in output format and quality.</I>


title: OPERATORS
content:
<I>PostScript and PDF are interpreted by `gs` using a sophisticated set of built-in operators. These operators perform various tasks, from drawing shapes and text to managing memory and file I/O. `gs` acts as the execution engine for these operations, processing the commands defined within the document.</I>


title: HISTORY
content:
<I>Ghostscript was originally developed by L. Peter Deutsch, with its first release under the Aladdin Free Public License (AFPL) in 1990. Over time, its licensing shifted to the GNU Affero General Public License (AGPL) for newer versions, solidifying its role as a cornerstone of open-source document processing on Unix-like systems. It became an essential backend for many printing systems (like CUPS) and PDF manipulation tools, widely adopted due to its robustness and comprehensive PostScript and PDF interpretation capabilities.</I>


title: PARAMETERS
content:
<b>XML_FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the input GSettings XML schema definition file (e.g., `org.gnome.Terminal.gschema.xml`).<br><br><b>OUTPUT_FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path where the converted binary schema data will be written. This file typically has a `.gschema.keyfile` extension and is then used by `glib-compile-schemas`.<br><br>


title: DESCRIPTION
content:
The <b>gsettings-data-convert</b> command is a low-level utility provided by the GLib library, primarily used during the build process of applications that utilize <I>GSettings</I>. Its main function is to transform human-readable GSettings XML schema definition files (typically with a `.gschema.xml` extension) into a more compact, binary format. These binary files are then consumed by <I>glib-compile-schemas</I>, which compiles them into a single, efficient GSettings schema database that applications can query at runtime. It is not typically invoked directly by end-users but rather by build systems like Meson or Autotools to prepare schema data for installation.


title: CAVEATS
content:
This command is primarily a build-time utility and not typically used by end-users directly. It lacks interactive features or extensive command-line options, focusing solely on its conversion task. Users interested in managing GSettings should use the `gsettings` command-line tool.


title: PURPOSE IN BUILD SYSTEMS
content:
During the compilation and installation of an application, build systems (like Autotools, Meson, or CMake) often invoke <b>gsettings-data-convert</b> as a build step. This pre-processing converts XML schema definitions into a binary representation. This step is crucial for preparing the schema data in a format optimized for runtime access by the GSettings backend, thereby improving application startup times and configuration lookup efficiency. The resulting binary files are then collected and compiled into a single database by `glib-compile-schemas`.


title: HISTORY
content:
<b>gsettings-data-convert</b> emerged as an integral part of the GSettings configuration system within GLib, which superseded the older GConf system in GTK+ and GNOME environments. Its development is tied to the evolution of GLib itself, providing the necessary backend for applications to define and store their configuration settings in a standardized and efficient manner. It acts as a foundational component in the modern GNOME configuration stack, ensuring schema integrity and performance.


title: PARAMETERS
content:
<b><b>-i</b>, <b>--input</b>=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reads the input schema from <I>FILE</I> instead of standard input. This is typically the deprecated keyfile format schema.</i><br><br><b><b>-o</b>, <b>--output</b>=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Writes the converted schema to <I>FILE</I> instead of standard output. The output will be in the XML format.</i><br><br><b><b>-d</b>, <b>--doctype</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Includes the XML DOCTYPE declaration in the output. This can be useful for XML validation.</i><br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a help message and exits.</i><br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays version information and exits.</i><br><br>


title: DESCRIPTION
content:
<i><B>gsettings-schema-convert</B> is a utility designed to facilitate the migration and interoperability of GSettings schemas by converting them between different formats. Primarily, its role is to convert deprecated keyfile-based GSettings schemas (a simple INI-like format) into the modern XML format used by GSettings. <br><br>GSettings is the configuration storage system used by the GNOME desktop environment and many GTK applications. Schemas define the structure, types, default values, and descriptions of settings. The transition from keyfile to XML schemas was a significant update in GLib's configuration management, offering better structure, validation, and internationalization capabilities. This command helps developers and system administrators update legacy schemas to the current standard, ensuring compatibility and leveraging the benefits of the XML format.</i>


title: CAVEATS
content:
<i>This utility is primarily focused on converting from the older, deprecated keyfile schema format to the newer XML format. While it aids in migration, it may not perfectly handle all edge cases or very complex schema definitions. The converted XML output should always be reviewed for correctness and then compiled using <B>glib-compile-schemas</B> for GSettings to use it.</i>


title: SCHEMA FORMATS
content:
<i>GSettings schemas can exist in two primary formats: <br><br>1. <B>Keyfile Format</B>: An older, deprecated INI-like format (e.g., <I>.gschema.override</I> files or older <I>.gschema.keyfile</I>). It's simpler but lacks XML's structured benefits.<br>2. <B>XML Format</B>: The modern, preferred format (e.g., <I>.gschema.xml</I> files). It offers better structure, support for multiple translations, complex types, and validation rules. <B>gsettings-schema-convert</B> primarily converts from the keyfile format to the XML format.</i>


title: TYPICAL WORKFLOW
content:
<i>A common workflow for creating or updating GSettings schemas involves: <br><br>1. Defining settings in an XML schema file (<I>.gschema.xml</I>).<br>2. If migrating from an old keyfile, using <B>gsettings-schema-convert</B> to convert it to XML.<br>3. Compiling the XML schema into a binary database using <B>glib-compile-schemas</B>.<br>4. Placing the compiled schema in the appropriate system or user directory for GSettings to find and use.</i>


title: HISTORY
content:
<i><B>gsettings-schema-convert</B> is part of the GLib library, specifically the GSettings framework. Its existence is tied to the evolution of configuration management within the GNOME project and related GTK applications. It emerged as a tool to smooth the transition from older GConf-based systems and, more directly, from the initial keyfile-based GSettings schemas to the more robust and standardized XML format. This reflects GLib's commitment to improving developer experience and application configuration capabilities over time.</i>


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;No standard parameters are known for the non-existent or unrecognized <i><b>gslp</b></i> command.<br><br>


title: DESCRIPTION
content:
The command <i><b>gslp</b></i> does not appear to be a standard or commonly recognized command in most Linux distributions. There is no widely available man page or common utility directly named <i><b>gslp</b></i>.<br><br>It is possible that it is a typo for another command (e.g., <i>glpsol</i>, <i>slp</i>), a custom script, a very specialized tool part of a niche software package, or a component of a specific development library (like <i>GNU Smalltalk Library Project</i> or <i>General Serial Line Protocol</i>, which are protocols/libraries, not direct commands). Without further context or the specific software package it belongs to, its function and usage cannot be determined.


title: CAVEATS
content:
As <i><b>gslp</b></i> is not a standard command, attempting to execute it on a typical Linux system will likely result in a 'command not found' error. Users should verify the spelling or the specific software package they intend to use.


title: POSSIBLE MISINTERPRETATIONS
content:
<li>Could be a typo for <i><b>glpsol</b></i> (GNU Linear Programming Kit solver).</li><li>Could refer to the <i><b>General Serial Line Protocol</b></i>, which is a communication protocol, not a direct command-line utility.</li><li>Could be related to the <i><b>GNU Smalltalk Library Project</b></i> (GSLP), which is a development library and not a direct executable command.


title: HISTORY
content:
Information regarding the history or development of a standard <i><b>gslp</b></i> command is unavailable as it is not a recognized utility in mainstream Linux distributions.


title: PARAMETERS
content:
<b>-sSOUNDDEVICE=<i>device_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the sound device to use for audio output. This allows directing the PostScript-generated sound to a particular hardware or virtual audio interface.<br><br><b>[<i>generic Ghostscript options</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>gsnd</i> supports many of the standard options available for the main Ghostscript interpreter (<i>gs</i>). These options can control aspects like memory allocation, debugging output, error handling, and other interpreter-specific behaviors.<br><br><b>[<i>file ...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more PostScript language files to be interpreted. If no files are specified, <i>gsnd</i> reads the PostScript code from standard input (<i>stdin</i>).<br><br>


title: DESCRIPTION
content:
<i>gsnd</i> is an obscure and largely deprecated utility, historically associated with early versions of Ghostscript and the X Window System. Its primary purpose was to interpret PostScript code and generate sound output from it directly to an available sound device. This functionality allowed PostScript programs to describe and control sound generation, leveraging PostScript's capabilities as a versatile page description language. However, it is not a standard or commonly available Linux command in modern distributions, and its specialized functionality has been largely superseded by contemporary audio APIs and toolkits. It typically reads PostScript input from named files or standard input, processing it to produce audio output. Its relevance is primarily historical, showcasing early attempts at direct software-controlled audio synthesis from programmatic descriptions.


title: CAVEATS
content:
<i>gsnd</i> is an extremely niche and largely obsolete command. It is not part of standard modern Linux distributions and its functionality for interpreting PostScript directly to sound is rarely, if ever, used today. Its availability is limited to very old or specialized systems, and modern audio APIs and tools offer far more flexible and robust ways to handle sound and audio programming. Users looking for sound playback or generation capabilities in modern Linux environments should use tools like <i>aplay</i>, <i>sox</i>, or programming libraries for audio.


title: HISTORY
content:
<i>gsnd</i> emerged as a component during the early development of Ghostscript and the X Window System. It represents a historical approach to audio synthesis, leveraging the descriptive power of PostScript. Its development dates back to a period (likely the 1990s) when direct hardware interaction and low-level system programming were more common for specialized multimedia tasks, preceding the widespread adoption of standardized, high-level audio APIs like ALSA or PulseAudio. It has not seen active development or widespread use for many decades, remaining largely a curiosity in computing history.


title: PARAMETERS
content:
<b><i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path or URL to the media file or stream to analyze. This can be a local file path (e.g., <code>file:///path/to/media.mp4</code>), a network URI (e.g., <code>http://example.com/stream.mp3</code>), or other GStreamer-supported URIs.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays more detailed and verbose information about the discovery process and the media properties. This can include GStreamer debug messages related to the discovery.<br><br><b><b>-a</b>, <b>--async</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs the media discovery process asynchronously. This means the command will return immediately, potentially allowing for non-blocking operations in scripts, though the output might not be directly available without further integration.<br><br><b><b>-c</b> <i>N</i>, <b>--timeout=</b><i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout for the discovery process in seconds. If the discovery does not complete within this time, the command will exit, preventing indefinite hangs on problematic or very large media sources.<br><br><b><b>-s</b>, <b>--simulate-tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the extraction of tags. This might be useful for testing tag parsing without needing the full media data, or for cases where actual tag extraction is slow or problematic.<br><br><b><b>-i</b> <i>N</i>, <b>--indent=</b><i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indents the output by <i>N</i> spaces, improving readability for nested information structures.<br><br><b><b>--disable-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colored output, which can be useful when redirecting output to files or in terminals that do not support ANSI color codes.<br><br>


title: DESCRIPTION
content:
<code>gst-discoverer-1.0</code> is a command-line utility provided by the GStreamer multimedia framework. Its primary purpose is to inspect and extract detailed information about media files or URIs (Uniform Resource Identifiers). When invoked with a specific media source, it analyzes the content and provides a comprehensive report, including details such as the overall duration, container format, and information about each individual stream (e.g., audio, video, subtitle).<br><br>For each stream, it typically lists the codec, resolution (for video), sample rate (for audio), bitrate, language, and other relevant properties. Additionally, it can display embedded metadata tags like title, artist, album, genre, and more. This tool is invaluable for developers, system administrators, and users who need to debug multimedia issues, verify media file properties, or understand the underlying structure and codecs of a media asset without playing it. It leverages GStreamer's powerful plugin architecture to support a wide array of media formats and codecs.


title: CAVEATS
content:
<b>GStreamer Dependency:</b> <code>gst-discoverer-1.0</code> requires a working GStreamer 1.x installation with the necessary base plugins. Without appropriate plugins (e.g., for MP4, WebM, or specific codecs), it may fail to discover or fully analyze certain media formats.<br><br><b>Network Connectivity:</b> When analyzing network URIs (e.g., <code>http://</code>, <code>rtmp://</code>), stable network connectivity is essential. Timeout settings (<code>-c</code>) can help manage slow or unresponsive network sources.<br><br><b>Resource Usage:</b> Analyzing very large media files or streams can consume significant CPU and memory resources, especially with verbose output enabled.<br><br><b>Partial Files:</b> If the media file is incomplete or corrupted, the tool might only be able to extract partial information or report errors.


title: <I>COMMON OUTPUT INFORMATION</I>
content:
The output of <code>gst-discoverer-1.0</code> typically includes:<br><br><b>Duration:</b> The total length of the media.<br><b>Seekable:</b> Whether the media can be randomly accessed (seeking).<br><b>Live:</b> Indicates if it's a live stream.<br><b>Container Format:</b> The overall wrapper format (e.g., MP4, Matroska, Ogg).<br><b>Streams:</b> A list of all elementary streams (e.g., audio, video, text). For each stream, details like codec (e.g., H.264, AAC), resolution, frame rate, sample rate, bitrate, language, and stream ID are provided.<br><b>Tags:</b> Embedded metadata like title, artist, album, genre, date, and sometimes cover art details.


title: <I>EXAMPLE USAGE</I>
content:
To inspect a local video file:<br><code>gst-discoverer-1.0 file:///home/user/myvideo.mp4</code><br><br>To inspect a network audio stream with verbose output and a timeout:<br><code>gst-discoverer-1.0 -v -c 30 http://example.com/radio.mp3</code><br><br>To analyze a file in the current directory:<br><code>gst-discoverer-1.0 myaudio.ogg</code> <i>(Note: Relative paths work directly, <code>file://</code> is optional for local files).</i>


title: HISTORY
content:
<code>gst-discoverer-1.0</code> is an integral part of the GStreamer 1.0 series, which was released after the long-standing GStreamer 0.10 series. The 1.0 branch introduced a more stable API, improved thread safety, and significant performance enhancements compared to its predecessor. The <i>discoverer</i> concept itself existed in earlier forms within GStreamer, but <code>gst-discoverer-1.0</code> provides a refined and robust standalone utility for media analysis, leveraging the modern GStreamer 1.x API for comprehensive and reliable media introspection. Its development mirrors the continuous evolution of the GStreamer framework to meet the growing demands of modern multimedia applications.


title: PARAMETERS
content:
<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 for the utility and exits.<br><br>


title: DESCRIPTION
content:
The <b>gst-feedback-0.10</b> command is a specialized utility designed to collect comprehensive debug and system information relevant to the GStreamer 0.10 multimedia framework. Its primary purpose was to assist users and developers in reporting bugs and diagnosing issues by providing a standardized dump of system details, GStreamer version, installed plugins, and environment variables. This information helps developers understand the context in which a bug occurs.<br><br>As its name suggests, this tool is specifically tied to the GStreamer 0.10 series, which has been superseded by newer GStreamer 1.x versions. Consequently, <b>gst-feedback-0.10</b> is considered an obsolete utility and is rarely found or used on modern Linux distributions. It typically operates as a simple script, printing its gathered information to standard output, which is then commonly redirected to a file for sharing in bug reports.


title: CAVEATS
content:
<i><b>Obsolete Version:</b> This command is specifically for GStreamer 0.10, which is an outdated and no longer maintained version of the GStreamer framework. It will not work with GStreamer 1.x installations.<br><b>Availability:</b> It is highly unlikely to be installed or available on modern Linux distributions unless explicitly added for compatibility with legacy systems.<br><b>Information Sharing:</b> The output contains system-specific details and configuration. Exercise caution and review the content before sharing it publicly, as it may include sensitive information.</i>


title: OUTPUT CONTENT
content:
When executed, <b>gst-feedback-0.10</b> typically collects and prints the following types of information:<br><i>- System details (e.g., kernel version, OS distribution).<br>- GStreamer version and configuration.<br>- A list of installed GStreamer 0.10 plugins and their details.<br>- Relevant environment variables that might affect GStreamer's behavior (e.g., GST_PLUGIN_PATH).<br>- Potentially, other diagnostic data useful for debugging.</i>


title: TYPICAL USAGE SCENARIO
content:
The most common way to use <b>gst-feedback-0.10</b> was to redirect its output to a text file, which could then be attached to a bug report or shared with support personnel. For example:<br><br><b>gst-feedback-0.10</b> > <i>gstreamer_feedback.txt</i><br><br>This creates a file named <i>gstreamer_feedback.txt</i> containing all the gathered diagnostic information.


title: HISTORY
content:
The <b>gst-feedback-0.10</b> utility was developed and maintained as part of the GStreamer 0.10 project, active during the late 2000s and early 2010s. It served as a crucial diagnostic tool for the GStreamer community during that period, facilitating streamlined bug reporting. With the advent and widespread adoption of GStreamer 1.x, the need for 0.10-specific tools like <b>gst-feedback-0.10</b> diminished, leading to its eventual deprecation and removal from most contemporary Linux distributions.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command-line options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the GStreamer 0.10 core and <b>gst-inspect-0.10</b> tool version information.<br><br><b><b>--print-plugins</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of all registered GStreamer 0.10 plugins found on the system.<br><br><b><b>--print-elements</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of all registered GStreamer 0.10 elements, categorized by plugin.<br><br><b><b>--print-uris</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all URI handlers supported by GStreamer 0.10 (e.g., file://, http://).<br><br><b><b>--print-formats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a list of all supported GStreamer 0.10 media formats.<br><br><b><b>--print-supported</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of supported types (e.g., video, audio) and their associated capabilities.<br><br><b><b>--print-features</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all supported GStreamer 0.10 features, such as element factories or type finds.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used without a specific element or plugin name, it lists all elements, including base elements not part of a specific plugin.<br><br><b><b>-e</b> <I>ELEMENT_NAME</I>, <b>--element</b> <I>ELEMENT_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inspects and prints detailed information about a specific GStreamer 0.10 element identified by its name (e.g., <i>fakesink</i>, <i>decodebin</i>).<br><br><b><b>-p</b> <I>PLUGIN_NAME</I>, <b>--plugin</b> <I>PLUGIN_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inspects and prints detailed information about a specific GStreamer 0.10 plugin identified by its name (e.g., <i>ogg</i>, <i>vorbis</i>).<br><br><b><b>-f</b>, <b>--full</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When inspecting an element or plugin, provides the most comprehensive information, including all properties, pads, signals, and their detailed descriptions.<br><br><b><b>-s</b>, <b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output to only show strict information, often related to compliance or specific types of elements.<br><br><b><b>--types</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of plugin types and their corresponding descriptions.<br><br>


title: DESCRIPTION
content:
The <b>gst-inspect-0.10</b> command is a powerful command-line tool designed for the GStreamer 0.10 multimedia framework. Its primary purpose is to inspect and provide detailed information about installed GStreamer plugins, elements, and features. It helps developers and users understand the capabilities of various GStreamer components, including their properties, pads (input/output points), signals, and supported formats. This utility is indispensable for debugging pipelines, learning about available functionalities, and developing GStreamer applications on systems or environments that still rely on the GStreamer 0.10 API series. While largely superseded by the 1.x series, <b>gst-inspect-0.10</b> remains crucial for maintaining and working with legacy GStreamer-based applications.


title: CAVEATS
content:
This command specifically targets the <i>GStreamer 0.10</i> API series. Most modern Linux distributions and GStreamer applications now use <i>GStreamer 1.x</i>. If you are working with a recent GStreamer setup, you should typically use <b>gst-inspect-1.0</b> instead. <br>The functionality and available plugins might differ significantly between 0.10 and 1.x versions. Ensure you are using the correct version of <b>gst-inspect</b> that matches your GStreamer installation and application dependencies. It may not be installed by default on systems primarily shipping GStreamer 1.x.


title: OUTPUT INTERPRETATION
content:
When inspecting an element with <b>gst-inspect-0.10</b>, the output typically includes several sections:<br><b>Factory</b>: Basic information about the element's origin.<br><b>Plugin</b>: The plugin the element belongs to.<br><b>Documentation</b>: A brief description of the element's purpose.<br><b>Pads</b>: Lists input (sink) and output (src) pads, detailing their capabilities (supported media types).<br><b>Properties</b>: Describes configurable attributes of the element, including their type, default values, and range. These can be set during pipeline construction (e.g., <i>gst-launch-0.10 filesrc location=audio.mp3 ! ...</i>).<br><b>Signals</b>: Events the element might emit.<br>Understanding these sections is crucial for constructing correct GStreamer pipelines and leveraging element functionalities.


title: COMMON USAGE EXAMPLES
content:
To list all available elements:<br><i>gst-inspect-0.10 --elements</i><br><br>To inspect a specific element like <i>oggdemux</i>:<br><i>gst-inspect-0.10 oggdemux</i><br><br>To get full details about the <i>audioconvert</i> element:<br><i>gst-inspect-0.10 -f audioconvert</i><br><br>To list all plugins:<br><i>gst-inspect-0.10 --plugins</i>


title: HISTORY
content:
The <b>gst-inspect-0.10</b> command was part of the GStreamer 0.10 stable release series, which was initially released in 2005 and served as the primary stable branch for many years. It was the standard tool for inspecting GStreamer components during that period. With the release of GStreamer 1.0 in 2012, which introduced significant API and ABI changes, the 0.10 series began to be phased out. However, due to its widespread adoption, many legacy systems, applications, and embedded devices still rely on GStreamer 0.10, making <b>gst-inspect-0.10</b> an essential tool for maintaining and troubleshooting such environments.


title: SEE ALSO
content:
gst-launch-0.10(1), gst-discoverer-0.10(1), gst-inspect-1.0(1), gst-launch-1.0(1), gst-discoverer-1.0(1)


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the GStreamer version information and exits.<br><br><b><b>--usage</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief usage message.<br><br><b><b>--plugins</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all registered GStreamer plugins, including their descriptions and ranks.<br><br><b><b>--elements</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all registered GStreamer elements, providing a summary of each.<br><br><b><b>--uris</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all supported URI protocols (e.g., file, http, rtp).<br><br><b><b>--types</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all registered GStreamer types.<br><br><b><b>--interfaces</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all registered GStreamer interfaces.<br><br><b><b>-a</b>, <b>--full</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all available information for an element or plugin, including properties, signals, and pad templates.<br><br><b><b>--print-plugin-auto-install-info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints details for plugin auto-installation.<br><br><b><b>--plugin</b> <I>PLUGIN</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inspects a specific plugin identified by its filename or name, rather than an element.<br><br><b><b>--licenses</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays license information for GStreamer components.<br><br><b><I>ELEMENT</I>|<I>PLUGIN</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific GStreamer element (e.g., <i>uridecodebin</i>, <i>vorbisdec</i>) or plugin name (e.g., <i>ogg</i>, <i>coreelements</i>) to inspect. If omitted, the command typically lists all elements or provides general information.<br><br>


title: DESCRIPTION
content:
The <b>gst-inspect-1.0</b> command is an essential command-line utility within the GStreamer multimedia framework. It allows users and developers to introspect and gain detailed information about installed GStreamer plugins, individual elements, and their supported capabilities.<br><br>It can list all available plugins and elements, search for specific components, or provide a comprehensive breakdown of an element's attributes, such as its properties, signals, and pad templates (which define how an element connects to others).<br><br>This tool is invaluable for debugging GStreamer pipelines, understanding the precise behavior and configuration options of an element, and discovering what multimedia functionalities (like codecs or protocols) are supported by the current GStreamer installation.


title: CAVEATS
content:
The output of <b>gst-inspect-1.0</b>, especially with the <b>--full</b> option, can be very verbose. It is often useful to pipe its output to pagination tools like <b>less</b> or filtering tools like <b>grep</b> to find specific information.<br><br>The command only reports on plugins and elements that are <i>installed</i> and <i>discoverable</i> by GStreamer. If a required plugin is missing or not correctly configured, it will not appear in the output.<br><br>Interpreting the detailed output (e.g., 'Pad Templates', 'Caps', 'Properties') requires a basic understanding of GStreamer's internal architecture and concepts.


title: USAGE EXAMPLES
content:
To inspect a specific element like <i>uridecodebin</i>:<br><code>gst-inspect-1.0 uridecodebin</code><br><br>To list all elements and filter for those related to MP3:<br><code>gst-inspect-1.0 --elements | grep mp3</code><br><br>To get full details about the <i>playbin</i> element and paginate the output:<br><code>gst-inspect-1.0 --full playbin | less</code>


title: INTERPRETING OUTPUT
content:
When inspecting an element with <b>gst-inspect-1.0</b>, you'll typically find sections like:<br><ul><li><b>Pad Templates</b>: Describe the element's connection points (<i>pads</i>), indicating whether they are source ('Src') or sink ('Sink') and the types of data they can handle (<i>capabilities</i> or <i>caps</i>).</li><li><b>Element Properties</b>: These are configurable options that modify an element's behavior. They can often be set in GStreamer pipelines or via application code.</li><li><b>Element Signals</b>: Events that an element can emit, allowing applications to react to changes or occurrences within the pipeline.</li><li><b>Element Capabilities (Caps)</b>: Detailed descriptions of the media formats an element can process or produce, including attributes like media type (e.g., 'audio/mpeg'), resolution, frame rate, and encoding details.</li></ul>


title: HISTORY
content:
GStreamer, and consequently its introspection tools like <b>gst-inspect</b>, originated in 1999 as a powerful and flexible multimedia framework. The `1.0` suffix in <b>gst-inspect-1.0</b> denotes its adherence to the GStreamer 1.x API series, which marked a significant evolution from the earlier 0.10 series. The 1.x branch was designed for long-term API/ABI stability and improved features, making <b>gst-inspect-1.0</b> the standard introspection tool for modern GStreamer installations. Its core functionality of providing detailed insights into multimedia components has remained vital throughout GStreamer's development.


title: SYNOPSIS
content:
<code><b>gst-install</b></code> [<i>OPTIONS</i>] [<i>PACKAGE_OR_COMPONENT</i>]...<br><br><i><I>Note: The syntax above is illustrative, as <code><b>gst-install</b></code> is not a standard command and its actual usage depends on its specific implementation.</I></i>


title: PARAMETERS
content:
<b><code><b>-h</b></code>, <code><b>--help</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><I>Displays help information about the command and its possible options.</I></i><br><br><b><code><b>-l</b></code>, <code><b>--list</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><I>Lists available GStreamer components (e.g., codecs, plugins) that can be installed.</I></i><br><br><b><code><b>-u</b></code>, <code><b>--update</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><I>Attempts to update existing GStreamer components or refresh the list of available packages.</I></i><br><br><b><code><b>-y</b></code>, <code><b>--yes</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><I>Assumes 'yes' to all prompts during the installation process, useful for non-interactive scripts.</I></i><br><br><b><code><b>--dry-run</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><I>Simulates the installation process without making any actual changes to the system.</I></i><br><br>


title: DESCRIPTION
content:
The <code><b>gst-install</b></code> command is <i><I>not a standard, universally available utility</I></i> on most Linux distributions. Instead, it typically refers to a custom script or a project-specific tool designed to simplify the installation of GStreamer-related components, such as multimedia codecs, plugins, or development libraries. Its primary purpose is to help users or developers set up a functional GStreamer environment by ensuring necessary dependencies and optional features are correctly installed and configured.<br><br>Because it is often a custom implementation, its exact functionality, available options, and installation methods can vary significantly depending on the GStreamer project, distribution, or specific environment it originates from. Users encountering <code><b>gst-install</b></code> usually find it within specific GStreamer SDKs, build instructions for certain multimedia applications, or community-driven scripts aimed at solving common GStreamer setup issues.


title: CAVEATS
content:
The <code><b>gst-install</b></code> command is <i><I>not a standard part of most Linux distributions</I></i>. Its presence, functionality, and exact syntax depend entirely on specific GStreamer projects, SDKs, or custom scripts. Users should always refer to the documentation or source code associated with the specific <code><b>gst-install</b></code> script they are using, as its behavior can vary significantly.<br><br>Using untrusted <code><b>gst-install</b></code> scripts can pose security risks, as they might execute commands with elevated privileges (often requiring <code><b>sudo</b></code>). Exercise caution and verify the source before execution.


title: IMPORTANT NOTE ON PARAMETERS
content:
<i><I>The parameters listed are illustrative examples of options commonly found in installer-like scripts. They may not be present in every custom implementation of <code><b>gst-install</b></code>, and other project-specific options might exist. Always consult the script's own help or documentation.</I></i>


title: TYPICAL USAGE CONTEXT
content:
<code><b>gst-install</b></code> is often found in development setups, specific software build instructions, or virtual machine provisioning scripts rather than as a command for general end-user system maintenance. Core GStreamer libraries and common plugins are usually installed via the distribution's standard package manager.


title: HISTORY
content:
The concept behind <code><b>gst-install</b></code> likely emerged from the need to simplify the setup of complex GStreamer environments, especially for developers or users who require specific sets of plugins or codecs not readily available through standard distribution repositories. Historically, installing all necessary GStreamer components could involve compiling from source, managing various GStreamer plugin sets (e.g., `GStreamer-bad`, `GStreamer-ugly`, `GStreamer-good`), and ensuring correct environment variables.<br><br>Custom <code><b>gst-install</b></code> scripts aim to automate these often tedious manual steps, making GStreamer adoption and development more accessible. Its usage is typically found in specific GStreamer SDKs or specialized build environments rather than as a general-purpose system tool.


title: SEE ALSO
content:
<code><b>gst-inspect-1.0(1)</b></code>: A GStreamer utility for inspecting available plugins and elements., <code><b>gst-launch-1.0(1)</b></code>: A GStreamer tool for constructing and running GStreamer pipelines., <code><b>apt(8)</b></code>, <code><b>dnf(8)</b></code>, <code><b>pacman(8)</b></code>: General package management commands typically used to install system-wide GStreamer libraries and codecs.


title: PARAMETERS
content:
<b><i>PIPELINE_DESCRIPTION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A string describing the GStreamer pipeline to be constructed and executed. This includes element names, their properties, and their connections.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output status information, property notifications, and debug messages during pipeline execution.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warnings and error messages, providing a cleaner output.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of the <i>gst-launch-0.10</i> command and exit.<br><br><b><b>--gst-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version of the GStreamer core library that <i>gst-launch-0.10</i> is linked against.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a summary of command-line options and exit.<br><br><b><b>-e</b>, <b>--eos-on-shutdown</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force an End Of Stream (EOS) event on shutdown, which helps ensure proper pipeline cleanup.<br><br><b><b>-t</b>, <b>--tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output tags (metadata) discovered within the media stream during pipeline operation.<br><br><b><b>-m</b>, <b>--messages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output GStreamer messages (e.g., error, warning, info) that occur within the pipeline.<br><br><b><b>--latency</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display pipeline latency statistics, useful for real-time applications.<br><br><b><b>--save-temps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save temporary files, such as Dot graphs of the pipeline, for debugging purposes.<br><br><b><b>--no-fault</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable installation of fault handlers, useful when debugging crashes with external tools.<br><br><b><b>--no-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output for messages, forcing plain text output.<br><br><b><b>--trace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable tracing of element operations for highly detailed debugging information.<br><br>


title: DESCRIPTION
content:
<i><b>gst-launch-0.10</b></i> is a command-line utility within the GStreamer multimedia framework, specifically designed for its 0.10 API series. It empowers users to construct and test GStreamer pipelines directly from the shell, eliminating the need for programming. A GStreamer pipeline is a sequence of interconnected multimedia elements—such as sources, filters, encoders, decoders, and sinks—that work together to process media data.<br><br>This tool is indispensable for rapid prototyping, debugging complex media playback or processing scenarios, and performing simple tasks like playing audio/video files, converting formats, or streaming. The '0.10' suffix in its name signifies its adherence to the older, now deprecated, GStreamer 0.10 API. While still present on some systems for backward compatibility, most modern GStreamer development and usage have transitioned to the 1.x series, primarily utilizing <i><b>gst-launch-1.0</b></i>.


title: CAVEATS
content:
<b><i>Deprecated Status:</i></b> <i><b>gst-launch-0.10</b></i> operates on the GStreamer 0.10 API series, which is deprecated. Modern GStreamer development and most current Linux distributions utilize the GStreamer 1.x series, accessed via <i><b>gst-launch-1.0</b></i>.<br><br><b><i>Compatibility:</i></b> Pipelines and plugins designed for GStreamer 0.10 are generally not compatible with GStreamer 1.x, and vice-versa, due to significant API changes. Users might encounter issues with plugin availability or functionality when mixing versions.<br><br><b><i>Security and Maintenance:</i></b> As an older version, GStreamer 0.10 and its associated tools like <i><b>gst-launch-0.10</b></i> no longer receive active development or security updates. For critical applications, using the latest stable GStreamer 1.x series is strongly recommended to ensure security and access to new features.


title: PIPELINE SYNTAX
content:
The <i>PIPELINE_DESCRIPTION</i> uses a simple, intuitive syntax where elements are declared and connected using the '<b>!</b>' symbol. Properties can be set on individual elements using the '<i>property=value</i>' format.<br><br><b>Examples:</b><br><i><b>Play an audio file:</b></i><br><i>gst-launch-0.10 filesrc location=audio.mp3 ! mad ! audioconvert ! autoaudiosink</i><br><br><i><b>Play a video file:</b></i><br><i>gst-launch-0.10 filesrc location=video.avi ! avidemux ! ffdec_h264 ! autovideosink</i><br><br><i><b>View a test pattern:</b></i><br><i>gst-launch-0.10 videotestsrc ! autovideosink</i>


title: HISTORY
content:
The GStreamer framework has undergone significant evolution since its inception. <i><b>GStreamer 0.10</b></i> served as a widely adopted and stable version for many years, forming the backbone of multimedia applications on various platforms. However, to address architectural limitations, introduce modern features (such as improved multi-threading support, advanced video acceleration, and OpenGL integration), and refine the API, the development team embarked on a major rewrite, culminating in the release of <i><b>GStreamer 1.0</b></i>.<br><br>This transition created a parallel API series. <i><b>gst-launch-0.10</b></i> was maintained on systems to provide backward compatibility for applications and scripts built against the older 0.10 API. While 1.x is now the actively developed and recommended version, 0.10 tools like <i><b>gst-launch-0.10</b></i> still exist on some systems for legacy purposes, highlighting the project's commitment to supporting existing deployments during the migration period.


title: SEE ALSO
content:
gst-launch-1.0(1), gst-inspect-0.10(1), gst-inspect-1.0(1), gst-discoverer-0.10(1), gst-discoverer-1.0(1)


title: PARAMETERS
content:
<b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be verbose, printing out information and debugging messages as the pipeline runs.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit on EOS (End of Stream), meaning the command terminates when the pipeline finishes processing all data.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be quiet, suppressing most normal output from the command.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print out the current pipeline to a dot file (requires Graphviz for visualization).<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print messages when elements transition to PREROLLING or PAUSED states during pipeline execution.<br><br><b><b>--gst-debug=</b><i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the default GStreamer debug level (e.g., GST_WARNING, GST_INFO, GST_DEBUG) for more detailed logging output.<br><br><b><b>--gst-plugin-path=</b><i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a specified directory to the GStreamer plugin search path.<br><br><b><b>--gst-plugin-load=</b><i>PLUGINS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load a comma-separated list of specific plugins before starting the pipeline.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print GStreamer version information and exit.<br><br><b><i>PIPELINE_DESCRIPTION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A string describing the GStreamer pipeline to be constructed, consisting of elements, their properties, and linking operators.<br><br>


title: DESCRIPTION
content:
<b>gst-launch-1.0</b> is a powerful command-line tool for building and running GStreamer multimedia pipelines. GStreamer is an open-source multimedia framework that allows developers to create various multimedia applications such as video editors, streaming media broadcasters, and media players. This command enables users to quickly prototype, test, and demonstrate complex GStreamer pipelines without writing any code. It constructs a pipeline from a textual description, connecting various GStreamer elements (sources, filters, encoders, decoders, sinks) together to process multimedia data. It's an indispensable tool for GStreamer development, debugging, and for performing quick media manipulation tasks directly from the terminal, making multimedia processing accessible and flexible.


title: CAVEATS
content:
Requires GStreamer and its necessary plugins to be installed on the system to function correctly. Constructing complex pipeline descriptions can be challenging for beginners. Error messages, while informative, sometimes require familiarity with GStreamer's internal workings. Real-time performance can vary significantly based on system resources and the complexity of the designed pipeline.


title: PIPELINE STRUCTURE BASICS
content:
A GStreamer pipeline defines the flow of multimedia data. It consists of interconnected <b>elements</b> (e.g., sources, filters, encoders, decoders, sinks). Elements are linked using the <b>!</b> operator (e.g., <b>filesrc ! decodebin ! autovideosink</b>). Properties of elements can be set using <b>property=value</b> (e.g., <b>filesrc location=video.mp4</b>). Data typically flows from source elements (like <b>filesrc</b>) through processing elements (like <b>decodebin</b>, <b>videoconvert</b>) to sink elements (like <b>autovideosink</b>, <b>filesink</b>).


title: COMMON USE CASES
content:
Playing media files: <b>gst-launch-1.0 filesrc location=video.mp4 ! decodebin ! autovideosink</b><br>Testing video/audio devices: <b>gst-launch-1.0 v4l2src ! autovideosink</b> (for webcam) or <b>gst-launch-1.0 audiotestsrc ! autoaudiosink</b><br>Transcoding media: <b>gst-launch-1.0 filesrc location=input.mp4 ! decodebin ! x264enc ! mp4mux ! filesink location=output.mp4</b><br>Basic streaming: <b>gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! udpsink host=127.0.0.1 port=5000</b>


title: HISTORY
content:
GStreamer was initially started by Erik Walthinsen in 1999. The <b>gst-launch</b> command has been a fundamental utility since GStreamer's early days, providing a quick way to test and prototype media pipelines directly from the command line. The transition from the older 0.10.x series to the GStreamer 1.x API brought significant improvements in stability, modularity, and API design. Consequently, <b>gst-launch-1.0</b> emerged as the standard tool for leveraging the robust GStreamer 1.x framework for modern multimedia development and usage.


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information.<br><br><b>--gst-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the GStreamer library version used by the player.<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colored output in the terminal.<br><br><b>--videosink=SINK</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the GStreamer factory name for the video output sink (e.g., <i>xvimagesink</i>, <i>glimagesink</i>).<br><br><b>--audiosink=SINK</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the GStreamer factory name for the audio output sink (e.g., <i>pulsesink</i>, <i>alsasink</i>).<br><br><b>--volume=VOLUME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial playback volume, a floating-point value between 0.0 (mute) and 1.0 (maximum).<br><br><b>--loop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays the specified media files in a continuous loop.<br><br><b>--fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays video in fullscreen mode if a video sink is active.<br><br><b>--display=DISPLAY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use for video output in an X11 environment.<br><br><b>--eos-on-shutdown</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures an End-of-Stream (EOS) event is sent before shutdown, useful for debugging.<br><br><b>--shuffle</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays multiple specified media files in a random order.<br><br><b>--subtitle-file=FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads an external subtitle file (e.g., SRT format) for playback.<br><br><b>--start-time=TIME_NANO</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts playback at a specific time, specified in nanoseconds (GstClockTime).<br><br><b>--stop-time=TIME_NANO</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops playback at a specific time, specified in nanoseconds (GstClockTime).<br><br><b>--profile=PROFILE_FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables profiling of the GStreamer pipeline and saves the data to the specified file for analysis.<br><br>


title: DESCRIPTION
content:
<i>gst-play-1.0</i> is a user-friendly command-line multimedia player built on the robust GStreamer framework. It offers a straightforward method to play various media files and URIs without requiring the manual construction of complex GStreamer pipelines. Unlike <i>gst-launch-1.0</i>, which is designed for building and testing custom pipelines, <i>gst-play-1.0</i> serves as a quick, ready-to-use player that abstracts away the underlying GStreamer complexities. It intelligently detects and utilizes available audio and video sinks and decoders, making it convenient for basic playback, verifying GStreamer installations, or quickly previewing media content from local storage or network streams. Its simplicity makes it an excellent choice for everyday multimedia playback needs.


title: CAVEATS
content:
<i>gst-play-1.0</i> relies heavily on the installed GStreamer plugins. Without the necessary plugins for specific media formats (codecs) or hardware acceleration, playback might fail, be inefficient, or lack features. It is primarily a basic playback utility; for advanced media manipulation, complex pipeline debugging, or custom multimedia processing, <i>gst-launch-1.0</i> offers much greater control and flexibility. The <i>--volume</i> option affects only the GStreamer pipeline's internal volume, not necessarily the system's master volume.


title: INTERACTIVE CONTROLS
content:
During playback, <i>gst-play-1.0</i> often provides basic interactive keyboard controls, such as <i>space</i> to pause/play, <i>q</i> to quit, and arrow keys for seeking, depending on the terminal and GStreamer version. These are runtime features and not exposed as command-line options.


title: GSTREAMER ENVIRONMENT VARIABLES
content:
Like other GStreamer utilities, <i>gst-play-1.0</i> respects various GStreamer environment variables. Examples include <i>GST_DEBUG</i> for detailed logging, <i>GST_PLUGIN_PATH</i> for specifying custom plugin directories, and <i>GST_REGISTRY_FORK</i> for controlling plugin scanning behavior. Utilizing these variables can significantly influence the player's operation and aid in debugging.


title: HISTORY
content:
<i>gst-play-1.0</i> is an integral part of the GStreamer 1.0 series, which marked a significant evolution from the older 0.10 series with its release in 2012. While the GStreamer framework itself has been under continuous development since 1999, <i>gst-play-1.0</i> emerged as a more modern and user-friendly player. Its development aimed to provide a stable, high-level interface for common multimedia playback scenarios, abstracting the complexities of pipeline construction and leveraging the modularity and extensibility inherent in the GStreamer framework. It serves as a convenient alternative to the more intricate <i>gst-launch</i> for quick media consumption.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits, outlining the command's basic usage and available options.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information for the <I>gst-typefind-0.10</I> utility and the GStreamer core library it's linked against.<br><br>


title: DESCRIPTION
content:
The <b>gst-typefind-0.10</b> command is a diagnostic utility from the GStreamer 0.10 series of the multimedia framework. Its primary function is to analyze the content of a specified file and attempt to determine its media MIME type (e.g., <I>video/mp4</I>, <I>audio/mpeg</I>, <I>image/jpeg</I>).<br><br>It achieves this by utilizing GStreamer's internal typefinding mechanisms, which inspect file headers and patterns to match them against known media formats and codecs. This tool is invaluable for developers and users troubleshooting multimedia playback issues, verifying file formats, or understanding what kind of media data a file contains. While the <I>-0.10</I> suffix indicates it belongs to an older, but historically significant, branch of GStreamer, the core functionality of type detection remains fundamental across GStreamer versions.


title: CAVEATS
content:
This command is part of the older GStreamer 0.10 series, which is largely superseded by the GStreamer 1.x series. Consequently, it may not support newer audio/video codecs or file formats introduced after the 0.10 branch ceased active development. Users are generally advised to use the more current <I>gst-typefind</I> (without the <I>-0.10</I> suffix) or <I>gst-discover</I> tools from the GStreamer 1.x ecosystem for modern media analysis.


title: USAGE EXAMPLE
content:
To determine the MIME type of a video file named <I>my_video.mp4</I>, you would run:<br><br><code><b>gst-typefind-0.10</b> my_video.mp4</code><br><br>The output would typically be something like: <I>video/quicktime</I> (for MP4 files, GStreamer sometimes identifies it as quicktime due to container similarities) or <I>audio/mpeg</I> for an MP3 file.


title: HISTORY
content:
The <I>gst-typefind-0.10</I> command was a standard utility included with the GStreamer 0.10 multimedia framework, which was a dominant version of GStreamer for many years. It was developed to provide a quick and reliable way to identify media types, crucial for GStreamer's dynamic pipeline construction. Although the 0.10 series has been largely succeeded by GStreamer 1.x, tools like <I>gst-typefind</I> formed the foundation for similar utilities in modern GStreamer, demonstrating the consistent need for robust media introspection capabilities.


title: PARAMETERS
content:
<b><i>FILE</i>|<i>URI</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files or URIs to be analyzed by the utility.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options for <b>gst-typefind-1.0</b>.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>gst-typefind-1.0</b> utility and the GStreamer library.<br><br><b><b>-a</b>, <b>--allow-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs all possible <i>MIME type</i> matches found for the input, not just the one with the highest confidence. Each match will include its associated confidence level.<br><br><b><b>-c</b> <i>&lt;confidence&gt;</i>, <b>--min-confidence=</b><i>&lt;confidence&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum confidence level (an integer from <i>0 to 100</i>) required for a <i>MIME type</i> to be reported. Typefind results below this threshold will be ignored. The default minimum confidence is <i>100</i>.<br><br>


title: DESCRIPTION
content:
<b>gst-typefind-1.0</b> is a utility from the <b>GStreamer</b> multimedia framework designed to determine the <i>MIME type</i> of media files or URIs. It works by analyzing the content of the provided input, rather than relying solely on file extensions. This process involves using <b>GStreamer's</b> extensive collection of <i>typefind plugins</i>, which are capable of recognizing various audio, video, and container formats by examining their unique byte patterns and headers. The command is crucial for applications that need to dynamically identify the media type before processing or playing, ensuring that the correct decoders and elements are used. It can report the most confident match or, optionally, all potential matches with their respective confidence levels. Its ability to inspect raw data makes it a robust tool for identifying even misnamed or extension-less media files within a Linux environment.


title: CAVEATS
content:
<ul><li>Results are dependent on the installed <b>GStreamer</b> <i>typefind plugins</i>. If a plugin for a specific format is missing, that type may not be identified correctly or at all.</li><li>Typefinding is a heuristic process and not always <i>100%</i> accurate, especially for corrupted, incomplete, or ambiguous files. Confidence levels indicate the certainty of the match.</li><li>For very large files, the initial probing might take a moment, although <b>gst-typefind-1.0</b> generally only reads a small portion of the file to determine its type, minimizing I/O.</li></ul>


title: HOW IT WORKS
content:
Unlike simple file extension checks, <b>gst-typefind-1.0</b> inspects the actual binary content of files. It reads initial bytes (often called '<i>magic bytes</i>') and looks for specific patterns or headers that uniquely identify various media formats. This process relies on <b>GStreamer's</b> <i>typefind plugins</i>, each specialized in recognizing particular formats like <i>MP3</i>, <i>MP4</i>, <i>WebM</i>, <i>Ogg</i>, etc. The plugins return a confidence level, indicating how certain they are about the identified type, allowing for robust and accurate media classification.


title: ROLE IN GSTREAMER
content:
The typefinding capability provided by <b>gst-typefind-1.0</b> is fundamental to how <b>GStreamer</b> applications handle media. When an application needs to play or process a file, it first uses typefinding to determine the file's format. This information is then used to select the appropriate <b>GStreamer</b> source elements, demuxers, and decoders needed to construct a functional multimedia pipeline. This dynamic identification process allows <b>GStreamer-based</b> applications to handle a wide variety of media formats seamlessly without requiring explicit format declarations from the user.


title: HISTORY
content:
The <b>gst-typefind-1.0</b> command is an integral part of the <b>GStreamer 1.x</b> series, which represents a significant evolution from the older <b>GStreamer 0.10.x</b> branch. It was developed to provide a robust and extensible mechanism for identifying media formats within the <b>GStreamer</b> ecosystem. Its functionality builds upon the core typefinding capabilities of <b>GStreamer</b>, leveraging a plugin-based architecture that allows for easy expansion and support for new media types as they emerge. The '<b>1.0</b>' suffix signifies its adherence to the stable API of the <b>GStreamer 1.x</b> branch, ensuring long-term compatibility and reliability for applications that rely on <b>GStreamer</b> for media processing.


title: SYNOPSIS
content:
<b>gst-visualise-0.10</b> [<I>GSTREAMER_OPTIONS</I>] [<I>PIPELINE_DESCRIPTION</I> | <I>FILENAME</I>]


title: PARAMETERS
content:
<b><I>PIPELINE_DESCRIPTION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A string representing a GStreamer pipeline to be visualized. For example: "filesrc location=video.mp4 ! decodebin ! autovideosink".<br><br><b><I>FILENAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to a file containing a GStreamer pipeline description or a Graphviz DOT file generated by GStreamer's debug dumping mechanism (e.g., via <B>GST_DEBUG_DUMP_DOT_DIR</B>).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the GStreamer version information and exits.<br><br><b>--gst-debug-level=<I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the global GStreamer debug level (e.g., <I>1</I> for errors, <I>2</I> for warnings, <I>3</I> for informational, <I>4</I> for debugging, <I>5</I> for tracing).<br><br><b>--gst-plugin-path=<I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a directory to the GStreamer plugin search path.<br><br>


title: DESCRIPTION
content:
gst-visualise-0.10 is a graphical user interface (GUI) tool designed for the GStreamer 0.10 multimedia framework. Its primary purpose is to help developers and users understand, build, and debug complex GStreamer pipelines visually. <br><br>GStreamer pipelines are sequences of processing elements (plugins) connected to perform tasks like audio/video playback, recording, streaming, or editing. Manually interpreting these textual pipeline descriptions can be challenging. gst-visualise-0.10 addresses this by parsing a GStreamer pipeline (either from a command-line argument or loaded from a file) and rendering a graphical representation of its elements, their properties, and the data flow between them. <br><br>Users can interact with the visual graph to inspect element details, modify properties, and observe the state of the pipeline in real-time. This interactive visualization is invaluable for debugging issues such as broken links, incorrect element configurations, or performance bottlenecks, providing a clear overview of the data path. Although highly useful in its time, it specifically targets the now deprecated GStreamer 0.10 series.


title: CAVEATS
content:
gst-visualise-0.10 is specifically built for the GStreamer 0.10 series, which is now considered legacy and is no longer actively maintained. As such, it may not function correctly with GStreamer 1.x pipelines or plugins, nor will it benefit from modern GStreamer features or bug fixes. Users should be aware that finding compatible system libraries and documentation for this older version can be challenging. For current GStreamer development, alternative visualization methods are recommended.


title: GRAPHICAL USER INTERFACE (GUI)
content:
gst-visualise-0.10 operates primarily as a desktop application, providing an interactive window where users can visually construct, modify, and inspect GStreamer pipelines. It allows for drag-and-drop element placement, property editing, and real-time pipeline state monitoring, offering a more intuitive approach than command-line debugging.


title: DEBUGGING AND LEARNING TOOL
content:
Beyond simple visualization, gst-visualise-0.10 serves as an excellent educational and debugging tool. It helps in understanding the GStreamer element model, how elements connect via pads, and the various properties that control their behavior. This visual feedback is crucial for pinpointing errors in pipeline construction, such as type mismatch errors or missing links, and for observing buffer flow.


title: HISTORY
content:
gst-visualise-0.10 emerged as an important debugging and development aid during the lifecycle of the GStreamer 0.10 series. Its development was driven by the need for a graphical representation of increasingly complex multimedia pipelines, making it easier for developers to trace data flow, identify misconfigurations, and optimize performance. With the significant architectural changes introduced in GStreamer 1.x (released in 2012), gst-visualise-0.10 was not directly ported. Its functionality has largely been superseded by other methods, primarily using <B>GST_DEBUG_DUMP_DOT_DIR</B> to generate Graphviz <I>.dot</I> files, which can then be viewed with general-purpose graph visualization tools like <B>dot</B> itself. While still functional on systems with GStreamer 0.10 libraries, its active usage has dwindled considerably.


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information and exits.<br><br><b><I>FILE.xml</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the XML file containing the GStreamer pipeline definition.<br><br>


title: DESCRIPTION
content:
gst-xmllaunch-0.10 is a utility program provided with the GStreamer 0.10 multimedia framework. Its primary purpose is to parse and execute GStreamer pipelines defined in a structured XML file. This offers an alternative to constructing complex pipelines directly on the command line using gst-launch-0.10, promoting more readable and manageable pipeline definitions, especially for intricate setups involving multiple elements, properties, and interconnections. The XML schema typically describes GStreamer elements, their associated properties, and how they link together via pads. Upon execution, gst-xmllaunch-0.10 interprets this XML, builds the corresponding GStreamer pipeline graph, and runs it. While powerful for its time, this specific version targets the older GStreamer 0.10 series, which has largely been superseded by the 1.x series.


title: CAVEATS
content:
<ul><li><b>Legacy Version:</b> This command is specific to the GStreamer 0.10 series, which is now considered legacy and deprecated. Modern GStreamer development and applications primarily use the 1.x series.</li><li><b>XML Schema:</b> The XML file must adhere to a specific GStreamer XML pipeline schema. Incorrect XML formatting or invalid element/property definitions will lead to errors.</li><li><b>Limited Debugging:</b> Debugging issues within the XML structure itself can sometimes be less straightforward than with gst-launch's command-line approach, although GStreamer's standard debug flags can still be used.</li></ul>


title: XML PIPELINE STRUCTURE
content:
An example XML pipeline for <I>gst-xmllaunch-0.10</I> typically defines elements, their properties, and their connections, often looking like this:<br><I>&lt;pipeline&gt;</I><br><I>&nbsp;&nbsp;&lt;element name="source" factory="filesrc"&gt;</I><br><I>&nbsp;&nbsp;&nbsp;&nbsp;&lt;property name="location"&gt;video.mp4&lt;/property&gt;</I><br><I>&nbsp;&nbsp;&lt;/element&gt;</I><br><I>&nbsp;&nbsp;&lt;element name="decoder" factory="decodebin2"/&gt;</I><br><I>&nbsp;&nbsp;&lt;link src="source" sink="decoder"/&gt;</I><br><I>&lt;/pipeline&gt;</I><br>This demonstrates defining elements by their <I>factory</I> name, setting <I>properties</I>, and linking them together.


title: MIGRATION TO GSTREAMER 1.X
content:
Users transitioning from GStreamer 0.10 to 1.x should be aware that <I>gst-xmllaunch-0.10</I> has no direct 1.x equivalent. Pipelines previously defined in XML for 0.10 would need to be re-expressed using <I>gst-launch-1.0</I> syntax or constructed programmatically within GStreamer 1.x applications.


title: HISTORY
content:
gst-xmllaunch-0.10 was developed as part of the GStreamer 0.10 release cycle. It aimed to provide a more robust and organized method for defining complex multimedia pipelines, moving beyond the limitations of single-line command-line arguments. While innovative for its time, the 0.10 series was eventually succeeded by the GStreamer 1.x series in 2012. Consequently, gst-xmllaunch-0.10 and its associated XML pipeline concept are no longer actively maintained or used in new GStreamer 1.x based projects, which typically rely on direct gst-launch-1.0 commands or programmatic pipeline construction within applications.


title: SYNOPSIS
content:
<I>gsutil</I> [<B>GLOBAL_OPTIONS</B>] <B>COMMAND</B> [<B>COMMAND_OPTIONS</B>] [<B>ARGUMENTS</B>...] <br><br>Common <B>COMMAND</B> examples:<br><I>gsutil</I> <B>cp</B> [<B>OPTIONS</B>] <I>SOURCE_URL</I> [<I>DEST_URL</I>...] <br><I>gsutil</I> <B>ls</B> [<B>OPTIONS</B>] [<I>URL</I>...] <br><I>gsutil</I> <B>mb</B> [<B>OPTIONS</B>] <I>BUCKET_URL</I> <br><I>gsutil</I> <B>rb</B> [<B>OPTIONS</B>] <I>BUCKET_URL</I> <br><I>gsutil</I> <B>rsync</B> [<B>OPTIONS</B>] <I>SOURCE_URL</I> <I>DEST_URL</I>


title: PARAMETERS
content:
<b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables parallel (multi-threaded/multi-processing) operations for faster transfers of large datasets or many small files.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode; suppresses non-error output.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output for troubleshooting.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables detailed debugging output, including HTTP headers and payload.<br><br><b>cp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy files and objects. Supports copying local files to Cloud Storage, Cloud Storage to local, and Cloud Storage to Cloud Storage.<br><br><b>ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List buckets and objects. Can list contents of a bucket or all buckets in a project.<br><br><b>mb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make bucket; creates a new Cloud Storage bucket.<br><br><b>rb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove bucket; deletes an empty Cloud Storage bucket.<br><br><b>rm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove objects; deletes one or more objects from a bucket. Use with <B>-r</B> for recursive deletion.<br><br><b>rsync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize contents of two directories or a local directory with a bucket, adding/deleting files as needed to make them identical.<br><br><b>acl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage access control lists (ACLs) for buckets and objects, allowing fine-grained permission control.<br><br><b>stat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display object metadata, such as ETag, content-type, creation time, and checksums.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Get help on <I>gsutil</I> global options or specific commands. E.g., '<I>gsutil help cp</I>'.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <I>gsutil</I> version information.<br><br>


title: DESCRIPTION
content:
<I>gsutil</I> is a powerful command-line tool, written in Python, for interacting with Google Cloud Storage. It is an essential component of the Google Cloud SDK, enabling users and scripts to perform a wide array of operations on buckets and objects. This includes creating and deleting buckets, uploading and downloading files, synchronizing directories, managing access control lists (ACLs), listing contents, and inspecting object metadata. <I>gsutil</I> is optimized for large-scale operations, featuring capabilities such as parallel (multi-threaded/multi-processing) transfers with the <B>-m</B> flag, automatic retries for transient errors, and cryptographic checksum validation for data integrity. Its design makes it ideal for automating cloud storage tasks in scripts and shell environments.


title: CAVEATS
content:
<I>gsutil</I> requires proper authentication with Google Cloud, typically managed via the <I>gcloud</I> command-line tool. All operations on Google Cloud Storage incur costs based on storage, network egress, and operations performed. Incorrect permissions (ACLs) can lead to unexpected access denials or, conversely, unintended public access to data. Be mindful of object versioning and lifecycle management policies configured on buckets, which can affect object deletion or modification.


title: AUTHENTICATION
content:
<I>gsutil</I> leverages the authentication mechanisms configured through the <I>gcloud</I> CLI. Users typically authenticate using <I>gcloud auth login</I> or configure service account keys, which <I>gsutil</I> then uses to authorize requests to Google Cloud Storage.


title: URI PATHS
content:
Cloud Storage resources are referenced using uniform resource identifiers (URIs) with the format <I>gs://BUCKET_NAME/OBJECT_NAME</I>. For example, <I>gs://my-bucket/my-file.txt</I> or just <I>gs://my-bucket</I> for a bucket.


title: WILDCARDS
content:
<I>gsutil</I> supports various wildcards in URI paths, including '*' for any number of characters, '?' for a single character, and '[]' for character sets, which is highly useful for operating on multiple objects matching a pattern.


title: HISTORY
content:
<I>gsutil</I> was developed by Google as the primary command-line interface for Google Cloud Storage. It is distributed as part of the Google Cloud SDK, a collection of tools for managing resources and applications on Google Cloud Platform. Written in Python, <I>gsutil</I> has been continuously evolved since its initial release to support new Cloud Storage features, improve performance, and enhance usability, becoming an indispensable tool for cloud architects and developers.


title: SYNOPSIS
content:
<B>gt</B> [GLOBAL_OPTIONS] &lt;TOOL&gt; [TOOL_OPTIONS] [ARGUMENTS]<br><br><I>Examples:</I><br><B>gt</B> <I>gff3</I> -tidy annotations.gff3<br><B>gt</B> <I>stat</I> genome.fa<br><B>gt</B> <I>seq</I> -showfasta -o output.fa input.fastq


title: PARAMETERS
content:
<b>-help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the <B>gt</B> command or the specified tool.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the GenomeTools suite.<br><br><b>-memlimit [bytes]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a limit on the total memory that can be allocated by <B>gt</B> processes.<br><br><b>-cpulimit [seconds]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a limit on the CPU time (in seconds) that can be used by <B>gt</B> processes.<br><br><b>-force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces overwriting of existing output files without prompting.<br><br><b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output messages, providing more detailed information during execution.<br><br><b>-warning</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates warning messages, which are typically suppressed by default.<br><br><b>-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output, useful for developers and advanced troubleshooting.<br><br><b>-output [filename]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects standard output to the specified file instead of the console.<br><br><b>-log [filename]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects log messages to the specified file.<br><br>


title: DESCRIPTION
content:
<I>Note: 'gt' is not a standard, universally available Linux command. This analysis refers to 'gt' as provided by the GenomeTools suite, a specialized toolkit for bioinformatics and genomics.</I><br><br>The <B>gt</B> (GenomeTools) command serves as the central entry point for a comprehensive open-source software system designed for genome analysis. It offers a rich collection of tools and libraries for processing genomic sequences, annotations (such as GFF3 and GTF formats), and alignment data. Its core functionalities include parsing, validating, and transforming common genome annotation formats, performing diverse sequence manipulations, building efficient data structures like suffix arrays, and providing a robust framework for developing custom bioinformatics applications. <B>gt</B> is widely utilized in genomics research for tasks ranging from fundamental sequence operations to more intricate comparative genomics and annotation processing workflows.


title: CAVEATS
content:
The <B>gt</B> command, as part of GenomeTools, is not installed by default on most Linux distributions. It requires separate installation, typically from source, a package manager (e.g., `apt install genometools-dev`), or through bioinformatics-specific environment managers like Conda. Its extensive functionality is highly specialized for bioinformatics and genomics tasks, making it less relevant for general system administration or common command-line operations. Many of its subcommands can be computationally intensive, requiring significant memory and CPU resources for large genomic datasets.


title: COMMON SUBCOMMANDS (TOOLS)
content:
The <B>gt</B> command functions as a dispatcher, invoking a wide array of specialized tools. Each tool (`<TOOL>`) addresses a specific genomic analysis task and has its own set of options. Here are a few frequently used subcommands:<br><br><B>gt gff3</B>: A versatile tool for manipulating, validating, and transforming GFF3 (General Feature Format, version 3) annotation files. It can check for syntax errors, canonicalize entries, and perform various filtering operations.<br><br><B>gt stat</B>: Used to compute comprehensive statistics on genomic sequence files (FASTA/FASTQ) or annotation files (GFF3/GTF), providing insights into their content and structure.<br><br><B>gt seq</B>: Provides functionalities for operating on sequence files, such as concatenating, reversing, complementing, and extracting subsequences, as well as converting between FASTA and FASTQ formats.<br><br><B>gt extractfeat</B>: Extracts annotated features (e.g., genes, CDS, exons) from genomic sequences based on the information provided in GFF3/GTF annotation files.<br><br><B>gt suffixerator</B>: A core tool for constructing advanced data structures like suffix arrays, enhanced suffix arrays (ESA), and suffix trees, which are fundamental for efficient string matching and sequence analysis algorithms.


title: HISTORY
content:
The GenomeTools project originated at the Center for Biotechnology (CeBiTec) at Bielefeld University in Germany. Its development began with a focus on efficient data structures for sequence analysis, particularly the implementation and application of suffix arrays. Over the years, it evolved into a comprehensive and modular software suite, driven by the increasing need for robust and standardized tools in genomics research. A significant emphasis has been placed on supporting standard file formats like GFF3 and GTF, ensuring interoperability within the bioinformatics ecosystem. Its development continues to be an ongoing, community-driven effort, adapting to the evolving challenges and demands of modern genomics.


title: SYNOPSIS
content:
<i>gtf</i>: <b>Command not found</b>.<br>This utility does not exist as a standard Linux command and will typically result in a 'command not found' error upon execution.


title: DESCRIPTION
content:
The command <i>gtf</i> is <b>not a standard or commonly recognized utility</b> in most Linux distributions. It is highly probable that the query refers to the <b>Gene Transfer Format (GTF)</b>, which is a text-based file format used extensively in bioinformatics to describe gene and genomic feature annotations. While numerous specialized bioinformatics tools exist to process GTF files (e.g., for gene quantification, transcriptome assembly, or format conversion), there is no generic Linux command simply named <i>gtf</i> that performs these operations by default. The term 'GTF' exclusively refers to the file format, not an executable program itself in standard Linux environments.


title: CAVEATS
content:
This command does not exist as a standard Linux utility. Users seeking to process <b>GTF files</b> should consult documentation for specific bioinformatics tools designed for reading, parsing, converting, or analyzing genomic annotations stored in this format. Attempting to run 'gtf' will only yield an error.


title: GTF FILE FORMAT EXPLAINED
content:
The <b>Gene Transfer Format (GTF)</b> is a specific tab-separated text file format primarily used in genomics to annotate gene structure. It shares similarities with the GFF3 format but has stricter conventions, particularly for gene and transcript features. A GTF file typically consists of nine columns:<br>1. Chromosome name<br>2. Source (e.g., Ensembl, Havana)<br>3. Feature type (e.g., 'exon', 'CDS', 'start_codon')<br>4. Start coordinate<br>5. End coordinate<br>6. Score (usually '.' or a numeric value)<br>7. Strand ('+' or '-')<br>8. Frame (0, 1, 2 for CDS features, '.' otherwise)<br>9. Attributes (a semicolon-separated list of 'key "value"' pairs, including 'gene_id' and 'transcript_id').


title: HISTORY
content:
There is no documented history for a standard Linux command named <i>gtf</i>, as it is not part of common Linux distributions. The acronym 'GTF' itself originates from the bioinformatics community, specifically describing a well-defined format for genomic annotations, first introduced as part of the Ensembl project specifications.


title: SEE ALSO
content:
<I>gffread</I>(1) (A utility often used for converting and manipulating GFF/GTF files, part of the StringTie/Cufflinks suite.), <I>bedtools</I>(1) (A versatile suite of tools for genomic feature manipulation, which can interact with GTF files for various operations like intersecting or merging.), <I>featureCounts</I>(1) (A program for quantifying reads against genomic features defined in GTF or GFF files.), <I>stringtie</I>(1) (A tool for transcriptome assembly and quantification that utilizes GTF annotations.)


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <i>gThumb</i>'s help options, including common and application-specific options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the <i>gThumb</i> application version information and exits.<br><br><b><b>--browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>gThumb</i> directly in browser mode, showing your image collection.<br><br><b><b>--viewer</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>gThumb</i> in viewer mode, typically showing the first specified image.<br><br><b><b>--fullscreen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches <i>gThumb</i> in a full-screen view, ideal for presentations or immersive viewing.<br><br><b><b>--slideshow</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a slideshow of the provided images or the current directory's contents.<br><br><b><b>--geometry=WIDTHxHEIGHT+X+Y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial size and position of the <i>gThumb</i> window.<br><br><b><b>--show-editor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens <i>gThumb</i> with the image editor panel activated for quick adjustments.<br><br><b><b>--import</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the image import wizard to transfer photos from devices or folders.<br><br><b><b>--new-window</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>gThumb</i> to open in a new window, even if an instance is already running.<br><br><b><b>--select-album=ALBUM_NAME</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens <i>gThumb</i> directly to the specified album.<br><br><b><b>--select-tag=TAG_NAME</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the view to show only images associated with the given tag.<br><br><b><b>--disable-metadata-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>gThumb</i> from using its metadata cache, potentially useful for debugging or when metadata changes frequently outside <i>gThumb</i>.<br><br>


title: DESCRIPTION
content:
<i>gThumb</i> is a powerful and versatile image viewer, browser, and organizer designed for the GNOME desktop environment. It provides a comprehensive set of features for managing and interacting with digital photographs. Users can easily browse their image collections, organize photos into albums, apply tags for efficient categorization, and locate images by various criteria.<br><br>Beyond basic viewing, <i>gThumb</i> includes essential image editing capabilities such as rotating, cropping, resizing, color adjustment, and red-eye removal. It also supports importing images from cameras or external devices, batch renaming, converting image formats, and creating web albums. Its intuitive interface makes it suitable for both casual viewing and more organized photo management. <i>gThumb</i> aims to be a complete solution for digital photography needs within the GNOME ecosystem, balancing ease of use with rich functionality. It supports a wide array of image formats, including JPEG, PNG, GIF, TIFF, and RAW formats through specific libraries.


title: CAVEATS
content:
While <i>gThumb</i> offers robust basic editing, it is not a substitute for professional-grade image manipulation software like GIMP or Photoshop. Its performance with extremely large, unindexed collections might be slower, and RAW file support relies on external libraries (like <i>libraw</i>), which may require additional installation or configuration for optimal performance with all camera models.


title: EXTENSIBILITY AND PLUGINS
content:
<i>gThumb</i> supports various plugins that extend its functionality, such as importing from specific online services, exporting to web galleries, and advanced batch operations. These plugins enhance its versatility beyond the core application.


title: METADATA HANDLING
content:
<i>gThumb</i> extensively uses image metadata (EXIF, IPTC, XMP) for organizing, searching, and displaying information about photos. It allows users to view and some cases edit this metadata, which is crucial for professional and amateur photographers alike.


title: HISTORY
content:
<i>gThumb</i> has been a staple in the GNOME desktop environment since its early days, initially developed by Paolo Bacchilega. It emerged as a user-friendly alternative to more complex image viewers and a more structured photo manager than simple file browsers. Over the years, <i>gThumb</i> has undergone significant development, adapting to changes in GTK+ toolkits (moving from GTK2 to GTK3 and GTK4) and integrating deeper with the GNOME ecosystem's evolving design principles. Its development has consistently focused on balancing intuitive usability with expanding features for image viewing, organizing, and light editing, making it a reliable choice for GNOME users for over two decades.


title: PARAMETERS
content:
<b>-?</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message indicating common usage.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays more comprehensive help options for the command, including available arguments and options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the version information of the <code>gtk-launch</code> utility.<br><br><b>APPLICATION...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more names of the applications to launch. These names typically correspond to the filename (without the <i>.desktop</i> extension) of the application's desktop entry, e.g., 'firefox' for <i>firefox.desktop</i>.<br><br><b>ARGUMENT...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments to pass directly to the launched application. These arguments are appended to the command specified in the <i>Exec</i> key of the <i>.desktop</i> file.<br><br>


title: DESCRIPTION
content:
<code>gtk-launch</code> is a command-line utility for launching applications registered with the GIO (Glib Input/Output) subsystem, which is fundamental to GTK-based desktop environments. Instead of requiring the user to know the exact path to an executable, <code>gtk-launch</code> allows applications to be started by their symbolic name, as defined in a <i>.desktop</i> file. These <i>.desktop</i> files adhere to the XDG Desktop Entry Specification and typically reside in standard directories like <i>~/.local/share/applications</i> or <i>/usr/share/applications</i>.<br><br>When invoked, <code>gtk-launch</code> parses the specified application's <i>.desktop</i> file to retrieve information such as the executable path and any default arguments defined in the <i>Exec</i> key. Any additional arguments provided on the command line are then appended to this command before execution. This mechanism provides a standardized and user-friendly way to integrate and launch applications within a desktop environment, abstracting away the underlying complexity of their execution paths and initial parameters.


title: CAVEATS
content:
<ul><li><code>gtk-launch</code> relies entirely on the presence and correctness of <i>.desktop</i> files in standard XDG application directories. If a <i>.desktop</i> file is missing, misnamed, or malformed, the application may fail to launch or <code>gtk-launch</code> may report an error.</li><li>It is designed to launch applications defined by <i>.desktop</i> entries, not arbitrary executable paths or shell commands. For general command execution, use a shell directly.</li><li>The security of <code>gtk-launch</code> is dependent on the integrity of <i>.desktop</i> files. Maliciously crafted <i>.desktop</i> files could potentially execute unwanted commands.</li></ul>


title: XDG DESKTOP ENTRY SPECIFICATION
content:
The behavior of <code>gtk-launch</code> is governed by the XDG Desktop Entry Specification. This standard defines the format of <i>.desktop</i> files, which are simple configuration files used to describe applications, their icons, categories, and most importantly, how they are launched via the <i>Exec</i> key. <code>gtk-launch</code> parses these files to execute the appropriate command.


title: APPLICATION SEARCH PATHS
content:
<code>gtk-launch</code> searches for <i>.desktop</i> files in a predefined set of directories, typically following the XDG Base Directory Specification. Common search paths include: <br><i>~/.local/share/applications/</i> (for user-specific applications)<br><i>/usr/local/share/applications/</i> (for system-wide, locally installed applications)<br><i>/usr/share/applications/</i> (for system-wide, packaged applications)


title: HISTORY
content:
<code>gtk-launch</code> is an integral part of the GTK toolkit, specifically leveraging the GIO library for application management. Its development stems from the need for a standardized, desktop-agnostic method of launching applications based on their semantic names rather than direct paths. It has evolved alongside the XDG Desktop Entry Specification, becoming a common utility in Linux desktop environments to ensure consistent application launching behavior across various desktop shells like GNOME, KDE, Xfce, etc.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message, detailing the available command-line options for <b>gtk-query-immodules-2.0</b>.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the version information of the <b>gtk-query-immodules-2.0</b> program.<br><br><b><b>--update-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the input method module cache file. This is the main operation of the command, and it is often run without any additional arguments, writing the cache to the default GTK+ 2.x cache location.<br><br>


title: DESCRIPTION
content:
The <b>gtk-query-immodules-2.0</b> command is a utility for the GTK+ 2.x toolkit. Its primary function is to query all installed input method (IM) modules and compile their information into a cache file. This cache file is then used by GTK+ 2.x applications to efficiently find and load the appropriate input methods.<br><br>Input methods are essential for handling complex text input, such as typing characters for East Asian languages (e.g., Chinese, Japanese, Korean) or entering special symbols and characters not directly available on a standard keyboard layout. By providing a cached list of available modules, <b>gtk-query-immodules-2.0</b> helps GTK+ applications launch faster and correctly support various input requirements.<br><br>This command is typically executed automatically by the system or package manager when GTK+ 2.x is installed or updated, rather than being manually invoked by users.


title: CAVEATS
content:
This command is primarily an internal utility of the GTK+ 2.x toolkit. It is generally executed automatically by the system or package manager upon GTK+ 2.x installation or updates. Manual invocation is typically only necessary for troubleshooting input method issues, such as missing language support or incorrect character input in GTK+ 2.x applications.


title: CACHE FILE LOCATION
content:
The generated cache file, typically named <i>immodules.cache</i>, is usually stored in a system-wide GTK+ 2.x data directory (e.g., <code>/usr/lib/gtk-2.0/2.10.0/</code> or <code>/usr/lib/gtk-2.0/</code>), or sometimes in a user's home directory (e.g., <code>~/.gtk-2.0/</code>) for user-specific configurations. GTK+ applications use this file to quickly locate and load the necessary input method modules.


title: HISTORY
content:
<i>gtk-query-immodules-2.0</i> is a component of the GTK+ 2.x series, which was a widely used version of the GTK toolkit. Its role in generating the IM cache file became crucial for applications to correctly handle internationalized text input. With the advent of GTK+ 3.x and later 4.x, its direct successor, <i>gtk-query-immodules-3.0</i>, took over this responsibility for newer GTK applications, while <i>gtk-query-immodules-2.0</i> remains relevant for legacy GTK+ 2.x applications still in use.


title: PARAMETERS
content:
<b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the utility and exits.<br><br>


title: DESCRIPTION
content:
The <b>gtk-query-immodules-3.0</b> command is a utility provided by the GTK+ 3 toolkit. Its primary purpose is to generate a cache file, typically named <i>immodules.cache</i>, which lists all available input method (IM) modules on the system. <br><br>Input method modules are plugins that provide functionality for entering text in various languages, especially those that require complex input methods like Chinese, Japanese, Korean, or those with diacritics. By creating this cache, GTK+ 3 applications can quickly identify and load the necessary input modules without having to scan multiple directories every time they start, significantly improving application startup performance and ensuring correct input method functionality. <br><br>This command is not typically run directly by end-users. Instead, it is usually invoked automatically by system scripts, package managers (e.g., during GTK+ installation or updates), or build processes to maintain an up-to-date cache for GTK+ 3 applications.


title: CAVEATS
content:
This command is primarily an internal utility for the GTK+ 3 environment. It is not designed for direct user interaction in most cases.<br><br>Maintaining an up-to-date and correctly permissioned <i>immodules.cache</i> file is crucial for the proper functioning of input methods in GTK+ 3 applications. If the cache is missing or corrupted, input methods may not work as expected, leading to issues with typing in certain languages.<br><br>Running this command requires appropriate write permissions for the directory where the <i>immodules.cache</i> file is stored, typically a system-wide GTK+ library path.


title: CACHE FILE LOCATION
content:
The generated cache file, named <i>immodules.cache</i>, is typically stored in a specific GTK+ system directory. Common locations include paths similar to <i>/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/</i> or <i>/usr/lib/gtk-3.0/3.0.0/</i>, varying based on the operating system, distribution, and architecture. This file is vital for GTK+ applications to quickly find and load the correct input method modules.


title: ROLE OF INPUT METHOD MODULES
content:
Input Method (IM) modules are specialized plugins that handle the complex process of converting keyboard input into characters, especially for languages with large character sets (e.g., Chinese, Japanese, Korean), or those requiring diacritics or dead keys. They enable features like character composition, phonetic conversion, handwriting recognition, and virtual keyboards, ensuring users can accurately enter text in their native languages.


title: HISTORY
content:
<b>gtk-query-immodules-3.0</b> emerged as part of the GTK+ 3 toolkit, succeeding its GTK+ 2 counterpart, <b>gtk-query-immodules-2.0</b>. With the evolution of the GTK+ library from version 2 to version 3, many internal tools were updated to reflect the new architecture and conventions. Its core function of streamlining input method loading has remained consistent across GTK+ versions, playing a vital role in ensuring a smooth and efficient text input experience for users across diverse linguistic contexts.


title: SEE ALSO
content:
<b>gtk-query-immodules-2.0</b>(1), <b>gtk-update-icon-cache</b>(8), <b>gdk-pixbuf-query-loaders</b>(1), <b>locale</b>(1)


title: PARAMETERS
content:
<b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force recreation of the cache file, even if it appears up-to-date.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run silently, suppressing all warnings and non-error output.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing detailed information about the caching process.<br><br><b>--ignore-theme-dir</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not include the theme directory name in the cached paths. Useful for shared icon directories.<br><br><b>--index-theme</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include information from the theme's 'index.theme' file in the cache. This is important for theme inheritance.<br><br><b>--include-image-data</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Embed small icon image data directly into the cache file, potentially improving lookup speed for frequently used small icons.<br><br><b>ICON_THEME_DIR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The mandatory path to the GTK+ icon theme directory for which the cache should be updated.<br><br>


title: DESCRIPTION
content:
<i>gtk-update-icon-cache</i> is a utility program provided by the GTK+ toolkit. Its primary function is to create and update a cache file named <b>icon-theme.cache</b> within a specified GTK+ icon theme directory. This cache file acts as an index of all icons available within that theme, significantly speeding up the lookup process for GTK+ applications. Without this cache, applications would have to scan numerous directories and subdirectories every time they need to display an icon, leading to performance overhead. By pre-indexing the icons, <i>gtk-update-icon-cache</i> ensures that applications can quickly locate and load the necessary graphical assets, providing a smoother and more responsive user experience. It is typically run automatically by package managers when installing or updating icon themes, or it can be invoked manually by users or theme developers after making changes to an icon theme's contents.


title: CAVEATS
content:
Running this command requires write permissions to the specified <i>ICON_THEME_DIR</i>. If permissions are insufficient, the cache file cannot be created or updated. While beneficial for performance, this command does not automatically detect changes; it must be run explicitly after icon theme modifications.


title: USAGE CONTEXT
content:
This utility is most commonly invoked by package managers during the installation or upgrade of icon themes (e.g., through post-installation scripts). Users who manually install or modify icon themes located in their <b>~/.icons</b> directory or system-wide <b>/usr/share/icons</b> directories may also need to run this command manually to ensure their changes are recognized by GTK+ applications.


title: CACHE FILE
content:
The command generates an <b>icon-theme.cache</b> file inside the root of the specified icon theme directory. This binary file contains an optimized index of icon names, their paths, and metadata, allowing GTK+ applications to quickly locate the correct icon without extensively traversing the filesystem.


title: HISTORY
content:
The need for <i>gtk-update-icon-cache</i> arose with the increasing complexity and size of icon themes in the GTK+ environment. As icon themes grew to include hundreds or thousands of icons across various sizes and categories, scanning directories on every icon request became a significant performance bottleneck. Introduced in GTK+ 2.x, this utility provides a mechanism to pre-index icon locations, greatly improving the responsiveness of GTK+ applications that utilize icon themes. It has remained a fundamental part of the GTK+ ecosystem through GTK+ 3.x and continues to be essential for efficient icon rendering.


title: PARAMETERS
content:
<b><i>ICON_THEME_DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the icon theme directory to be cached.<br><br><b><b>--force</b>, <b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the update of the cache file, even if it appears to be up-to-date.<br><br><b><b>--quiet</b>, <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress non-error messages during the cache update process.<br><br><b><b>--ignore-theme-dir</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not write the <i>icon-theme.cache</i> file directly into the theme directory. This option is typically used when the cache is managed externally, e.g., by a system-wide cache directory.<br><br><b><b>--index-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only update or write the <i>index.theme</i> data within the cache, without including all icon data. Useful for themes that primarily rely on <i>index.theme</i> for structure.<br><br><b><b>--only-scalable</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include only scalable icons (e.g., SVG files) in the cache. Non-scalable (bitmap) icons will be ignored.<br><br><b><b>--validate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Validate the existing cache file for consistency and integrity.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for the command.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a brief help message and exit.<br><br>


title: DESCRIPTION
content:
<i>gtk-update-icon-cache-3.0</i> is a utility designed to create or update the icon theme cache file for GTK+ 3.x icon themes. This cache, typically named <i>icon-theme.cache</i>, resides within an icon theme directory and significantly speeds up icon lookup and loading times for GTK 3 applications. Without this cache, applications would have to scan the entire icon theme directory every time they need an icon, leading to performance bottlenecks.<br><br>The command scans a specified <i>ICON_THEME_DIR</i>, collects information about all icons present, and generates a binary cache file. This cache includes paths, sizes, and other metadata about the icons. It is crucial for proper icon rendering in GTK 3 environments. This utility is typically invoked by package managers, theme installers, or users after installing new icon themes or updating existing ones to ensure the cache is up-to-date and reflects the current state of the icon files. It specifically targets the GTK 3 API version, ensuring compatibility with applications built against that library.


title: CAVEATS
content:
This command is specifically designed for GTK+ 3.x icon themes. For older GTK+ 2.x themes, the <b>gtk-update-icon-cache</b> command (without the <i>-3.0</i> suffix) should be used. For newer GTK+ 4.x themes, <b>gtk-update-icon-cache-4.0</b> is the appropriate utility. Running this command on a directory not containing a valid GTK+ 3 theme (specifically, an <i>index.theme</i> file) may result in an error or an incomplete cache. Ensure that the user running the command has write permissions to the <i>ICON_THEME_DIR</i> to successfully create or update the <i>icon-theme.cache</i> file.


title: ICON CACHE FILE LOCATION
content:
The generated cache file, named <i>icon-theme.cache</i>, is typically found directly inside the <i>ICON_THEME_DIR</i>. For system-wide themes, this could be paths like <i>/usr/share/icons/&lt;theme_name&gt;/</i>, and for user-specific themes, <i>~/.local/share/icons/&lt;theme_name&gt;/</i>.


title: THE <I>INDEX.THEME</I> FILE
content:
Every valid GTK icon theme directory must contain an <i>index.theme</i> file. This file acts as a configuration file for the icon theme, providing metadata such as the theme's name, description, and inheritance hierarchy. <i>gtk-update-icon-cache-3.0</i> relies on this file to properly identify and process the icon theme.


title: HISTORY
content:
The <i>gtk-update-icon-cache</i> utility family emerged as a crucial component of the GTK+ toolkit to optimize icon loading. The original <b>gtk-update-icon-cache</b> was for GTK+ 2.x. As GTK+ evolved to version 3.x, API changes necessitated a separate, version-specific utility, leading to the creation of <b>gtk-update-icon-cache-3.0</b>. This separation ensures backward compatibility while allowing the toolkit to introduce new features and optimizations without breaking older applications. Its primary development focus has always been on improving performance and reliability for icon display within GTK-based desktop environments and applications.


title: SEE ALSO
content:
gtk-update-icon-cache(1), gtk-update-icon-cache-4.0(1), update-icon-caches(8), gdk-pixbuf-query-loaders(1), xdg-desktop-menu(1)


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available command-line options.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the installed <b>gtop</b> version.<br><br><b>--theme <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a color theme for the interface (e.g., "colorful", "dark", "light").<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable all color output in the terminal.<br><br><b>Dot-notation options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Many other configuration options are available via dot notation (e.g., <I>--processes.sort cpu</I>, <I>--network.interval 2000</I>) or through a global configuration file, allowing fine-grained control over various display aspects like refresh rates, process sorting, and visibility of specific metrics.<br><br>


title: DESCRIPTION
content:
<br><b>gtop</b> is an open-source, cross-platform system monitoring tool for the command line, designed to provide a visually rich overview of system resources. Unlike traditional Linux utilities like <b>top</b> or <b>htop</b>, <b>gtop</b> is built using <b>Node.js</b>, making it highly portable across Linux, macOS, and Windows environments, provided <b>Node.js</b> and <b>npm</b> are installed.<br><br>It presents real-time data on CPU usage, memory consumption, disk I/O, network activity, and process information using interactive, colorful graphs and lists. Users can sort, filter, and drill down into process details. Its modern interface and emphasis on clear visualizations make it a popular choice for developers and system administrators seeking an alternative to native tools, offering a dashboard-like experience directly within the terminal.


title: CAVEATS
content:
<br><i>gtop</i> is not a standard, pre-installed Linux utility. It requires <B>Node.js</B> and the <B>npm</B> package manager to be installed on your system. As a Node.js application, its performance can be influenced by the Node.js runtime and may consume more system resources compared to native compiled tools like <I>top</I> or <I>htop</I>. Its reliance on Node.js also means it needs to be installed globally via <I>npm</I> before it can be run as a command.


title: INSTALLATION
content:
<br>To install <I>gtop</I>, you must have <B>Node.js</B> and <B>npm</B> (Node Package Manager) installed. Then, execute the following command:<br><code>npm install -g gtop</code><br>The <I>-g</I> flag ensures it's installed globally and accessible as a command from anywhere in your terminal.


title: INTERACTIVE KEYBINDINGS
content:
<br>Once <I>gtop</I> is running, you can interact with it using various key presses:<br><I>q</I> or <I>Ctrl+C</I>: Quit the application.<br><I>k</I>: Kill a selected process (requires PID input).<br><I>s</I>: Sort processes (e.g., by CPU, memory).<br><I>f</I>: Filter processes.<br>Arrow keys: Navigate lists.<br>These shortcuts provide dynamic control over the displayed information.


title: HISTORY
content:
<br><I>gtop</I> was created by <B>aksakalli</B> and first released around <B>2016</B>. It quickly gained traction within the developer community as a modern, interactive, and visually appealing alternative to traditional system monitoring tools. Its cross-platform nature, built on the ubiquitous Node.js runtime, made it accessible to users across different operating systems, contributing to its widespread adoption, especially among those already familiar with the Node.js ecosystem. Its development reflects a trend towards more graphical and user-friendly command-line interfaces.


title: PARAMETERS
content:
<b><i>-b, --bind-host &lt;hostname&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the hostname or IP address <b>guacd</b> should bind to. Default is 0.0.0.0 (all interfaces).<br><br><b><i>-p, --bind-port &lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the TCP port <b>guacd</b> will listen on. Default is 4822.<br><br><b><i>-f, --foreground</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>guacd</b> from detaching and running as a background daemon. Useful for debugging or when running under a service manager like systemd.<br><br><b><i>-L, --log-level &lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the verbosity of logging. Possible levels include <i>trace</i>, <i>debug</i>, <i>info</i>, <i>warn</i>, and <i>error</i>. Default is <i>info</i>.<br><br><b><i>-l, --log-file &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file path where <b>guacd</b> should write its logs instead of standard error.<br><br><b><i>-P, --pid-file &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file path where <b>guacd</b> should write its process ID (PID).<br><br><b><i>-v, --version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of <b>guacd</b> and exits.<br><br><b><i>-h, --help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message listing all available command-line options and exits.<br><br>


title: DESCRIPTION
content:
<b>guacd</b> is the Guacamole proxy daemon, a fundamental component of the Apache Guacamole remote desktop gateway. It acts as a lightweight, language-agnostic proxy that mediates communication between the Guacamole web application (running in a servlet container like Tomcat) and various remote desktop servers.<br><br><b>guacd</b> understands standard remote desktop protocols such as VNC, RDP, and SSH. When a user connects to a remote desktop session through the Guacamole web application, the application establishes a connection to <b>guacd</b>. <b>guacd</b> then translates the Guacamole protocol messages into the respective native remote desktop protocol (e.g., VNC, RDP) and forwards them to the target remote desktop server.<br><br>This architecture ensures that no plugins or client software are required on the user's machine, as all protocol translation and communication with the remote server occur on the server where <b>guacd</b> runs. It typically listens on port 4822 by default and can be configured to run in the foreground or as a background service.


title: CAVEATS
content:
<b>Security:</b> <b>guacd</b> listens on a network port. It is crucial to restrict network access to this port (default 4822) using a firewall or by binding <b>guacd</b> to a specific internal IP address. Only trusted Guacamole web application instances should be able to connect to <b>guacd</b>.<br><br><b>Resource Usage:</b> Each active Guacamole connection consumes resources on the server running <b>guacd</b>, including CPU for protocol translation and memory for buffering. Scaling considerations are important for environments with many concurrent users.<br><br><b>Dependency:</b> <b>guacd</b> is a backend service and requires the <i>guacamole-client</i> web application to function as a complete remote access gateway. It does not provide a user interface on its own.


title: ARCHITECTURE OVERVIEW
content:
<b>guacd</b> operates as a crucial middleware in the Guacamole ecosystem. The Guacamole web application (running in a servlet container like Tomcat) establishes a WebSocket or HTTP tunnel connection with the user's browser. Simultaneously, the web application connects to <b>guacd</b> (typically on port 4822). <b>guacd</b> then establishes a connection to the target remote desktop server using the native protocol (VNC, RDP, SSH, etc.). All user input (keyboard, mouse) and remote display updates are relayed between the browser and the remote desktop server, with <b>guacd</b> performing the real-time protocol translation and proxying. This layered architecture enhances security by centralizing protocol handling and reduces the client-side burden.


title: HISTORY
content:
The Guacamole project, including <b>guacd</b>, began development around 2010. It was created to provide clientless remote desktop access through standard web browsers, leveraging HTML5 and JavaScript. The core idea was to eliminate the need for plugins or specialized client software, making remote access universally accessible. <b>guacd</b> was designed as the crucial bridging component, abstracting the complexities of various remote desktop protocols from the web application and handling the low-level communication. Over the years, Guacamole, and by extension <b>guacd</b>, have evolved to support a wider range of protocols and improve performance and security, becoming an Apache project.


title: SYNOPSIS
content:
<b>guake</b> [<i>OPTIONS</i>]<br><b>guake</b> --new-tab [<i>COMMAND</i>]<br><b>guake</b> --execute-command <i>COMMAND</i><br><b>guake</b> --toggle-visibility<br><b>guake</b> --show-hide


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show Guake's help message and exit.</i><br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show Guake's version information and exit.</i><br><br><b><b>--toggle-visibility</b>, <b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Toggles the visibility of the Guake window (show if hidden, hide if shown).</i><br><br><b><b>--show-hide</b>, <b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Similar to --toggle-visibility, but specifically shows if hidden and hides if shown, without starting if not running.</i><br><br><b><b>--new-tab</b>, <b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Opens a new tab in the Guake window. Optionally, a COMMAND can be specified to run in the new tab.</i><br><br><b><b>--rename-tab</b>, <b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Renames a specific tab by its index.</i><br><br><b><b>--rename-current-tab</b>, <b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Renames the currently active tab.</i><br><br><b><b>--execute-command</b>, <b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Executes a specified COMMAND in the current tab. If Guake is not running, it will be launched.</i><br><br><b><b>--preferences</b>, <b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Opens the Guake preferences window, allowing graphical configuration.</i><br><br><b><b>--quit</b>, <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Exits the running Guake instance.</i><br><br><b><b>--display</b> <i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the X display to use.</i><br><br><b><b>--geometry</b> <i>WIDTHxHEIGHT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the initial geometry of the Guake window.</i><br><br><b><b>--tab-name</b> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the name for a new tab created with --new-tab.</i><br><br><b><b>--no-global-hotkey</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Starts Guake without registering the global hotkey.</i><br><br><b><b>--allow-custom-command</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Allows the execution of custom commands specified in the preferences.</i><br><br>


title: DESCRIPTION
content:
Guake is a <i>highly customizable</i> drop-down terminal emulator designed for GTK-based desktop environments like Gnome. Inspired by the console found in games like Quake, it provides <i>instant access</i> to a terminal by pressing a single, user-definable hotkey, typically <kbd>F12</kbd>. Its primary advantage is its <i>speed and convenience</i>; it appears from the top of the screen when invoked and disappears when the hotkey is pressed again, allowing users to quickly execute commands without switching windows or interrupting their workflow. Guake supports <i>multiple tabs</i>, allowing users to organize different tasks within a single instance. It offers extensive configuration options, including font customization, color schemes, transparency levels, window geometry, and startup commands. This makes Guake an <i>invaluable tool</i> for developers, system administrators, and anyone who frequently uses the command line, enhancing productivity by keeping a powerful terminal readily available.


title: CAVEATS
content:
<i>Guake is primarily designed for GTK-based desktop environments. While it may function in other environments, its integration and appearance might not be optimal. It runs as a background process, consuming a small amount of system resources even when hidden. Users should ensure their hotkey does not conflict with other system shortcuts.</i>


title: CONFIGURATION
content:
<i>Guake's configuration is managed through its graphical preferences window, accessible via the --preferences option or from the right-click menu on its system tray icon. Settings are typically stored in DConf or a configuration file, allowing for persistence across sessions.</i>


title: SCRIPTING INTEGRATION
content:
<i>Guake supports executing custom commands upon startup or when a new tab is created, facilitating integration with scripts and development workflows. This can be configured to, for example, automatically SSH into a server or start a development server.</i>


title: HISTORY
content:
<i>Guake was created by Gael J. Grimaud and first released in 2007, drawing inspiration from the KDE equivalent, Yakuake, and the iconic in-game console from the Quake series. Its development aimed to provide a similar convenient, hotkey-activated drop-down terminal experience specifically for the Gnome and GTK+ environments. Over the years, it has gained a dedicated following due to its simplicity, speed, and extensive customization options, evolving with new features and improved stability while maintaining its core purpose of instant terminal access.</i>


title: PARAMETERS
content:
<b><b>--block=<i>BLOCKNAME</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the character map directly to the specified Unicode block. For example, to view mathematical symbols, you might use <i>--block="Mathematical Operators"</i>.<br><br><b><b>--character=<i>CHARACTER_CODEPOINT</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the character map and highlights the specified character code point. The code point should be provided in hexadecimal format, optionally prefixed with 'U+'. For instance, <i>--character=U+20AC</i> for the Euro sign or <i>--character=00A9</i> for the copyright symbol.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <i>gucharmap</i> and then exits immediately.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a comprehensive list of all available command-line options for <i>gucharmap</i> and then exits.<br><br><b><b>--display=<i>DISPLAY</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use. This is a common option for graphical applications running in an X environment, allowing the application to be displayed on a different screen or remote display.<br><br><b><b>--sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes X calls synchronous. While potentially useful for debugging purposes, this option can significantly slow down the application's performance.<br><br><b><b>--g-fatal-warnings</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes all warnings generated by the application to be treated as fatal errors, leading to the immediate termination of the application upon encountering a warning. This is primarily useful for developers during debugging.<br><br>


title: DESCRIPTION
content:
<i>gucharmap</i> is the official GNOME character map application, providing a user-friendly graphical interface to browse, search, and insert Unicode characters.<br><br>It serves as an essential tool for users needing to access special characters, symbols, or characters from various languages that are not readily available on standard keyboards. The application allows users to navigate through different Unicode blocks, view detailed properties of each character (such as its Unicode name, code point, and UTF-8 encoding), and copy selected characters directly to the clipboard for use in other applications. <i>gucharmap</i> also supports searching for characters by name or code point, making it efficient to locate specific symbols quickly.<br><br>As an integral part of the GNOME desktop environment, <i>gucharmap</i> integrates seamlessly, offering a robust and intuitive solution for Unicode character management and insertion.


title: CAVEATS
content:
<i>gucharmap</i> is a graphical application built with GTK and requires a running X server or Wayland compositor to function. It cannot be used from a purely command-line interface without a display environment.<br><br>While it supports a vast array of Unicode characters, its primary function is display and selection; it does not offer advanced font management or character design capabilities.<br><br>Being part of the GNOME desktop environment, it might have additional dependencies if installed on a system without a full GNOME setup.


title: UNICODE SUPPORT
content:
<i>gucharmap</i> is designed to support the latest or near-latest versions of the Unicode Standard. This ensures that users can access and utilize characters from the ever-expanding range of scripts and symbols defined by Unicode. The application's interface organizes characters logically by Unicode blocks, making navigation intuitive.


title: DESKTOP INTEGRATION
content:
As a native GNOME application, <i>gucharmap</i> is tightly integrated with other GNOME components and GTK-based applications. Characters copied from <i>gucharmap</i> are placed onto the system clipboard and can be pasted effortlessly into any application that supports text input, enhancing productivity for users working with diverse character sets.


title: HISTORY
content:
<i>gucharmap</i> has been a fundamental utility of the GNOME desktop environment since its early inception. Developed to provide users with an accessible way to browse and insert Unicode characters, its core functionality has remained consistent. Its evolution has focused on enhancing usability, keeping pace with updates to the Unicode Standard to ensure comprehensive character coverage, and integrating seamlessly with the broader GNOME ecosystem.


title: PARAMETERS
content:
<b>-quality N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output JPEG quality level. Accepted values range from <b>84</b> to <b>100</b>. The default is <b>95</b>. Note that Guetzli's quality scale is not directly comparable to other JPEG encoders (e.g., libjpeg).<br><br><b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a detailed log of the encoding progress to the console.<br><br><b>-print_psnr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Peak Signal-to-Noise Ratio (PSNR) and Butteraugli distance values for the processed image.<br><br><b>-memlimit N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum memory usage limit in <b>GiB</b>. The default is <b>6GiB</b>. This parameter is crucial for processing large images and can be increased if memory issues occur.<br><br><b>-num_threads N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of threads to use for processing. The default is <b>1</b>. While it can speed up batch processing of multiple images, a single image is still processed on a single thread.<br><br><b>-depth N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the optimization iteration depth, impacting compression efficiency and processing time. Higher values (up to <b>15</b>) result in more thorough optimization (slower, better compression). The default is <b>10</b>.<br><br>


title: DESCRIPTION
content:
<b>Guetzli</b> is a JPEG encoder developed by Google, specifically designed to create <i>high-quality</i> JPEG images with significantly smaller file sizes. Its core innovation lies in the use of a sophisticated psycho-visual model called <b>Butteraugli</b>, which attempts to identify and reduce visual artifacts that are less noticeable to the human eye. This allows Guetzli to achieve superior compression at a given perceived visual quality compared to traditional JPEG encoders.<br><br>While it excels at producing smaller files that maintain visual fidelity, Guetzli is known for being <i>computationally intensive</i>. It requires more processing time and memory than other encoders, making it less suitable for real-time applications but ideal for optimizing static web assets where perceived quality and file size are critical factors.


title: CAVEATS
content:
<b>Slow Processing:</b> Guetzli is notoriously slow, often taking minutes or even hours for a single high-resolution image.<br><b>High Memory Usage:</b> It can consume significant amounts of RAM, especially for very large images. Ensure sufficient memory or adjust the <b>-memlimit</b>.<br><b>Quality Scale:</b> The <b>-quality</b> parameter (84-100) is specific to Guetzli and does not directly map to quality settings in other JPEG encoders. Using values below 84 is generally not recommended due to visible artifacts.<br><b>Not for All Images:</b> While excellent for photographic content, its benefits may be less pronounced or even counterproductive for images with sharp lines, text, or graphic elements, where its artifacts might be more apparent.


title: WORKFLOW RECOMMENDATION
content:
Given its high computational cost, <b>Guetzli</b> is best utilized as a <i>final optimization step</i> for critical static web assets, such as hero images or high-traffic visuals. It is typically employed in an offline, batch processing workflow rather than in real-time image serving pipelines.


title: HISTORY
content:
<b>Guetzli</b> was developed by Google and publicly announced in <i>March 2017</i>. Its primary motivation was to create a new JPEG encoder that could produce visually indistinguishable images at smaller file sizes than existing methods. This was achieved by integrating Google's advanced <b>Butteraugli</b> perceptual metric into the encoding process. The name "Guetzli" is Swiss German for "cookie," a nod to its origin and purpose in web optimization.


title: PARAMETERS
content:
<b><b>-c</b> <I>EXPR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluate <I>EXPR</I> as a Scheme expression and exit.<br><br><b><b>-s</b> <I>SCRIPT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load and run the specified <I>SCRIPT</I> file. Subsequent arguments are passed to the script.<br><br><b><b>-l</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load the Scheme source <I>FILE</I> before evaluating any further expressions or scripts.<br><br><b><b>-L</b> <I>DIRECTORY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <I>DIRECTORY</I> to the module and extension load path, allowing Guile to find libraries.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debugging features for Guile programs, useful for tracing and breakpoints.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display Guile's version information and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a summary of command-line options and exit.<br><br><b><b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter an interactive read-eval-print loop (REPL) after processing all other command-line arguments.<br><br>


title: DESCRIPTION
content:
<b>guile</b> is the GNU Project's official extension language. It is a robust and flexible implementation of the Scheme programming language, a powerful dialect of Lisp. Designed primarily for embedding into applications written in C, C++, and other languages, Guile provides a seamless way to add scripting, configuration, and extensibility capabilities to software. It adheres to various Scheme standards (R5RS, R6RS, R7RS) and offers a rich set of features including modules, continuations, threads, and dynamic linking. Beyond its embedding role, <b>guile</b> also functions as a standalone interpreter for general-purpose scripting, rapid prototyping, and developing full-fledged applications, leveraging its extensive standard library and powerful JIT compiler.


title: CAVEATS
content:
While powerful, Guile's full potential often comes from its integration as an embedded language, which requires developers to interact with its C API. The performance characteristics of interpreted or JIT-compiled Scheme code can vary based on the workload. Compatibility with every nuance of various Scheme standards (R5RS, R6RS, R7RS) might not be 100% complete across all features, though it strives for high adherence. Users should consult the official Guile documentation for detailed information on specific standard compliance and embedding guidelines.


title: ENVIRONMENT VARIABLES
content:
Guile's behavior can be influenced by environment variables. Key ones include <b>GUILE_LOAD_PATH</b>, which specifies directories where Guile searches for Scheme source files and modules, and <b>GUILE_EXTENSIONS_PATH</b>, used for locating C extensions that Guile can load dynamically.


title: EMBEDDING CAPABILITIES
content:
While <b>guile</b> runs as a standalone interpreter, its primary design strength lies in its robust embedding capabilities. Developers can link the Guile library into their C/C++ applications, exposing Scheme as a powerful, high-level extension language. This allows end-users to customize, script, and extend applications using Guile, fostering a highly flexible and adaptable software ecosystem.


title: HISTORY
content:
Guile was initiated by the GNU Project in 1993, with Richard Stallman envisioning a single, universal extension language for GNU software, moving away from fragmented domain-specific languages like Emacs Lisp or Tcl. Scheme was chosen for its clean semantics, extensibility, and small core. Development has been continuous, with significant milestones including the introduction of a new compiler and JIT in Guile 2.0 (2009), further JIT improvements in 2.2 and 3.0 (2019). Guile has become a core component of the GNU system, serving as the extension language for applications like GnuCash, GNU TeXmacs, and parts of the GNU Build System, reinforcing its role as GNU's 'Ubiquitous Intelligent Language for Extensions'.


title: SYNOPSIS
content:
<b>guix package</b> <i>--install</i>=<i>PACKAGE</i>... [<i>OPTION</i>...]<br><b>guix package</b> <i>--remove</i>=<i>PACKAGE</i>... [<i>OPTION</i>...]<br><b>guix package</b> <i>--update</i> [<i>OPTION</i>...]<br><b>guix package</b> <i>--upgrade</i> [<i>OPTION</i>...]<br><b>guix package</b> <i>--search</i> <i>REGEX</i>... [<i>OPTION</i>...]<br><b>guix package</b> <i>--manifest</i>=<i>FILE</i> [<i>OPTION</i>...]<br><b>guix package</b> <i>--roll-back</i> [<i>OPTION</i>...]<br><b>guix package</b> <i>--list-generations</i> [<i>OPTION</i>...]<br><b>guix package</b> <i>--show</i>=<i>PACKAGE</i>... [<i>OPTION</i>...]


title: PARAMETERS
content:
<b>--install=PACKAGE...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Installs specified PACKAGEs into the current user profile. Can take multiple package specifications, e.g., 'bash@5.1'.</I><br><br><b>--remove=PACKAGE...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Removes specified PACKAGEs from the current user profile, effectively reverting the profile to a state without them.</I><br><br><b>--update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Updates the Guix channel definitions to their latest versions, fetching new package descriptions and build recipes.</I><br><br><b>--upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Upgrades all packages currently installed in the profile to their newest available versions based on the updated channels.</I><br><br><b>--search=REGEX...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Searches for packages whose name or description matches the given regular expression, displaying relevant results.</I><br><br><b>--manifest=FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Installs or updates packages specified in a declarative Guile Scheme manifest FILE, ensuring the profile's contents match its declaration.</I><br><br><b>--profile=PROFILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the user profile to operate on. If not given, the default `~/.guix-profile` is used for non-root operations.</I><br><br><b>--roll-back</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Reverts the current profile to its immediately preceding transactional generation, effectively undoing the last change.</I><br><br><b>--list-generations</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Lists all past generations of the current profile, showing their timestamps, associated operations, and disk usage.</I><br><br><b>--show=PACKAGE...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays detailed information about the specified PACKAGEs, including their dependencies, build inputs, and available versions.</I><br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Shows a preview of the operations that would be performed without actually modifying the profile or system, useful for verification.</I><br><br>


title: DESCRIPTION
content:
<b><I>guix package</I></b> is the primary command-line tool for users to interact with the GNU Guix package manager to manage software packages. It facilitates declarative installation, removal, upgrade, and querying of packages in a reproducible and transactional manner.<br><br>Unlike traditional package managers, <b><I>guix package</I></b> ensures that installations are purely functional, meaning dependencies are precisely specified and isolated, leading to reliable and rollback-able system configurations. It can manage packages for the current user's profile or for the entire system when run with root privileges. This command is central to leveraging Guix's unique features like transactional upgrades, declarative system configuration, and isolated software environments.


title: CAVEATS
content:
<ul><li>Requires <i>root</i> privileges for system-wide operations or manipulating system profiles (e.g., `/var/guix/profiles/system`).</li><li>Relies on Guix channels being up-to-date (`guix pull` and `guix package --update`) for accurate package information and successful builds.</li><li>Disk space consumption can be high due to storing all generations of profiles and immutable store paths for packages.</li><li>Network access is essential for fetching new packages, channel updates, and their cryptographic signatures.</li><li>Familiarity with Guile Scheme is beneficial for advanced usage, especially when defining custom packages or manifest files.</li></ul>


title: PROFILES AND GENERATIONS
content:
Unlike traditional package managers, <b><I>guix package</I></b> operates on user-specific "profiles" (symbolic links to immutable store paths) and maintains "generations" (historical snapshots of a profile). This allows for transactional upgrades, easy rollbacks to previous states, and multiple independent user environments without conflicts. Each operation typically creates a new generation, preserving the old one for easy reversion.


title: MANIFESTS
content:
A manifest is a Guile Scheme file that declaratively specifies a set of packages and their exact versions that a user wants installed in a profile. Using <b><I>guix package --manifest=FILE</I></b> allows for highly reproducible and shareable package configurations, ensuring that a specific environment can be recreated identically on different machines or at a later time.


title: HISTORY
content:
<b><I>guix package</I></b> is a core component of GNU Guix, which itself originated in 2012 as a project aiming to bring the Nix package manager's purely functional approach to the GNU system, using Guile Scheme for its definitions. The <b><I>guix package</I></b> command has been central from early on, providing the primary user-facing interface for managing software in a transactional, reproducible, and declarative way, aligning with Guix's core principles. Its development has mirrored the evolution of Guix, incorporating features like profile management, manifest support, and advanced querying capabilities, continuously improving the user experience while adhering to its functional programming paradigm.


title: SYNOPSIS
content:
<b>gulp</b> [<i>taskname</i>] [<i>options</i>]<br><b>gulp</b> [<i>command</i>] [<i>options</i>]<br><b>gulp</b> <i>--version</i>


title: PARAMETERS
content:
<b><i>--gulpfile &lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative <I>gulpfile.js</I> path to load.<br><br><b><i>--cwd &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative working directory to run gulp from.<br><br><b><i>--tasks</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print a formatted tree of all available tasks defined in the gulpfile.<br><br><b><i>--tasks-simple</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print a plain, unformatted list of available tasks.<br><br><b><i>--tasks-json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print tasks in JSON format for programmatic use.<br><br><b><i>--require &lt;module&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preload a Node.js module before running the gulpfile.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the global <I>gulp-cli</I> and local <I>gulp</I> package versions.<br><br><b><i>--verify</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verify global and local <I>gulp</I> version compatibility.<br><br><b><i>--compact-tasks</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hide tasks that are marked as hidden by description.<br><br><b><i>--continue</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue running subsequent tasks even if a task fails.<br><br><b><i>--silent</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable all logging output during task execution.<br><br><b><i>--series</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force all tasks to run sequentially (overrides default parallel for some cases).<br><br><b><i>--parallel</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force all tasks to run concurrently (overrides default series for some cases).<br><br><b><i>--no-color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output in the console.<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the gulp command and its options.<br><br><b><i>--log-level &lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the minimum log level for output (e.g., 'info', 'warn', 'error').<br><br><b><i>--log-timestamps</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add timestamps to log messages for better tracking.<br><br><b><i>--stack-trace</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the full JavaScript stack trace on error for debugging.<br><br>


title: DESCRIPTION
content:
Please note: <b>gulp</b> is not a standard Linux command built into the operating system. It is a popular <i>JavaScript task runner</i> primarily used in web development, built on <I>Node.js</I> and installed via <I>npm</I>.<br><br><b>gulp</b> automates repetitive development tasks such as code minification, compilation (e.g., Sass to CSS, TypeScript to JavaScript), concatenation, testing, and deployment. It operates on a 'code-over-configuration' paradigm, where tasks are defined using JavaScript in a file named <I>gulpfile.js</I>. This approach leverages Node.js streams for efficient file processing, allowing transformations to happen in memory without writing intermediate files to disk, leading to faster build times. It's highly extensible through a vast ecosystem of plugins, enabling developers to customize build workflows efficiently.


title: CAVEATS
content:
<b>gulp</b> is not a native Linux utility; it fundamentally relies on <I>Node.js</I> and its package manager <I>npm</I> being installed on the system. It functions as a project-specific tool, meaning you typically install a global <I>gulp-cli</I> for command-line access and a local <I>gulp</I> package as a development dependency within each project. Its entire functionality is defined by the JavaScript tasks written in a project's <I>gulpfile.js</I>, making it highly flexible but requiring a JavaScript development environment.


title: INSTALLATION
content:
To use <b>gulp</b> globally from your terminal, first install the <I>gulp-cli</I> package: <I>npm install -g gulp-cli</I>. For each project, you then need to install the local <I>gulp</I> package as a development dependency: <I>npm install --save-dev gulp</I>.


title: GULPFILE.JS
content:
The central configuration and task definition file for <b>gulp</b> is named <I>gulpfile.js</I>, located in the root of your project. This file is written in JavaScript and uses <I>gulp.src()</I> to read files, <I>.pipe()</I> to apply transformations using plugins, <I>gulp.dest()</I> to write processed files, and <I>gulp.series()</I> or <I>gulp.parallel()</I> to compose tasks.


title: HISTORY
content:
<b>gulp</b> was initially developed by Eric Schoffstall and released in 2013. It gained rapid popularity as a modern alternative to existing JavaScript task runners like Grunt. Its core philosophy emphasized 'code-over-configuration' and leveraged Node.js streams for efficient, in-memory processing of files. This design often resulted in faster build times and a more programmatic, less declarative approach to defining build workflows. Its development has continued with focus on performance, plugin ecosystem, and an intuitive API for front-end automation.


title: SEE ALSO
content:
npm(1): Node.js package manager, used to install gulp and its plugins., node(1): Node.js runtime, which executes gulp tasks and the underlying JavaScript code., webpack: A popular module bundler, often used for similar front-end asset compilation and optimization tasks., grunt: Another well-known JavaScript task runner, which gulp emerged as an alternative to, focusing on streams and code-based configuration.


title: SYNOPSIS
content:
<b><I>gum</I></b> <I>command</I> [flags]<br><br>Examples:<br><b><I>gum</I></b> <I>input</I> --prompt <I>"What's your name?"</I><br><b><I>gum</I></b> <I>choose</I> <I>"apple"</I> <I>"banana"</I> <I>"cherry"</I><br><b><I>gum</I></b> <I>confirm</I> <I>"Are you sure?"</I>


title: PARAMETERS
content:
<b><b>--width</b> <I>&lt;int&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum width of the component.<br><br><b><b>--height</b> <I>&lt;int&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum height of the component (for list-like components).<br><br><b><b>--prompt</b> <I>&lt;string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Text to display before user input (e.g., for <I>input</I>, <I>confirm</I>).<br><br><b><b>--placeholder</b> <I>&lt;string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Placeholder text for input fields.<br><br><b><b>--selected</b> <I>&lt;string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initial selected value for choice components.<br><br><b><b>--header</b> <I>&lt;string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Text to display above the component (for list-like components).<br><br><b><b>--cursor</b> <I>&lt;string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Symbol or text to use as a cursor.<br><br><b><b>--no-limit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the limit for selectable items in <I>choose</I> or <I>filter</I>.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or subcommand.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of <I><b>gum</b></I>.<br><br>


title: DESCRIPTION
content:
<I><b>gum</b></I> is a modern, open-source command-line tool from Charm designed to enhance shell scripts with interactive <b><I>Text User Interface</I></b> (TUI) components. Unlike traditional utilities like <b><I>read</I></b> or <b><I>select</I></b>, <I><b>gum</b></I> provides a rich set of composable utilities for common interactive tasks, such as getting user input, making choices from a list, confirming actions, displaying spinners for long-running processes, formatting text, or rendering markdown. Built on top of the <I><b>Bubble Tea</b></I> <b><I>TUI</I></b> framework, <I><b>gum</b></I> aims to make shell scripts more user-friendly, visually appealing, and robust by abstracting away the complexities of terminal <b><I>UI</I></b> programming. It simplifies the creation of engaging command-line experiences without requiring extensive programming knowledge, making it an ideal choice for developers looking to quickly build powerful and interactive <I><b>CLI</b></I> tools or automate tasks with a pleasant user interface.


title: CAVEATS
content:
<I><b>gum</b></I> is not a standard, pre-installed utility on most Linux distributions; it must be installed separately. While it significantly enhances shell scripting, its primary focus is on interactive user interfaces rather than core system administration tasks. Terminal compatibility may vary, and advanced customization often requires diving into the specific options of each subcommand.


title: KEY SUBCOMMANDS
content:
<I><b>gum</b></I> operates through a collection of powerful subcommands, each designed for a specific interactive task:<br><br><I><b>input</b></I>: Prompts the user for text input.<br><I><b>choose</b></I>: Allows selection of one or more items from a list.<br><I><b>confirm</b></I>: Asks for a yes/no confirmation.<br><I><b>filter</b></I>: Filters input lines using a fuzzy finder.<br><I><b>spin</b></I>: Displays a spinner while a command runs.<br><I><b>format</b></I>: Renders markdown, JSON, or other formats.<br><I><b>write</b></I>: Multi-line text editor for user input.<br><I><b>pager</b></I>: Displays content in a scrollable view.<br><I><b>style</b></I>: Applies ANSI styling to text.<br><I><b>log</b></I>: Displays a structured log viewer.


title: INSTALLATION
content:
<I><b>gum</b></I> can be installed via various package managers or directly from source. Common methods include:<br><br><b>Homebrew (macOS/Linux)</b>: <I>brew install gum</I><br><b>Go</b>: <I>go install github.com/charmbracelet/gum@latest</I><br><b>APT (Debian/Ubuntu)</b>: <I>sudo mkdir -p /etc/apt/keyrings<br>curl -fsSL https://repo.charm.sh/apt/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/charm.gpg<br>echo "deb [signed-by=/etc/apt/keyrings/charm.gpg] https://repo.charm.sh/apt/ *" | sudo tee /etc/apt/sources.list.d/charm.list<br>sudo apt update && sudo apt install gum</I>


title: HISTORY
content:
Developed by Charm, the creators of other popular <I><b>CLI</b></I> tools like <I><b>Glow</b></I> and <I><b>Bunnyshell</b></I>, <I><b>gum</b></I> was first released to provide modern, interactive <I><b>UI</b></I> components for shell scripting. It leverages the <I><b>Bubble Tea</b></I> framework for building command-line applications and <I><b>Glamour</b></I> for markdown rendering, bringing a polished and aesthetically pleasing experience to the terminal. Its development focuses on ease of use and integrating <I><b>TUI</b></I> elements seamlessly into existing shell scripts, addressing the limitations of traditional, less interactive scripting methods.


title: PARAMETERS
content:
<b>set <I>key</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stores or updates a persistent key-value pair. If <i>key</i> already exists, its <i>value</i> is overwritten.<br><br><b>get <I>key</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves and prints the <i>value</i> associated with the specified <i>key</i> to standard output. An error is returned if the <i>key</i> is not found.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all currently stored key-value pairs managed by <b>gummy</b> for the current user.<br><br><b>clear [<I>key</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specific key-value pair identified by <i>key</i>. If no <i>key</i> is provided, all stored data for the current user is cleared.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides details about the <b>gummy</b> storage location and overall usage statistics.<br><br>


title: DESCRIPTION
content:
The <b>gummy</b> command is a <i>hypothetical</i> utility designed for managing lightweight, ephemeral data that requires persistence across terminal sessions or system reboots, without the overhead of traditional files or databases. It serves as a simple, user-specific key-value store, enabling users to "stick" small pieces of information, such as temporary notes, configuration flags, or frequently used strings, for easy retrieval later. <br><br>Unlike environment variables, which are typically confined to the current shell or process, <b>gummy</b> ensures data availability across multiple login sessions. Its primary goal is to provide a frictionless way to store and retrieve data that is "gummy" – persistent yet easily modifiable or discarded. This makes it an ideal tool for personal command-line workflows where certain information needs to be conveniently accessible and durable for a moderate period.<br><br>It aims to bridge the gap between volatile shell variables and rigid filesystem storage, offering a flexible layer for dynamic information management.


title: CAVEATS
content:
<b>Hypothetical Command</b>: The <b>gummy</b> command is a conceptual utility and does not exist as a standard command in Linux distributions. This description is provided for illustrative purposes.<br><i>Note</i>: If you need similar functionality, consider using custom shell scripts, environment variables, or dedicated note-taking utilities.<br><br><b>Security Implications</b>: If this command were real, data would typically be stored in plain text within the user's home directory. Therefore, it would <i>not</i> be suitable for storing sensitive information such as passwords or private keys.<br><br><b>Scalability</b>: This concept is designed for small, intermittent data storage. It is not optimized for large datasets or high-performance data operations.


title: PERSISTENT STORAGE MECHANISM
content:
Conceptually, <b>gummy</b> data would be stored in a hidden, user-specific file (e.g., <code>~/.config/gummy/data.json</code> or <code>~/.gummy_data</code>) to ensure persistence across reboots and login sessions. This file would be automatically managed by the command.


title: DATA FORMAT
content:
The data would ideally be stored in a simple, human-readable format such as JSON or a basic key-value text file, allowing for easy inspection and minimal overhead.


title: HISTORY
content:
The <b>gummy</b> command is purely <i>hypothetical</i> and therefore has no historical development or usage within Linux systems. Its conceptualization arises from the common need for a lightweight, flexible mechanism to store and retrieve small pieces of data that persist beyond a single shell session, without requiring the formality of a traditional filesystem or database. It represents a potential solution to bridge the gap between volatile shell variables and permanent file storage for user-centric, non-critical information.


title: PARAMETERS
content:
<b>-c, --stdout, --to-stdout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write output to standard output; keep original files unchanged.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force decompression. If an output file already exists, it is overwritten. Allows decompression of files that do not have a recognized suffix.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>-k, --keep</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep (don't delete) input files during decompression.<br><br><b>-L, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the contents of a compressed file. Does not decompress.<br><br><b>-N, --name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When decompressing, restore the original filename and timestamp if saved in the compressed file.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warnings.<br><br><b>-r, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurse into directories. If any of the file names specified on the command line are directories, <b>gunzip</b> will descend into the directory and decompress all files found there.<br><br><b>-S <i>suffix</i>, --suffix <i>suffix</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>suffix</i> instead of <i>.gz</i> when searching for compressed files.<br><br><b>-t, --test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the integrity of the compressed file. The file is decompressed in memory to check for errors, but no output file is created.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be verbose. Display the name and percentage reduction for each file decompressed.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version number and exit.<br><br>


title: DESCRIPTION
content:
The <b>gunzip</b> command is used to decompress files that were compressed by the <b>gzip</b> utility. It is functionally equivalent to executing `gzip -d`. By default, <b>gunzip</b> replaces the compressed input file (typically ending with <i>.gz</i>, <i>.tgz</i>, <i>.taz</i>, or <i>.Z</i>) with its original, uncompressed version. If no files are specified, or if a file is given as <i>-</i>, <b>gunzip</b> will read from standard input and write the decompressed data to standard output, keeping the original file intact.<br><br><b>gunzip</b> can decompress files created by <b>gzip</b>, <b>compress</b> (<i>.Z</i>), and can also handle some <b>PKZIP</b> archives (<i>.zip</i>) that contain a single entry compressed with the 'deflate' method, though for general ZIP files, <b>unzip</b> is recommended. It checks the integrity of the compressed file before decompressing. If an error is detected, the command will often report it and delete any partially decompressed output files to prevent corruption.


title: CAVEATS
content:
By default, <b>gunzip</b> deletes the original compressed file after successful decompression. Use the <b>-k</b> option to keep the original.<br>It is primarily designed for single-file decompression; for complex archives like <i>.tar.gz</i>, it's often piped with <b>tar</b> (e.g., `tar -xzf file.tar.gz`).<br>While it can sometimes decompress single-entry <b>PKZIP</b> files, <b>unzip</b> is the dedicated tool for <i>.zip</i> archives.


title: <I>STANDARD INPUT/OUTPUT HANDLING</I>
content:
When no file arguments are given, or if a file is specified as <i>-</i>, <b>gunzip</b> reads from standard input and writes the decompressed data to standard output. This allows it to be used in pipes, for example, `cat file.gz | gunzip` or `gunzip < file.gz > file`.


title: <I>EXIT STATUS</I>
content:
<b>gunzip</b> exits with status 0 if processing was successful, 1 if an error occurred (e.g., malformed file, invalid arguments), and 2 if a warning occurred (e.g., file not found).


title: HISTORY
content:
<b>gunzip</b> is part of the GNU Project's <b>gzip</b> package, initially developed by Jean-loup Gailly and released in 1992. It emerged as a free alternative to the proprietary <b>compress</b> utility, which used the LZW compression algorithm, subject to patents. <b>gzip</b> and consequently <b>gunzip</b>, quickly became the de-facto standard for lossless data compression on Unix-like systems.


title: DESCRIPTION
content:
<b>gv2gml</b> is a dedicated utility within the <i>Graphviz</i> suite of graph visualization tools. Its primary function is to transform graph descriptions written in the <i>DOT language</i> into the <i>GML (Graph Modeling Language)</i> format. GML provides a hierarchical, text-based structure for representing graphs, making it suitable for exchange between various graph analysis and visualization applications.<br><br>By converting DOT files to GML, <b>gv2gml</b> facilitates interoperability, allowing users to leverage Graphviz's powerful layout capabilities and then export the graph data for use in other GML-compatible systems. The command reads graph data from specified input files or from standard input if no files are provided, outputting the resulting GML representation to standard output.<br><br>While Graphviz offers numerous layout algorithms, <b>gv2gml</b> focuses solely on the format conversion aspect, relying on the core <b>dot</b> engine for parsing and rendering the graph structure before conversion.


title: CAVEATS
content:
<b>gv2gml</b> is often implemented as a simple shell script or wrapper that invokes the core <b>dot</b> command with the <i>-Tgml</i> output format option. As such, it generally does not have its own specific command-line options beyond accepting input files. Any advanced graph layout or attribute processing is handled by the underlying <b>dot</b> utility. Users wishing to apply specific <b>dot</b> options should typically use <b>dot -Tgml</b> [options] [files] directly.<br><br>The output of <b>gv2gml</b> is always written to standard output. To save the GML content to a file, output redirection (e.g., <code>&gt; output.gml</code>) must be used.


title: INPUT AND OUTPUT
content:
<b>gv2gml</b> reads its input graph description from one or more files specified as command-line arguments. If no files are provided, it reads from standard input, allowing it to be used in pipelines. The converted GML output is always written to standard output (<i>stdout</i>), making it suitable for piping to other commands or redirecting to a file using shell redirection operators (e.g., <code>gv2gml input.dot &gt; output.gml</code>).


title: HISTORY
content:
<b>gv2gml</b> is part of the <i>Graphviz</i> (Graph Visualization Software) project, which was originally developed at <i>AT&T Labs Research</i>. Graphviz itself has a long history, with its origins tracing back to the early 1990s as a tool for visualizing various types of graphs, particularly those arising in software engineering and network analysis. As a utility for format conversion, <b>gv2gml</b> was included to enhance the interoperability of Graphviz with other graph-processing tools and systems that utilize the GML standard, reflecting the project's commitment to flexible data exchange.


title: PARAMETERS
content:
<b><b>-o</b> <i>outfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs the GXL output to the specified <i>outfile</i>. If this option is omitted, the output is written to standard output (stdout).<br><br><b><b>-?</b> or <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief usage message, listing the available command-line options.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <i>gv2gxl</i> utility.<br><br><b><i>files ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more input files in Graphviz DOT format. If no files are provided, <i>gv2gxl</i> reads its input from standard input (stdin).<br><br>


title: DESCRIPTION
content:
<i>gv2gxl</i> is a utility from the <B>Graphviz</B> suite designed to convert graph descriptions written in the Graphviz <B>DOT language</B> into the <B>Graph eXchange Language (GXL)</B> format. GXL is an XML-based standard for the interchange of graph data, allowing various graph processing tools and applications to share and understand graph structures.<br><br>This conversion is particularly useful for users who need to export their Graphviz visualizations or data models into systems that prefer or require GXL for further analysis, manipulation, or storage. By facilitating interoperability, <i>gv2gxl</i> bridges the gap between Graphviz's powerful layout and visualization capabilities and other graph analysis platforms. It can read input from specified files or standard input and write the GXL output to a specified file or standard output.


title: CAVEATS
content:
<i>gv2gxl</i> primarily converts the <B>structure</B> of the graph (nodes, edges, attributes) but might not fully preserve all Graphviz-specific layout attributes or visual properties that are unique to Graphviz rendering engines. GXL focuses on the graph's logical structure, not its visual presentation.<br><br>Input files must be valid Graphviz DOT files. Errors in the input may lead to conversion failures or unexpected output.


title: INPUT/OUTPUT FLEXIBILITY
content:
<i>gv2gxl</i> is designed to be flexible with input and output. It can process multiple input DOT files, concatenating their graphs for conversion, or read from standard input (stdin), making it suitable for piping with other commands. The output can be redirected to a specified file or piped to subsequent commands for further processing.


title: GXL STANDARD
content:
GXL (Graph eXchange Language) is an XML-based standard for describing graphs. It serves as a widely recognized exchange format between various graph tools and applications. Understanding GXL's structure can be beneficial for users intending to process the output of <i>gv2gxl</i> programmatically or integrate it into other GXL-compatible systems.


title: HISTORY
content:
<i>gv2gxl</i> is part of the open-source <B>Graphviz</B> (Graph Visualization Software) project, developed by AT&T Labs Research. Graphviz has been under continuous development since the late 1990s, with <i>gv2gxl</i> being one of the many utility programs designed to enhance interoperability and data exchange capabilities within the graph processing ecosystem. Its inclusion reflects the need for robust mechanisms to transform Graphviz data into standardized formats like GXL, broadening its utility beyond just visualization.


title: SYNOPSIS
content:
<b>gvcolor</b> [<i>-?</i>] [<i>-V</i>] [<i>-G&lt;attr&gt;</i>] [<i>-N&lt;attr&gt;</i>] [<i>-E&lt;attr&gt;</i>] [<i>-f&lt;file&gt;</i>] [<i>-n&lt;v&gt;</i>] [<i>-c&lt;v&gt;</i>] [<i>-e&lt;v&gt;</i>] [<i>-s&lt;v&gt;</i>] [<i>file</i>]


title: PARAMETERS
content:
<b>-?</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 of <i>gvcolor</i> and exits.<br><br><b>-G&lt;attr&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the graph attribute to check for group ID. Defaults to <i>group</i>.<br><br><b>-N&lt;attr&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the node attribute to check for group ID. Defaults to <i>group</i>.<br><br><b>-E&lt;attr&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the edge attribute to check for group ID. Defaults to <i>group</i>.<br><br><b>-f&lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a file containing a custom color scheme to be used.<br><br><b>-n&lt;v&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of colors to use from the default palette. Default is 11; maximum allowed is 11.<br><br><b>-c&lt;v&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the base <b>ColorBrewer</b> palette by ID (0-23). Default is 0.<br><br><b>-e&lt;v&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of additional <b>ColorBrewer</b> palettes to append to the base scheme. Default is 0.<br><br><b>-s&lt;v&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the saturation level for generated colors, ranging from 0.0 (grayscale) to 1.0 (full saturation). Default is 0.5.<br><br><b>file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The input graph file in <b>DOT</b> format. If omitted, <i>gvcolor</i> reads from standard input.<br><br>


title: DESCRIPTION
content:
<i>gvcolor</i> is a specialized utility included in the <b>Graphviz</b> package, designed to enhance the visual clarity of graph diagrams. Its primary function is to assign colors to nodes and edges within a graph, based on a specified numeric attribute, typically <i>group</i>.<br><br>The command reads a graph in the <b>DOT</b> language format from standard input or a specified file. For each node or edge, <i>gvcolor</i> inspects the value of the designated attribute (defaulting to <i>group</i>). If this attribute contains a numeric value, it maps this value to a distinct color from a predefined palette or a user-supplied color scheme. This automatic coloring is invaluable for visually distinguishing related components or highlighting specific clusters within complex graphs.<br><br>The output is another <b>DOT</b> file, with the added <i>color</i> attributes for the modified nodes and edges. This colored <b>DOT</b> file can then be rendered into various image formats (like PNG, SVG, PDF) using <b>Graphviz</b> layout engines such as <b>dot</b>, <b>neato</b>, or <b>fdp</b>. It is commonly used in pipelines, for example, <b>unflatten | gvcolor | dot -Tpng > graph.png</b>, to automatically generate aesthetically pleasing and informative graph visualizations.


title: CAVEATS
content:
<i>gvcolor</i> primarily relies on numeric values in the specified <i>group</i> or custom attributes for coloring. Non-numeric values will be ignored for coloring purposes.<br><br>The default color palette is limited to 11 distinct colors. For more variation, custom color scheme files or <b>ColorBrewer</b> options must be utilized.<br><br>It is part of the <b>Graphviz</b> suite and not a standalone general-purpose text processing tool. It expects <b>DOT</b> format input and produces <b>DOT</b> format output.


title: COLOR SCHEMES AND PALETTES
content:
<i>gvcolor</i> supports using various color schemes. The <i>-c</i> (base palette ID) and <i>-e</i> (additional palettes) options allow users to leverage <b>ColorBrewer</b> palettes, which are designed for optimal readability and perceptual uniformity. This provides a wide range of well-suited color sets for different types of data visualization.


title: INPUT AND OUTPUT FORMAT
content:
<i>gvcolor</i> exclusively processes graph descriptions in the <b>DOT</b> language. It reads <b>DOT</b> format from an input file or standard input and outputs a modified <b>DOT</b> file to standard output, with <i>color</i> attributes added to relevant nodes and edges.


title: HISTORY
content:
<i>gvcolor</i> is an integral component of the open-source <b>Graphviz</b> project, which was initially developed at <b>AT&T Labs Research</b>. <b>Graphviz</b>, including tools like <i>gvcolor</i>, has evolved significantly since its inception to become a widely used suite for visualizing structural information, particularly graphs and networks. Its development has focused on providing automated and aesthetically pleasing ways to represent complex data relationships. <i>gvcolor</i>'s specific role in this evolution has been to provide an accessible and automated method for distinguishing graph elements by groups, greatly enhancing the interpretability of large or intricate visualizations.


title: SEE ALSO
content:
<b>dot(1)</b>: Graphviz layout engine, <b>neato(1)</b>: Graphviz layout engine, <b>twopi(1)</b>: Graphviz layout engine, <b>circo(1)</b>: Graphviz layout engine, <b>fdp(1)</b>: Graphviz layout engine, <b>sfdp(1)</b>: Graphviz layout engine, <b>gvpr(1)</b>: Graphviz graph processing language, <b>unflatten(1)</b>: Graphviz tool to remove flat edges


title: PARAMETERS
content:
<b><i>LOCATION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more GVFS URIs specifying the file(s) to read. Examples include <i>sftp://user@host/path/to/file</i>, <i>smb://server/share/file.txt</i>, or <i>mtp://[bus-id]:[device-id]/Internal storage/file.mp3</i>.<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;Shows version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>gvfs-cat</b> command is a utility within the GNOME Virtual File System (GVFS) framework. GVFS is a userspace virtual filesystem that provides a unified way for applications to access various remote and local file systems, including FTP, SFTP, WebDAV, SMB/CIFS, MTP, and even content inside archive files, as if they were standard local files.<br><br>Similar to the traditional <b>cat</b> command for local files, <b>gvfs-cat</b> reads the content of files specified by a GVFS Uniform Resource Identifier (URI) and prints them to standard output. This makes it possible to view or pipe the content of files residing on remote servers or virtual locations without needing to explicitly mount them beforehand or use specific client tools for each protocol. It is particularly useful in scripting contexts for automating tasks involving non-local data.


title: CAVEATS
content:
<b>GVFS Daemon:</b> <b>gvfs-cat</b> relies on the GVFS daemon being active and running. This is typically the case in GNOME desktop environments.<br><b>URI Format:</b> Strict adherence to GVFS URI syntax is crucial. Incorrect URIs will result in errors.<br><b>Authentication:</b> Accessing remote resources may require authentication (e.g., passwords, SSH keys). <b>gvfs-cat</b> will often prompt for credentials or rely on the GVFS daemon's authentication mechanisms.<br><b>Permissions:</b> The user running the command must have the necessary permissions to access the specified remote or virtual resource.


title: URI EXAMPLES
content:
Understanding the correct GVFS URI syntax is key. Common schemes include: <br><i>sftp://user@host/path/to/file</i> (SFTP)<br><i>ftp://user:password@host/path/to/file</i> (FTP)<br><i>smb://server/share/path/to/file</i> (SMB/CIFS)<br><i>dav://host/path/to/file</i> (WebDAV)<br><i>mtp://[bus-id]:[device-id]/Storage/path/to/file</i> (MTP devices)<br><i>archive://path/to/archive.zip/path/inside/archive.txt</i> (Content inside archives)


title: INTEGRATION WITH GIO
content:
<b>gvfs-cat</b> leverages the GIO library, which is GNOME's modern input/output API. This means it benefits from GIO's asynchronous I/O capabilities, cancellation support, and robust handling of various file system types and network protocols. The <b>gio cat</b> command is often an alias or functionally identical way to achieve the same result, as <b>gio</b> is the primary command-line interface for GIO operations.


title: HISTORY
content:
<b>gvfs-cat</b> is part of the GVFS (GNOME Virtual File System) project, which was developed to succeed the older GNOME VFS. The primary motivation for GVFS was to provide a more robust, flexible, and modular virtual filesystem architecture built upon the GIO (Gnome Input/Output) library. GVFS integrates deeply with the GNOME desktop, offering seamless access to various network protocols and local archives from standard file managers and applications. <b>gvfs-cat</b>, along with other <b>gvfs-*</b> utilities, was introduced as a command-line interface to interact with this powerful virtual filesystem layer, making its capabilities accessible directly from the terminal for scripting and administrative tasks.


title: PARAMETERS
content:
<b><b>-i</b>, <b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt before overwriting an existing destination file.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite existing destination files without prompting (overrides <b>-i</b>).<br><br><b><b>-n</b>, <b>--no-clobber</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not overwrite an existing file; exit with an error if the destination already exists.<br><br><b><b>-P</b>, <b>--no-progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display progress information during the copy operation.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>gvfs-copy</i> is a command-line utility that is part of the GVfs (GNOME Virtual File System) suite. It allows users to copy files and directories to or from various locations, including local filesystems and remote resources accessed via GVfs backends. Unlike standard tools like <i>cp</i>, <i>gvfs-copy</i> can directly handle URIs (Uniform Resource Identifiers) such as <b>sftp://</b>, <b>smb://</b>, <b>ftp://</b>, <b>dav://</b>, or <b>mtp://</b>.<br><br>This capability makes it ideal for interacting with network shares, MTP devices, or other virtual filesystems supported by GVfs without requiring them to be traditionally mounted beforehand. It transparently handles authentication and connection details managed by GVfs, providing a consistent way to manage files across diverse storage types within the GNOME environment and beyond. It supports recursive copying for directories and offers options for handling existing destination files.


title: CAVEATS
content:
<i>gvfs-copy</i> relies on GVfs backends being installed and properly configured for remote protocols. Its performance and available features can vary depending on the specific GVfs backend used (e.g., a slow network connection for SFTP). While it mimics <i>cp</i>, it does not support all its options (e.g., preserving all attributes like <b>-a</b>, or creating hard/symbolic links), as these capabilities are often backend-dependent or not relevant to virtual filesystems. Authentication for remote resources is handled by GVfs's integrated credential management (e.g., GNOME Keyring) rather than direct command-line prompts for passwords.


title: URI SUPPORT
content:
The most significant distinction of <i>gvfs-copy</i> is its ability to accept URIs as source and destination paths. This allows direct interaction with network shares (e.g., <b>smb://</b>, <b>sftp://</b>, <b>ftp://</b>), MTP devices (<b>mtp://</b>), and other virtual filesystems without the need for explicit mounting via the traditional <i>mount</i> command. The URI format ensures that protocol-specific details are handled transparently by the appropriate GVfs backend, simplifying cross-protocol file operations.


title: INTEGRATION WITH GNOME
content:
As an integral part of the GVfs suite, <i>gvfs-copy</i> seamlessly integrates with the GNOME desktop environment's file management capabilities. It leverages GNOME's sophisticated credential management system for remote authentications, providing a consistent and secure user experience for file operations across both local and remote resources within the GNOME ecosystem.


title: HISTORY
content:
GVfs was introduced as a major component of GNOME 2.22 (released in 2008) to replace the older and less flexible GnomeVFS. Its primary goal was to provide a more modular, robust, and extensible virtual filesystem layer built upon GIO (Glib Input/Output). <i>gvfs-copy</i> is one of the core command-line utilities developed as part of this transition, offering a familiar <i>cp</i>-like interface tailored to interact with GVfs-managed resources. It has since evolved alongside the GNOME desktop, benefiting from improvements in GVfs's stability and expanding support for various network and virtual filesystem protocols.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message for the command, detailing available options and usage.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>gvfs-info</b> utility.<br><br><b><b>--attributes=</b><I>ATTRIBUTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of attributes to query. Attributes can be defined with namespaces (e.g., <i>standard::*, etag::hash, unix::mode</i>). Using <i>*</i> will query all available attributes.<br><br><b><b>--query-filesystems</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries and displays information about all currently mounted GVfs filesystems. When this option is used, no <i>LOCATION</i> argument is required.<br><br><b><b>--filesystem</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used in conjunction with a <i>LOCATION</i>, this option queries and displays information specifically about the GVfs filesystem to which the given <i>LOCATION</i> belongs, rather than the <i>LOCATION</i> (file or directory) itself.<br><br>


title: DESCRIPTION
content:
<b>gvfs-info</b> is a command-line utility designed to query and display detailed <i>information</i> about files, directories, or specific GVfs URI schemes. It forms an integral part of the GVfs (GNOME Virtual File System) framework, which provides a userspace virtual filesystem layer over various backends such as local filesystems, SFTP, SMB, MTP devices, and more.<br><br>This command empowers users to inspect a wide range of properties, including standard file attributes like type, size, and modification dates, as well as more specific GVfs attributes such as content type, display name, and mount-related information for remote locations. It is particularly valuable for developers, system administrators, and advanced users who need to understand how GVfs interprets and manages different URI types, offering a programmatic method to retrieve metadata that is often displayed by graphical file managers like Nautilus.


title: CAVEATS
content:
The functionality of <b>gvfs-info</b> is contingent upon the GVfs daemon being actively running. Querying remote URIs necessitates proper network connectivity and, in many cases, valid authentication credentials. The output can become quite extensive, particularly when querying all attributes using wildcards like <i>*</i>, which may include internal or less commonly used GVfs metadata. Incorrectly formatted URIs will result in errors.


title: GVFS URIS
content:
<i>GVfs URIs</i> are specialized strings that identify resources managed by the GVfs framework, similar in concept to standard URLs. They can point to local files (e.g., <i>file:///home/user/document.txt</i>) or a multitude of remote locations (e.g., <i>sftp://user@host/path/</i>, <i>mtp://[usb:001,005]/</i>). A clear understanding of GVfs URI formatting is essential for the effective use of <b>gvfs-info</b>.


title: ATTRIBUTES AND NAMESPACES
content:
GVfs organizes extensive metadata into <i>attributes</i>. These attributes are logically grouped within <i>namespaces</i>, such as <i>standard</i> (basic file info), <i>time</i> (timestamps), <i>owner</i> (user/group), <i>unix</i> (POSIX permissions), and <i>xattr</i> (extended attributes). When using the <b>--attributes</b> option, you can specify individual attributes (e.g., <i>standard::name, time::modified</i>) or use wildcards to retrieve all attributes within a namespace (e.g., <i>standard::*</i>) or all attributes universally (<i>*</i>). This mechanism provides granular control over the displayed information.


title: NOTE ON 'GIO INFO'
content:
While <b>gvfs-info</b> specifically targets GVfs URIs, the more general-purpose <b>gio info</b> command from the GIO library often provides similar or even broader functionality. <b>gio info</b> can query GIO URI types directly and is frequently the preferred tool for general file information queries within the GNOME environment, as it sits at a higher abstraction layer.


title: HISTORY
content:
<b>gvfs-info</b> is a component of the GNOME Virtual File System (GVfs) project, which emerged as a modern successor to the older GnomeVFS framework. GVfs was developed to provide a robust and extensible abstraction layer for diverse filesystems—ranging from local and network shares to virtual devices like MTP. It leverages a D-Bus based architecture for inter-process communication. This command has been a foundational part of the GVfs toolkit since its initial iterations, enabling programmatic access to the rich metadata and properties managed by GVfs for various URI schemes.


title: PARAMETERS
content:
<b><b>-l</b>, <b>--long</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a long listing format, showing permissions, owner, group, size, and modification time.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ignore entries starting with '<b>.</b>' (dot files).<br><br><b><b>-A</b>, <b>--almost-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not list implied '<b>.</b>' and '<b>..</b>' entries.<br><br><b><b>-h</b>, <b>--human-readable</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;With <b>-l</b>, print sizes in human readable format (e.g., 1K, 234M, 2G).<br><br><b><b>-d</b>, <b>--directory</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List directory entries themselves, rather than their contents.<br><br><b><b>-F</b>, <b>--classify</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append an indicator (one of <i>*/=>@|</i>) to entries: <i>*</i> for executables, <i>/</i> for directories, <i>=</i> for sockets, <i>></i> for whiteouts, <i>@</i> for symbolic links, <i>|</i> for FIFOs.<br><br><b><b>-R</b>, <b>--recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List subdirectories recursively.<br><br><b><b>-n</b>, <b>--numeric-uid-gid</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like <b>-l</b>, but list numeric user and group IDs.<br><br><b><b>-Q</b>, <b>--quote-name</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enclose entry names in double quotes.<br><br><b><b>-s</b>, <b>--size</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the allocated size of each file, in blocks.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort by modification time, newest first.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort by file size, largest first.<br><br><b><b>-U</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not sort; list entries in directory order.<br><br><b><b>-X</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort alphabetically by entry extension.<br><br><b><b>-1</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List one entry per line.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display extra debugging information.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br>


title: DESCRIPTION
content:
The <b>gvfs-ls</b> command is a utility from the GNOME Virtual File System (GVFS) suite, designed to list the contents of directories or locations specified by Uniform Resource Identifiers (URIs). GVFS itself is a user-space virtual file system that integrates various remote or special file systems directly into the GNOME desktop environment, making them accessible as if they were local files. This includes protocols like FTP, SFTP, SMB/CIFS, WebDAV, MTP, and more.<br><br><b>gvfs-ls</b> functions similarly to the standard <b>ls</b> command but extends its capabilities to handle network locations and other non-local resources that GVFS supports. Instead of traditional file paths, it accepts URIs as arguments (e.g., <i>sftp://user@host/path/</i>, <i>smb://server/share/</i>, <i>ftp://example.com/</i>). This allows users to browse and list directories on remote servers, network shares, or even portable devices without needing to explicitly mount them beforehand. It's an essential tool for interacting with the diverse range of virtual file systems managed by GVFS from the command line.


title: CAVEATS
content:
<b>gvfs-ls</b> relies heavily on the availability and correct configuration of GVFS backends. Network connectivity is essential for accessing remote URIs, and performance can vary significantly based on network conditions and the responsiveness of the remote server. Authentication might be prompted or fail if the necessary credentials are not provided or previously stored. While it can list local files, <b>gvfs-ls</b> is generally slower than the standard <b>ls</b> command for such operations as it goes through the GVFS layer.


title: GVFS URIS
content:
GVFS uses Uniform Resource Identifiers (URIs) to specify locations, which allows it to address files and directories across diverse protocols and services. Unlike traditional file paths, URIs specify the protocol (e.g., <i>ftp://</i>, <i>sftp://</i>, <i>smb://</i>, <i>dav://</i>, <i>mtp://</i>), followed by the network location and optional path within that location. For instance, <i>sftp://user@example.com/home/user/documents/</i> would point to a 'documents' directory on a remote SFTP server, while <i>smb://server/share/</i> would refer to a network share. This standardized approach enables <b>gvfs-ls</b> to list contents from a wide array of sources, abstracting away the underlying network complexities.


title: HISTORY
content:
<b>gvfs-ls</b> is part of the GVFS project, which was developed as a modern replacement for the older <i>gnome-vfs</i> in the GNOME desktop environment. GVFS made its debut with GNOME 2.22 in 2008, bringing a more robust, asynchronous, and flexible virtual filesystem layer built upon GIO (Gnome Input/Output). The <i>gvfs-</i> utilities, including <b>gvfs-ls</b>, were created to provide command-line access to these new capabilities, allowing users to interact with various network protocols and virtual file systems that are seamlessly integrated into the GNOME desktop.


title: SYNOPSIS
content:
<b>gvfs-mime</b> --query <I>MIME_TYPE</I><br><b>gvfs-mime</b> --set <I>MIME_TYPE</I> <I>APPLICATION_HANDLER</I><br><b>gvfs-mime</b> --list<br><b>gvfs-mime</b> [--help | --version]


title: PARAMETERS
content:
<b>--query <I>MIME_TYPE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries and prints the default application for the specified MIME type.<br><br><b>--set <I>MIME_TYPE</I> <I>APPLICATION_HANDLER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default application for the specified MIME type. <I>APPLICATION_HANDLER</I> is typically a desktop file ID (e.g., <i>firefox.desktop</i>).<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all known MIME types and their currently configured default applications.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br>


title: DESCRIPTION
content:
<i>gvfs-mime</i> is a command-line utility provided by the GVfs (GNOME Virtual File System) suite. It allows users to interact with the system's MIME type database, primarily for querying and setting default applications. This tool is instrumental in defining which application opens specific file types (e.g., PDFs, images, text files) within a GNOME desktop environment or other environments utilizing GVfs.<br><br>It can list all known MIME types and their associated default handlers, query the specific default application for a given MIME type, or explicitly set a new default application for a MIME type. While it directly manages GIO/GVfs MIME associations, its functionality often aligns with the user's perception of 'default applications' on their desktop.


title: CAVEATS
content:
<i>gvfs-mime</i> primarily manages associations within the GIO/GVfs framework, commonly used in GNOME and related desktop environments. Its effects might not be universal across all Linux desktop environments (e.g., KDE Plasma often uses different mechanisms).<br><br>When using <i>--set</i>, the <i>APPLICATION_HANDLER</i> must be the correct desktop file ID (e.g., <i>org.gnome.Nautilus.desktop</i>), not the raw executable path, which can sometimes be a source of confusion.


title: INTEGRATION WITH DESKTOP ENVIRONMENTS
content:
While a command-line tool, <i>gvfs-mime</i> serves as the underlying mechanism for many GUI-based 'Default Applications' settings within GNOME and other GIO-based desktop environments. Users interacting with these graphical settings are often implicitly using the same GIO/GVfs mechanisms that <i>gvfs-mime</i> exposes.


title: USER-SPECIFIC CONFIGURATION
content:
Default application settings managed by <i>gvfs-mime</i> are typically stored in the user's configuration directory, specifically <i>~/.local/share/applications/mimeapps.list</i>. This allows for personalized application preferences without affecting system-wide defaults.


title: HISTORY
content:
<i>gvfs-mime</i> is part of the GVfs (GNOME Virtual File System) project, which was introduced to GNOME to replace the older GnomeVFS. GVfs is a userspace virtual filesystem providing GIO (Gnome Input/Output) modules and various backends. <i>gvfs-mime</i> emerged as the command-line utility for managing MIME type associations within this new GIO/GVfs framework, offering programmatic control over default application settings that were previously handled differently in older GNOME versions or entirely by desktop environments. Its development is tied directly to the evolution of GNOME's core infrastructure for file handling and application launching.


title: PARAMETERS
content:
<b>--parents, -p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create parent directories as needed. If parent directories do not exist, they are created automatically.<br><br><b>--mode=MODE, -m MODE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the file mode (permissions) for the newly created directory. MODE can be an octal number (e.g., <I>0755</I>) or a symbolic mode string.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br><b>URI</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Uniform Resource Identifier(s) specifying the path(s) of the directory to be created. This can be a local path or a remote URI (e.g., <I>sftp://user@host/path/to/dir</I>).<br><br>


title: DESCRIPTION
content:
<b>gvfs-mkdir</b> is a utility from the GNOME Virtual File System (GVfs) suite, designed to create new directories on remote locations or local file systems that are exposed via GVfs. Unlike the standard <b>mkdir</b> command, <b>gvfs-mkdir</b> operates on URIs (Uniform Resource Identifiers), allowing it to interact seamlessly with various network protocols such as FTP, SFTP, SMB, WebDAV, and more, as long as GVfs has a backend for them.<br><br>This command is particularly useful in environments where users need to manipulate files and directories across different network shares or cloud storage providers without explicitly mounting them in the traditional sense. It provides a consistent interface for directory creation, abstracting away the underlying network complexities.


title: CAVEATS
content:
<b>gvfs-mkdir</b> relies on the GVfs backends and the D-Bus system. Its functionality depends on the availability and proper configuration of GVfs mounts and services. Errors during remote operations (e.g., network issues, authentication failures, insufficient permissions on the remote server) will be reported by the command. It might not be available or fully functional in minimal environments without a running D-Bus session or GVfs daemons.


title: URI USAGE
content:
Unlike traditional commands that operate on local file paths, <b>gvfs-mkdir</b> exclusively uses URIs. This allows it to target diverse network locations (e.g., <I>sftp://user@host/path</I>, <I>smb://server/share/folder</I>, <I>ftp://example.com/dir</I>) as if they were local paths, providing a powerful abstraction layer for remote file management.


title: INTEGRATION WITH GNOME
content:
<b>gvfs-mkdir</b> and other <b>gvfs-</b> commands are often used implicitly by GNOME applications. For example, when you drag and drop files to a network share in Nautilus, GVfs handles the underlying operations. These command-line tools provide direct access to this same GVfs functionality for scripting and power users.


title: HISTORY
content:
GVfs (GNOME Virtual File System) was developed as a replacement for the older <I>GnomeVFS</I> library, aiming for a more robust and modular virtual filesystem architecture. It integrates deeply with the GNOME desktop environment, providing transparent access to remote resources. <b>gvfs-mkdir</b> emerged as part of the <I>gvfs-fuse</I> and command-line utilities, offering a consistent way to manage directories across these virtualized file systems, enhancing user experience by abstracting network complexities. Its development is tied to the evolution of the GNOME desktop.


title: SYNOPSIS
content:
<B>gvfs-monitor-dir</B> [<i>OPTION...</i>] <i>DIRECTORY</i><br><B>gvfs-monitor-dir</B> --help<br><B>gvfs-monitor-dir</B> --version


title: PARAMETERS
content:
<b><i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the directory that <i>gvfs-monitor-dir</i> should monitor for changes. This can be a local path or a GVFS URI (e.g., <i>sftp://user@host/path</i>).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information for the <i>gvfs-monitor-dir</i> command and exits.<br><br>


title: DESCRIPTION
content:
The <i>gvfs-monitor-dir</i> command is a utility from the <B>GVFS</B> (GNOME Virtual File System) suite, designed to observe and report changes within a specified directory. It primarily acts as a diagnostic and debugging tool, printing notifications to standard output whenever events like file creation, deletion, modification, or attribute changes occur within the monitored directory or its immediate contents. This is especially useful for understanding how applications interact with directories exposed through GVFS backends, which can include remote locations like SFTP, SMB shares, or FTP servers. Unlike lower-level file system monitoring tools, <i>gvfs-monitor-dir</i> operates at the GVFS abstraction layer, making it suitable for debugging issues related to GVFS operations rather than raw kernel-level file system events.


title: CAVEATS
content:
<ul><li>Primarily intended as a debugging and informational tool for developers and advanced users working with GVFS. It is not typically used for automated scripting due to its raw, event-stream output.</li><li>The events reported by <i>gvfs-monitor-dir</i> are specific to the GVFS abstraction layer and may not perfectly reflect all underlying kernel-level file system events (e.g., via <i>inotify</i>).</li><li>Its functionality depends on the correct operation of the GVFS daemon (<i>gvfsd</i>) and relevant GVFS backends.</li><li>It does not provide options for filtering specific event types or for monitoring subdirectories recursively beyond the immediate contents of the specified directory.</li></ul>


title: OUTPUT FORMAT
content:
The command outputs events to standard output in a human-readable, but programmatic-unfriendly, format. Each line typically describes an event, such as a file being created, deleted, or changed, often including the path to the affected item. This output is primarily for interactive debugging and observation.


title: USAGE SCENARIO
content:
A typical use case involves running <i>gvfs-monitor-dir</i> on a directory that is experiencing issues, perhaps on a network share mounted via GVFS, and then performing actions in that directory to see what events are reported, helping diagnose file operation problems.


title: HISTORY
content:
<i>gvfs-monitor-dir</i> is part of the <B>GVFS</B> project, which was introduced with <B>GNOME 2.22</B> in March 2008. GVFS was developed to replace the older <I>GnomeVFS</I> library, aiming to provide a more robust and flexible virtual file system layer for GNOME applications, leveraging <I>GIO</I> (Gnome Input/Output) as its foundation. The <i>gvfs-monitor-dir</i> utility emerged as a specific tool within this framework to aid in debugging and understanding directory monitoring behavior within the GVFS environment. Its development and usage are closely tied to the evolution and maintenance of the GVFS system itself.


title: PARAMETERS
content:
<b>-d, --directory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitors the specified <I>FILE</I> as a directory. When this option is used, events related to the directory itself or its immediate children (depending on other options) will be reported.<br><br><b>--monitor-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When monitoring a directory (with <I>-d</I>), this option restricts monitoring to only the directory itself, ignoring changes within its subdirectories or files inside it.<br><br><b>--monitor-dirs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When monitoring a directory (with <I>-d</I>), this option specifically enables monitoring for changes to subdirectories within the specified directory.<br><br><b>--monitor-files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When monitoring a directory (with <I>-d</I>), this option specifically enables monitoring for changes to files within the specified directory.<br><br><b>-?, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a summary of available command-line options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the <I>gvfs-monitor-file</I> command.<br><br>


title: DESCRIPTION
content:
The <i>gvfs-monitor-file</i> command is a utility from the <B>GVFS (GNOME Virtual File System)</B> suite, designed to observe and report real-time changes to specified files or directories. GVFS provides a high-level abstraction layer for accessing various local and remote file systems, allowing applications to interact with them uniformly.<br><br>This command leverages the <B>GFileMonitor</B> API to detect events such as file creation, deletion, modification, moving, and attribute changes. It continuously watches the target and prints messages to standard output whenever an event occurs. This makes it invaluable for debugging applications that rely on GVFS, understanding file system activity in GNOME environments, or for developers needing to track how their files are being accessed or modified through the GVFS layer.


title: CAVEATS
content:
While useful, <i>gvfs-monitor-file</i> operates through the GVFS layer, which introduces some overhead compared to direct kernel interfaces like <i>inotify</i> or <i>fanotify</i>. It may not be suitable for extremely high-performance or low-latency file monitoring applications. Its output can be verbose, especially for directories with frequent changes. It also relies on the GVFS daemon (<I>gvfsd</I>) being active.


title: OUTPUT FORMAT
content:
The command prints events to standard output in a simple format, typically consisting of the event type followed by the path of the file or directory that changed. Common event types include <I>changed</I>, <I>deleted</I>, <I>moved</I>, and <I>attribute-changed</I>. For example: <br><br><i>changed /home/user/testfile.txt</i><br><i>deleted /home/user/olddir/</i><br><i>moved /home/user/tempfile.txt /home/user/newfile.txt</i>


title: GVFS BACKEND INTERACTION
content:
One of the key strengths of <i>gvfs-monitor-file</i> is its ability to monitor not just local files, but also files accessed via various GVFS backends, such as SMB shares (<I>smb://</I>), SFTP connections (<I>sftp://</I>), or even MTP devices (<I>mtp://</I>). This provides a unified way to observe file system events across different protocols and locations that GVFS supports, abstracting away the underlying complexities.


title: HISTORY
content:
<i>gvfs-monitor-file</i> emerged as part of the <B>GVFS (GNOME Virtual File System)</B> project, which was introduced to replace the older GConf and HAL components in GNOME desktop environments. Its primary purpose has always been to provide a debugging and introspection tool for GVFS, allowing developers and system administrators to observe how file system events are processed and reported through the GVFS stack. Its development mirrors that of the wider GNOME desktop, evolving with new versions of the GIO library.


title: SYNOPSIS
content:
gvfs-mount [OPTION...] LOCATION<br>gvfs-mount --unmount [OPTION...] LOCATION<br>gvfs-mount --unmount-all<br>gvfs-mount --list<br>gvfs-mount --monitor


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help text and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version number and exits.<br><br><b>-u, --unmount</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unmounts the given location.<br><br><b>--unmount-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unmounts all currently mounted locations.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently mounted locations.<br><br><b>-m, --monitor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitors mount and unmount operations.<br><br><b>-o, --options=OPTIONS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of options to pass to the mount operation. The exact options depend on the GVfs backend (e.g., cifs supports "user=USERNAME", "pass=PASSWORD", "domain=DOMAINNAME").<br><br><b>--private</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mount the location in private mode. This is mostly useful for GVfs backend implementations.<br><br><b>--do-not-show-ui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents any password or other user interface elements from being shown when mounting.<br><br><b>--anon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mounts anonymously without asking for a password.<br><br><b>--set-enabled</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the enabled state for the location. This is mostly useful for GVfs backend implementations.<br><br><b>--volumeid=VOLUMEID</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the given volume ID to mount the location. This is mostly useful for GVfs backend implementations.<br><br><b>-i, --detail</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows more detailed information when listing mounts.<br><br><b>--shell-interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in shell interactive mode.<br><br>


title: DESCRIPTION
content:
<i>gvfs-mount</i> is a command-line utility that interacts with GVfs (GNOME Virtual File System), a user-space abstraction for various network and local filesystems. It allows users to mount, unmount, and list GVfs locations, which can be URIs (e.g., <i>sftp://user@host/path</i>) or volume names (e.g., "My Disk").<br><br>GVfs provides transparent access to resources like FTP, SFTP, WebDAV, SMB/CIFS, MTP, and more, typically without requiring <b>root</b> privileges or specific kernel modules for each protocol. This command is particularly useful for scripting and managing GVfs mounts from the terminal. When run without arguments, it lists currently mounted locations. It also provides options for unmounting specific locations, unmounting all, monitoring mount operations, and passing protocol-specific options.


title: CAVEATS
content:
<i>gvfs-mount</i> relies on the GVfs daemon (<i>gvfsd</i>) being active. Its functionality may be limited or unavailable in environments where GVfs is not running or properly configured (e.g., non-GNOME desktop environments without <i>gvfsd-fuse</i>). The specific options for <i>-o, --options</i> are highly backend-dependent and not universally applicable; users should consult documentation for the respective GVfs backend (e.g., CIFS, FTP) for supported options.


title: LOCATION ARGUMENT
content:
The <b>LOCATION</b> argument for mounting or unmounting can be either a full URI (e.g., <i>sftp://user@host/path</i>) or a volume name (e.g., <i>"My Disk"</i> or <i>"USB Drive"</i>).


title: HISTORY
content:
GVfs (GNOME Virtual File System) was developed as a modern replacement for the older GnomeVFS library, aiming for improved performance, robustness, and extensibility in handling virtual filesystems. <i>gvfs-mount</i> emerged as a key command-line utility within this new framework, providing a consistent interface for managing remote and local resources within the GNOME ecosystem. Its development is integral to the evolution of the GNOME desktop environment, though it can be utilized independently.


title: SEE ALSO
content:
gvfs(7), gvfsd(1), gvfsd-fuse(1), gvfs-ls(1), gvfs-info(1), gvfs-cat(1), gvfs-copy(1), gvfs-move(1), gvfs-trash(1), gvfs-rm(1)


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version information and exit.<br><br>


title: DESCRIPTION
content:
<b>gvfs-move</b> is a command-line utility provided by the GNOME Virtual File System (GVFS) framework. It allows users to move files and directories, particularly when dealing with URIs (Uniform Resource Identifiers) that represent remote or virtual file systems (e.g., <I>sftp://</I>, <I>smb://</I>, <I>dav://</I>).<br><br>Unlike the traditional <I>mv</I> command, <I>gvfs-move</I> leverages GVFS's capabilities to handle these non-local paths seamlessly, providing a consistent interface for file operations across various backends. It's often used by desktop environments or scripts that need to interact with diverse network locations or special GVFS mounts.


title: CAVEATS
content:
<b>gvfs-move</b> operates on <I>GVFS URIs</I> and paths, not solely traditional local file paths. While it can move local files, its primary strength lies in handling remote or virtual locations.<br><br>It may not offer the same granular control (e.g., specific overwrite prompts, force options) as the standard <I>mv(1)</I> command, relying on GVFS's default behavior for conflict resolution.<br><br>Reliability for remote operations depends on the underlying network connection and the stability of the GVFS backend for the specific protocol being used. Errors during remote operations might be less verbose than those from lower-level network tools.


title: GVFS URIS
content:
GVFS commands operate on URIs (Uniform Resource Identifiers) which can represent various locations, including local paths (<I>file:///path/to/file</I>), remote connections (<I>sftp://user@host/path</I>), webDAV servers (<I>dav://server/path</I>), and more. Understanding the correct URI format for your target is crucial for successful operations.


title: DESKTOP INTEGRATION
content:
While a command-line tool, <b>gvfs-move</b> underpins much of the file movement functionality within GNOME's graphical file manager (Nautilus/Files) when dealing with remote or special locations. It ensures that file operations are handled consistently regardless of the underlying protocol.


title: HISTORY
content:
GVFS (GNOME Virtual File System) was introduced around GNOME 2.22 (2008) as a replacement for the older <I>GNOME-VFS</I> system. It was designed to provide a more robust, extensible, and asynchronous framework for file system abstraction, building upon the <I>GIO</I> library.<br><br>The <b>gvfs-move</b> command, along with other <I>gvfs-*</I> utilities, provides command-line access to these GVFS capabilities, enabling consistent file operations across various protocols and virtual file systems without needing to mount them traditionally or use protocol-specific tools. Its development is tied to the evolution of the GNOME desktop environment and its underlying infrastructure for file management.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--app</b>=<i>APPLICATION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an <i>APPLICATION</i> to open the <i>LOCATION(s)</i> with, overriding the default associated application. For example, <b>--app=gimp</b> to open an image with GIMP.<br><br><b><b>-L</b>, <b>--launch-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the application and immediately exits, without waiting for the application to finish or close.<br><br><b><b>-P</b>, <b>--print-uri</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the URI of the opened resource to standard output. This can be useful in scripting to get the canonical URI after opening.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and general usage information for the command.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the version information for the GIO library, which <b>gvfs-open</b> relies upon.<br><br>


title: DESCRIPTION
content:
The <b>gvfs-open</b> command is a utility from the <i>GVFS</i> (GNOME Virtual File System) suite, primarily designed for the GNOME desktop environment. Its core function is to open local files, directories, or various types of <i>URIs</i> (Uniform Resource Identifiers) using the user's preferred default application.<br><br>While named <b>gvfs-open</b>, it is typically a convenience symlink or wrapper to the more general <b>gio open</b> command, which is part of the GIO (Glib Input/Output) library. Therefore, its functionality and options are inherited directly from <b>gio open</b>.<br><br>It seamlessly handles diverse URI schemes such as <i>http://</i>, <i>ftp://</i>, <i>sftp://</i>, and <i>smb://</i>, allowing users to interact with remote resources as if they were local files. <b>gvfs-open</b> determines the correct application to launch by querying the GNOME desktop environment's <i>MIME type</i> and application associations. It's often used internally by GNOME applications to ensure consistent and intuitive file and URI handling.


title: CAVEATS
content:
The <b>gvfs-open</b> command is primarily designed for and most effective within GNOME or GTK+-based desktop environments, as it relies on <i>GVFS</i> and GNOME's desktop integration. In non-GNOME environments, it might not be present or function as expected; <b>xdg-open</b> is a more universal alternative for cross-desktop file opening.<br><br>As a symlink to <b>gio</b>, its behavior and available options are entirely dependent on the <b>gio open</b> subcommand. If <b>gio</b> itself is not installed or configured correctly, <b>gvfs-open</b> will not function.


title: UNDERLYING COMMAND
content:
It's crucial to understand that <b>gvfs-open</b> is typically a direct symlink to the <b>gio</b> executable, specifically executing its 'open' subcommand. This means that all parameters, capabilities, and underlying mechanisms are derived from <b>gio open</b>. When you run <b>gvfs-open</b>, you are effectively running <b>gio open</b>.


title: DESKTOP INTEGRATION
content:
This command leverages the rich desktop integration provided by GNOME. It consults the system's <i>MIME type</i> database and the user's default application preferences (often configured via the GNOME Control Center or file manager) to intelligently launch the correct application for a given file type or URI scheme. This makes it a key component in how GNOME applications handle external resources seamlessly.


title: HISTORY
content:
<b>gvfs-open</b> emerged as part of the <i>GVFS</i> (GNOME Virtual File System) project, which was developed to replace the older <i>GnomeVFS</i> in GNOME. <i>GVFS</i> provides a robust, user-space virtual filesystem layer, enabling applications to transparently access various remote resources (like <i>FTP</i>, <i>SFTP</i>, <i>SMB</i>, <i>HTTP</i>) as if they were local files. <br><br>The underlying mechanism, <i>GIO</i> (Glib Input/Output), is a crucial part of the GLib library, providing a modern and asynchronous I/O API. <b>gvfs-open</b> was introduced as a convenient wrapper or symlink to the <b>gio open</b> command, simplifying file and URI handling for end-users within the GNOME desktop environment, ensuring consistent behavior with user preferences and desktop integration settings.


title: PARAMETERS
content:
<b>OLD_URI</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Uniform Resource Identifier (URI) of the file or directory to be renamed.<br><br><b>NEW_URI</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Uniform Resource Identifier (URI) for the new name or location of the file or directory.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the command.<br><br>


title: DESCRIPTION
content:
<I>gvfs-rename</I> is a command-line utility that facilitates renaming files and directories using the <I>gvfs</I> (GNOME Virtual File System) backend. Unlike the standard <I>mv</I> command, which operates primarily on local filesystems, <I>gvfs-rename</I> leverages <I>gvfs</I> to interact with various file system types, including remote ones (e.g., SFTP, SMB, MTP, FTP, WebDAV), as if they were local. This allows users to perform rename operations on files located on network shares or other virtual locations transparently. It's particularly useful in GNOME-based desktop environments, where <I>gvfs</I> provides the underlying abstraction for file management applications like Nautilus. The command takes Uniform Resource Identifiers (URIs) as arguments, enabling it to specify paths on diverse protocols.


title: CAVEATS
content:
Requires the <I>gvfs</I> daemon and related components to be running and properly configured.<br><br>Renaming across different <I>gvfs</I> backends (e.g., from SFTP to SMB) is generally not supported; both URIs must typically refer to the same backend.<br><br>Network connectivity is required for remote URIs.<br><br>Permissions on the source and destination paths must be adequate for the rename operation to succeed.<br><br>URI syntax must be correct for the respective protocol (e.g., <I>sftp://user@host/path</I>, <I>smb://server/share/path</I>, <I>mtp://[device_id]/path</I>).


title: USAGE WITH URIS
content:
<I>gvfs-rename</I> operates on URIs, not traditional filesystem paths, which is its key distinction. A URI specifies the protocol, host (if applicable), and path. For example, to rename a file on an SFTP server, you might use:<br><br><I>gvfs-rename sftp://user@remotehost/oldname.txt sftp://user@remotehost/newname.txt</I><br><br>Similarly, for a local file, you can use the <I>file://</I> scheme:<br><br><I>gvfs-rename file:///home/user/oldfile.txt file:///home/user/newfile.txt</I><br><br>However, for local files, the standard <I>mv</I> command is typically more direct and efficient.


title: COMPARISON WITH MV
content:
While <I>gvfs-rename</I> performs a similar function to <I>mv</I> (renaming), its primary advantage lies in its ability to handle remote and virtual filesystems that <I>mv</I> cannot directly access without prior mounting. <I>mv</I> works on paths resolved by the kernel, whereas <I>gvfs-rename</I> uses the GIO library and <I>gvfs</I> backends to communicate with various protocols. For operations exclusively on local, mounted filesystems, <I>mv</I> remains the conventional and often preferred tool due to its directness and simplicity.


title: HISTORY
content:
<I>gvfs-rename</I> is a component of the <I>gvfs</I> project, which was developed to replace the older <I>gnome-vfs</I> (GNOME Virtual File System) library. Development on <I>gvfs</I> began around 2005-2006, aiming to provide a more modern, robust, and extensible framework for virtual file system access in the GNOME desktop environment. The shift from <I>gnome-vfs</I> to <I>gvfs</I> brought significant improvements in handling various network protocols and local media, making commands like <I>gvfs-rename</I> essential for performing file operations seamlessly across diverse storage locations. Its usage is tightly integrated with GNOME's file management capabilities.


title: PARAMETERS
content:
<b>-r, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove directories and their contents recursively.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore nonexistent files and arguments, never prompt.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt before every removal.<br><br><b>-I, --once-interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt once before removing more than three files, or when removing recursively. This option overrides -i.<br><br><b>--preserve-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not operate recursively on '/' (default behavior for safety).<br><br><b>--no-preserve-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate recursively on '/'.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>gvfs-rm</b> command is used to remove files and directories from specified locations accessible via the GNOME Virtual File System (GVFS). GVFS allows applications to access remote and virtual file systems (like SFTP, SMB, MTP, WebDAV, etc.) as if they were local.<br><br>Unlike the standard <i>rm</i> command, <b>gvfs-rm</b> operates on GVFS URIs (Uniform Resource Identifiers) which specify the protocol, user, host, and path. For instance, you can delete a file on an SFTP server using a URI like <i>sftp://user@host/path/to/file.txt</i>.<br><br>By default, <b>gvfs-rm</b> will not remove a directory unless the <i>-r</i> or <i>--recursive</i> option is explicitly used to indicate recursive deletion.


title: CAVEATS
content:
<b>gvfs-rm</b> requires explicit use of the <i>-r</i> or <i>--recursive</i> option to remove directories. This is a safety measure to prevent accidental deletion of directory contents.<br><br>It operates on GVFS URIs, which require correct syntax for protocol, user, host, and path to ensure the target location is correctly identified. Operating recursively on the root directory (<i>/</i>) is dangerous and prevented by default with <i>--preserve-root</i>.


title: <B>EXIT STATUS</B>
content:
On success, <b>gvfs-rm</b> returns 0. A non-zero exit code indicates an error during the removal process.


title: <B>GIO URI FORMAT</B>
content:
<b>gvfs-rm</b> uses GIO URI format for specifying locations. Examples include:<br><i>sftp://user@host/path/to/file.txt</i><br><i>smb://server/share/folder/</i><br><i>mtp://[usb:001,003]/Internal shared storage/DCIM/</i>


title: SEE ALSO
content:
rm(1), gvfs(7), gvfs-cat(1), gvfs-copy(1), gvfs-info(1), gvfs-ls(1), gvfs-mkdir(1), gvfs-move(1), gvfs-open(1), gvfs-rename(1), gvfs-trash(1)


title: PARAMETERS
content:
<b><i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target GVFS URI where the file content from standard input will be saved. Examples include 'file:///home/user/document.txt', 'sftp://user@host/path/file.pdf', or 'smb://server/share/document.odt'.<br><br><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 for the command and exits.<br><br><b><b>--overwrite</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If a file or directory already exists at the specified <i>URI</i>, this option forces <b>gvfs-save</b> to overwrite it.<br><br><b><b>--no-overwrite</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;This is the default behavior. If a file or directory already exists at the specified <i>URI</i>, <b>gvfs-save</b> will fail and report an error instead of overwriting it.<br><br><b><b>--progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays progress information (e.g., percentage complete) during the saving operation. This is particularly useful for large files or slow connections.<br><br><b><b>--display=</b><i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use. This is primarily relevant when the command interacts with X server components, such as for authentication dialogues.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, providing more verbose information for troubleshooting.<br><br>


title: DESCRIPTION
content:
The <b>gvfs-save</b> command is a utility within the GNOME Virtual File System (GVFS) framework. It enables applications to save arbitrary content to a specified GVFS URI. This URI can represent various backends, including local filesystems, remote network shares (SMB, SFTP, WebDAV), or other virtual locations managed by GVFS.<br><br>Typically, <b>gvfs-save</b> is invoked by graphical applications like Nautilus (GNOME's file manager) or other GNOME-based software to handle the saving process seamlessly. It reads the data to be saved from standard input (<i>stdin</i>) and writes it to the designated destination, managing tasks such as authentication, progress reporting, and error handling behind the scenes. It's a crucial component for providing a unified file management experience across diverse storage locations.


title: CAVEATS
content:
<b>gvfs-save</b> typically reads its input from standard input (<i>stdin</i>). This means it expects the content to be piped to it or redirected from a file. It is primarily a backend utility for applications, not commonly invoked directly by end-users in a terminal. Its functionality relies on the GVFS daemon (<b>gvfsd</b>) being active and properly configured to handle the specified URI scheme and backend.


title: INPUT SOURCE
content:
The command reads the file content to be saved from its standard input (<i>stdin</i>). For example, to save the output of a command or the content of an existing file: <i>echo 'Hello World' | gvfs-save file:///tmp/hello.txt</i> or <i>cat /etc/hosts | gvfs-save sftp://user@host/remote_hosts</i>.


title: APPLICATION INTEGRATION
content:
While callable from the command line, <b>gvfs-save</b>'s primary purpose is to serve as an internal helper for graphical applications within the GNOME desktop. Applications leverage its capabilities to provide transparent saving functionality to local or remote destinations without needing to manage the underlying protocol complexities themselves.


title: HISTORY
content:
<b>gvfs-save</b> is a component of the GVFS (GNOME Virtual File System) project, which was introduced to replace the older GNOME VFS library. GVFS was developed to provide a more modern, modular, and robust virtual filesystem layer for the GNOME desktop environment, leveraging D-Bus and GIO (Glib Input/Output) for better integration and extensibility. Its development focused on abstracting file operations across diverse locations and protocols, making saving and accessing files more consistent for applications and users.


title: PARAMETERS
content:
<b><i>FILE</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to the files or directories on which to set the attribute. These paths can be local or GVfs URIs (e.g., <i>sftp://user@host/path/to/file</i>).<br><br><b><i>ATTRIBUTE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the extended attribute to set or remove (e.g., <i>metadata::tag</i>, <i>user::comment</i>).<br><br><b><i>VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The value to assign to the attribute. If the <i>--remove</i> option is used, this argument is omitted.<br><br><b><b>--type</b>=<i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the data type of the attribute <i>VALUE</i>. Common types include <i>string</i>, <i>int32</i>, <i>uint32</i>, <i>boolean</i>, <i>byte_array</i>, <i>object</i>. If not specified, <i>string</i> is often assumed.<br><br><b><b>--value-type</b>=<i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>--type</b>.<br><br><b><b>--remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the command to remove the specified <i>ATTRIBUTE</i> from the <i>FILE</i>(s) instead of setting a new value.<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 the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>gvfs-set-attribute</i> is a command-line utility used to manage extended attributes on files and directories accessed through the GVfs (GNOME Virtual File System) framework. GVfs provides a unified abstraction layer for accessing various local and remote filesystems (such as FTP, SFTP, SMB, WebDAV, MTP, etc.) as if they were local files. Extended attributes are arbitrary metadata associated with a file or directory, beyond the standard permissions, timestamps, and ownership.<br><br>This command allows users to add, modify, or remove these custom attributes, enabling richer metadata management for files stored across diverse storage locations, including those accessed remotely via GVfs backends. It is particularly useful for applications that store custom information alongside files, like tagging, indexing, or content-specific flags.


title: CAVEATS
content:
Not all GVfs backends or underlying filesystems fully support extended attributes. The ability to set or retrieve attributes depends on the capabilities of the specific backend and the remote server/protocol.<br><br>Users must have appropriate write permissions on the file or directory to set or remove attributes. The command may fail silently or with generic errors if the backend does not support the operation or if there are permission issues.


title: ATTRIBUTE VALUE TYPES
content:
When setting an attribute, it's often crucial to specify its data type using <b>--type</b> or <b>--value-type</b>. This ensures proper interpretation and storage. Common types include:<br><ul><li><i>string</i>: Textual data.</li><li><i>int32</i>, <i>uint32</i>: Signed and unsigned 32-bit integers.</li><li><i>boolean</i>: True/False values (e.g., <i>true</i> or <i>false</i>).</li><li><i>byte_array</i>: Raw binary data.</li><li><i>object</i>: A more complex, structured data type, often represented as a serialized object.</li></ul>


title: HISTORY
content:
<i>gvfs-set-attribute</i> is an integral part of the GVfs project, which was developed as a replacement for the older GnomeVFS in the GNOME desktop environment. Introduced around GNOME 2.22 / 2.24 (circa 2008), GVfs aimed to provide a more robust, scalable, and modular virtual filesystem layer.<br><br>This command, along with others like <i>gvfs-info</i> and <i>gvfs-cat</i>, provides command-line access to GVfs functionalities, allowing scripting and management of files across diverse network protocols and local media without direct reliance on graphical interfaces. Its development has mirrored the evolution of GVfs itself, focusing on expanding supported protocols and improving stability.


title: PARAMETERS
content:
<b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show help options and exit.</I><br><br><b><B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show version information and exit.</I><br><br><b><B>--empty</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Empty the trash bin.</I><br><br>


title: DESCRIPTION
content:
gvfs-trash is a command-line utility provided by the GNOME Virtual File System (GVFS) suite, designed to offer a safe alternative to permanent deletion. Its primary purpose is to move specified files or directories to the user's trash bin, rather than permanently removing them from the file system. This functionality is crucial for preventing accidental data loss, as it allows for easy recovery of items that might have been inadvertently deleted. It mimics the familiar "move to trash" behavior found in graphical desktop environments, providing a consistent user experience across different interaction methods. The command intelligently respects the XDG Base Directory Specification for determining the trash location, which is typically found at <I>~/.local/share/Trash</I> on most Linux systems. Unlike the <I>rm</I> command, which permanently deletes files, <I>gvfs-trash</I> offers a non-destructive way to remove files from their current location while keeping them accessible for potential restoration.


title: CAVEATS
content:
<ul><li><I>gvfs-trash</I> relies on GVFS being installed and running, which is standard in GNOME-based desktop environments.</li><li>When used without the <B>--empty</B> option, it expects file paths as arguments. If no files are specified on the command line, it reads file paths from standard input, one per line.</li><li>Files moved to the trash bin still consume disk space until the trash is explicitly emptied.</li><li>It may not function as expected on non-GVFS managed file systems or if the <I>gvfsd</I> daemon is not running.</li><li>Trash functionality is typically per-user; items trashed by one user are not directly accessible from another user's trash bin.</li></ul>


title: STANDARD INPUT USAGE
content:
<I>gvfs-trash</I> is capable of accepting file paths from standard input. If no file arguments are provided on the command line, it will read file paths (one per line) from stdin. This feature is particularly useful for piping output from other commands, for instance, <B>find . -name "*.tmp" | gvfs-trash</B> to trash all temporary files found in the current directory tree.


title: TRASH LOCATION
content:
The user's trash bin location is typically defined by the XDG Base Directory Specification, commonly found at <I>~/.local/share/Trash</I>. Within this directory, trashed items are stored in the <I>files/</I> subdirectory, while associated metadata (such as original path and deletion date) is stored in the <I>info/</I> subdirectory. This structured approach helps manage and restore trashed files effectively.


title: HISTORY
content:
<I>gvfs-trash</I> is an integral part of the GVFS (GNOME Virtual File System) project, which was developed to supersede the older GNOME VFS library. GVFS provides a modern, modular, and extensible architecture for managing various file systems and protocols within the GNOME desktop environment. <I>gvfs-trash</I> was introduced as a convenient command-line utility to interact seamlessly with the standard trash mechanism provided by GVFS, thereby aligning the command-line file management experience with the graphical desktop's familiar "move to trash" functionality. Its ongoing development reflects the evolution of the GNOME desktop itself, emphasizing user convenience, consistency, and data safety.


title: SEE ALSO
content:
rm(1): <I>Remove files or directories permanently.</I>, mv(1): <I>Move (rename) files.</I>, gvfs(7): <I>GNOME Virtual File System documentation.</I>, trash-cli(1): <I>A command-line interface for the trashcan, often used as an alternative.</I>


title: PARAMETERS
content:
<b>-s, --status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed status information for each <I>GVfs</I> mount point, providing more context than the default output.<br><br><b>-u, --uris</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the Universal Resource Identifier (URI) for each <I>GVfs</I> mount point, indicating the source of the virtual filesystem.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a concise help message with available command options and usage information.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version number of the <I>gvfs-tree</I> utility.<br><br>


title: DESCRIPTION
content:
The <i>gvfs-tree</i> command is a utility designed to display the hierarchical structure of mount points within the <I>GVfs</I> (GNOME Virtual File System).<br><br>GVfs is a userspace virtual filesystem that provides applications with access to various remote and local resources, such as FTP, SFTP, WebDAV, SMB/CIFS shares, MTP devices, and archives, treating them as if they were local filesystems. Unlike traditional kernel-level mounts, GVfs operates at the application level, abstracting the complexities of different protocols.<br><br>When executed, <i>gvfs-tree</i> presents a tree-like view of all currently active GVfs mounts, showing their relationships and underlying protocols. This command is invaluable for debugging, understanding how applications are accessing remote resources, or simply gaining insight into the GVfs daemon's current state. It helps users and developers visualize the dynamic virtual filesystem landscape managed by GVfs, including details like the mount URI and the backend handling the connection.


title: CAVEATS
content:
Requires the <I>GVfs</I> daemon to be running; if no virtual filesystems are mounted, the output will be minimal or empty.<br><i>gvfs-tree</i> shows userspace virtual mounts, not kernel-level mounts viewable via commands like <b>mount</b> or <b>df</b>.<br>The information presented is specific to the current user's active <I>GVfs</I> sessions.


title: WHAT IS GVFS?
content:
<I>GVfs</I> is a userspace virtual filesystem abstraction layer designed for the GNOME desktop environment. It allows applications to access various forms of data (local files, remote shares, MTP devices, archives) through a unified API, making them appear as standard filesystem objects. It handles authentication, protocol details, and error recovery transparently, enhancing the user experience by integrating diverse sources into the desktop environment.


title: GVFS AND GIO
content:
<I>GVfs</I> is built on top of <I>GIO</I>, which is the I/O abstraction layer of the GLib library. <I>GIO</I> provides an object-oriented API for various I/O operations, including file operations, network sockets, and asynchronous I/O. <I>GVfs</I> extends <I>GIO</I>'s capabilities by providing concrete implementations for various URI schemes and network protocols, making them accessible through <I>GIO</I>'s standard file operations. This symbiotic relationship ensures a consistent and modern approach to file handling in GNOME.


title: HISTORY
content:
<I>GVfs</I> (GNOME Virtual File System) was introduced to replace <I>libgnomevfs</I>, which was part of older GNOME versions. The transition to <I>GVfs</I>, built on top of <I>GIO</I> (GLib Input/Output), aimed to provide a more robust, extensible, and asynchronous I/O framework for the GNOME desktop environment.<br><br>The <I>gvfs-tree</I> command, being a part of this suite, emerged as a direct way to inspect the virtual filesystem structure managed by <I>GVfs</I>, offering an essential diagnostic tool for users and developers alike as <I>GVfs</I> became central to file handling in GNOME.


title: SEE ALSO
content:
<b>gvfs-mount(1)</b>: Manages <I>GVfs</I> mount points., <b>gvfs-ls(1)</b>: Lists contents of <I>GVfs</I> locations., <b>gvfsd(8)</b>: The main <I>GVfs</I> daemon., <b>gio(1)</b>: A general command-line utility for <I>GIO</I> operations, which <I>GVfs</I> extends.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints</i> a summary of command-line options and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints</i> the version information and exits.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables</i> verbose debugging output to standard error.<br><br><b>--no-daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Runs</i> <i><b>gvfsd</b></i> in the foreground instead of daemonizing. Useful for debugging.<br><br><b>--no-mount</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prevents</i> <i><b>gvfsd</b></i> from automatically mounting the GvfsFilesystem. Primarily for internal debugging.<br><br>


title: DESCRIPTION
content:
<i><b>gvfsd</b></i> is the main daemon for the <b>G</b>NOME <b>V</b>irtual <b>F</b>ile <b>S</b>ystem (GVFS), a crucial component of modern GNOME-based desktop environments. It provides a high-level, D-Bus-based abstraction layer for various file systems and storage mechanisms, allowing applications to access local, remote (e.g., FTP, SMB, SSH, WebDAV), and special file systems (like Trash, CD/DVD drives, MTP devices) in a unified manner. <br><br>The daemon orchestrates communication between applications (which use the GIO library) and the various GVFS backends (e.g., gvfs-sftp-volume-monitor, gvfs-smb-volume-monitor). It handles mounting, unmounting, and managing these file systems, making them appear as standard directories in the user's home directory (e.g., under <i>~/.gvfs/</i> or <i>/run/user/&lt;uid&gt;/gvfs/</i>). <br><br>Typically, <i><b>gvfsd</b></i> runs as a background process for each user session, automatically started by the desktop environment (like <i><b>gnome-session</b></i>). Its robust design allows file managers like Nautilus and other GNOME applications to seamlessly browse and interact with diverse data sources without needing to understand the underlying protocol specifics.


title: CAVEATS
content:
<i><b>gvfsd</b></i> is a system daemon designed for automatic operation within a desktop environment. Direct manual execution or termination by an end-user is generally not recommended as it can disrupt file browsing and application functionality in GNOME.<br><br>It relies heavily on the D-Bus message bus system for inter-process communication. If D-Bus is not running or misconfigured, <i><b>gvfsd</b></i> may not function correctly.


title: D-BUS INTEGRATION
content:
<i><b>gvfsd</b></i> exposes its services via D-Bus, allowing applications using the GIO library to interact with various file systems without needing to know the specifics of the underlying protocols. This D-Bus-centric architecture enables a highly modular and extensible system where new backends can be added without modifying the core daemon.


title: DEBUGGING GVFS
content:
For debugging issues with GVFS, one can run <i><b>gvfsd</b></i> in the foreground with debug output. A common method is to use: <br><i><b>G_MESSAGES_DEBUG=all gvfsd --no-daemon</b></i> <br>This command provides detailed logs that can help in diagnosing problems with specific GVFS backends or file operations.


title: HISTORY
content:
<i><b>gvfsd</b></i> and the GVFS framework were introduced as part of GNOME 2.22 (released in March 2008) to modernize and eventually replace the older GNOME VFS (Virtual File System). The primary motivations for this transition were to leverage the then-newer GIO (GLib I/O) library for I/O operations, improve extensibility with D-Bus services, and provide better integration with non-local filesystems. <br><br>The older GNOME VFS had limitations, particularly with asynchronous operations and D-Bus integration. GVFS was designed from the ground up to address these, offering a more robust and flexible architecture for handling file operations across various protocols and media. Its development marked a significant step in enhancing user experience by providing seamless access to diverse data sources within the GNOME desktop.


title: SYNOPSIS
content:
<b>gvfsd-fuse</b><br><i>(Typically launched automatically by the GVfs infrastructure, not for direct user invocation.)</i>


title: DESCRIPTION
content:
The <b>gvfsd-fuse</b> command is a crucial component of GVfs (GNOME Virtual File System), which integrates various remote and virtual file systems directly into the GNOME desktop environment. Its primary function is to act as a bridge, making these diverse resources accessible through the standard Linux filesystem hierarchy. It achieves this by leveraging <i>FUSE</i> (Filesystem in Userspace), a powerful mechanism that allows unprivileged users to create their own filesystems without kernel modification. <br><br>When a GVfs backend (such as SFTP, WebDAV, SMB, or MTP) is accessed, <b>gvfsd-fuse</b> is automatically launched via D-Bus activation. It then takes the virtual filesystem provided by GVfs and presents it as a standard mount point. This allows users to interact with remote shares, MTP devices, and other virtual resources just as if they were local files or directories, using any standard file manager, command-line tool, or application. This seamless integration greatly enhances the usability of networked and non-traditional storage within the GNOME desktop.


title: CAVEATS
content:
<b>gvfsd-fuse</b> is a backend daemon intended for automatic activation by GVfs and D-Bus; users should generally not attempt to run it directly. It requires the FUSE kernel module to be loaded and functional. The actual mount points created are typically in the user's runtime directory, e.g., <i>/run/user/&lt;UID&gt;/gvfs</i> or older <i>~/.gvfs</i>. Multiple active GVfs mounts can consume system resources (memory, CPU) depending on their number and type.


title: AUTOMATIC ACTIVATION
content:
Unlike most commands, <b>gvfsd-fuse</b> is not typically run manually. It is automatically launched by the GVfs daemon and D-Bus whenever a GVfs-supported resource (like an SFTP share, MTP device, or SMB share) is accessed, ensuring that the necessary FUSE mount points are created on demand.


title: MOUNT POINT LOCATION
content:
Virtual filesystems exposed by <b>gvfsd-fuse</b> are usually mounted under a specific path in the user's environment. In modern systems, this is typically within the user's runtime directory, such as <i>/run/user/&lt;UID&gt;/gvfs</i>. On older systems, it might have been found under <i>~/.gvfs</i>. These directories contain the actual accessible mount points for GVfs resources.


title: HISTORY
content:
<b>gvfsd-fuse</b> is an integral part of <i>GVfs</i> (GNOME Virtual File System), which was developed to replace the older, less flexible <i>GnomeVFS</i>. The transition to GVfs, which began around 2007, brought significant improvements, particularly its reliance on D-Bus for inter-process communication and its modular design. The adoption of <i>FUSE</i> (Filesystem in Userspace) by GVfs, facilitated by components like <b>gvfsd-fuse</b>, was a key development. FUSE allowed GVfs to present remote and virtual resources as standard mount points, making them accessible to any application that understands traditional file system paths, without requiring root privileges or complex kernel modifications. This marked a significant step forward in desktop integration of diverse data sources.


title: PARAMETERS
content:
<b><code>--version</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of the <b><code>gvfsd-metadata</code></b> daemon.<br><br><b><code>--debug</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output, which can be useful for troubleshooting issues.<br><br><b><code>--display=DISPLAY</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the X display to connect to (typically for session management). This option is usually handled by the session manager.<br><br><b><code>--sm-client-id=ID</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a session management client ID. Used for integrating with the desktop session.<br><br><b><code>--sm-disable</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable session management capabilities for the daemon, preventing it from interacting with the session manager.<br><br><b><code>--sm-no-xserver</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent the daemon from connecting to an X server for session management purposes. Useful in non-graphical environments.<br><br><b><code>--sync</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize the metadata database, potentially forcing writes of pending changes.<br><br><b><code>--no-daemon</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the <b><code>gvfsd-metadata</code></b> process in the foreground instead of detaching as a daemon. Useful for debugging.<br><br>


title: DESCRIPTION
content:
<b><code>gvfsd-metadata</code></b> is a background daemon that forms a core component of the GNOME Virtual File System (GVfs), specifically handling file metadata. It provides a centralized and persistent storage mechanism for attributes such as file tags, comments, star ratings, and other user-defined properties, which are then accessible by applications like Nautilus (Files).<br><br>The daemon primarily uses extended attributes (xattrs) to store metadata directly on files where supported by the filesystem. For filesystems that do not support xattrs, or for more complex indexing and search capabilities, it also utilizes a SQLite database typically located at <i><code>~/.local/share/gvfs-metadata</code></i>. This hybrid approach ensures metadata persistence and efficient retrieval.<br><br>Users rarely interact with <b><code>gvfsd-metadata</code></b> directly. It is automatically launched by <b><code>gvgvfsd</code></b> or the user's session manager when an application requests metadata functionality. Its primary role is to ensure a consistent and reliable metadata experience across the GNOME desktop environment.


title: CAVEATS
content:
<ul><li><b><code>gvfsd-metadata</code></b> is an internal system daemon; direct user interaction or manual invocation with parameters is typically not required for normal operation.</li><li>Its performance can be affected by the number of files and the volume of metadata being managed, especially during initial indexing or extensive metadata changes.</li><li>Metadata stored via <b><code>gvfsd-metadata</code></b> might not be portable to systems that do not use GVfs or do not properly support extended attributes.</li></ul>


title: METADATA STORAGE MECHANISM
content:
GVfs metadata is stored using a combination of extended attributes (xattrs) on individual files for filesystems that support them, and a SQLite database located at <i><code>~/.local/share/gvfs-metadata</code></i> for indexing, search, and storing metadata for files on filesystems without xattr support. The daemon manages the consistency between these two storage methods.


title: AUTOMATIC OPERATION
content:
This daemon is not meant for manual execution by end-users. It is automatically launched by the primary <b><code>gvfsd</code></b> daemon or the user's desktop session manager whenever a GNOME application (like Nautilus or Evince) attempts to read or write metadata associated with files. Its background operation ensures seamless metadata handling for desktop applications.


title: HISTORY
content:
<b><code>gvfsd-metadata</code></b> is an integral part of the GVfs (GNOME Virtual File System) framework, which was developed to replace the older GNOME VFS. GVfs, and consequently <b><code>gvfsd-metadata</code></b>, was designed to provide a more modern, extensible, and robust way for GNOME applications to interact with various file systems and network resources. The metadata daemon specifically addresses the growing need for rich file metadata management in desktop environments, enabling features like tagging and advanced searching that go beyond basic file system attributes. Its development reflects the evolution of desktop environments towards more semantic file management.


title: SYNOPSIS
content:
<b>gvpack</b> [ <i>options</i> ] [ <i>files</i> ]<br><br><i>files</i>: One or more Graphviz DOT language files containing graphs to be packed. If no files are specified, <b>gvpack</b> reads from standard input.


title: PARAMETERS
content:
<b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use node adjacency to determine how graphs are clustered and packed. Useful for breaking large graphs into smaller components.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Place each connected component of a graph on its own separate page.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pad each packed graph with an empty margin, typically a default of 8 points.<br><br><b><b>-G</b><i>attr</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a default graph attribute. For example, <b>-G'pad=0.5'</b> can modify the padding of graphs.<br><br><b><b>-L</b><i>flags</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the level of packing. <i>flags</i> can be combinations of '<i>x</i>' (pack by x-coordinate), '<i>y</i>' (pack by y-coordinate), '<i>c</i>' (connected components), '<i>m</i>' (master graphs), '<i>a</i>' (array-based packing).<br><br><b><b>-m</b><i>margin</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the page margin for the output. This value specifies the space around the packed graphs.<br><br><b><b>-o</b><i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the packed graph to the specified <i>output_file</i>. If omitted, output goes to standard output.<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pack all graphs onto a single page. This is the default behavior if no other page-related flags are specified.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unpack graphs. This reverses the packing operation, potentially expanding previously packed graphs.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, providing information about the packing process.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Place each graph from the input files on its own separate page.<br><br>


title: DESCRIPTION
content:
<b>gvpack</b> is a utility from the Graphviz suite designed to arrange multiple independent graphs onto a smaller combined space, typically a single page, by minimizing the empty space between them. It takes one or more Graphviz DOT language files as input, which may contain single or multiple graphs.<br><br><b>gvpack</b> applies algorithms to reposition these graphs such that they are tightly packed without overlapping, while preserving their internal layouts. This is particularly useful when visualizing many small graphs, such as components of a larger system, on a single output document. The command can output the packed graph in various formats, including DOT, allowing further processing by other Graphviz layout engines like <b>dot</b> or <b>neato</b> for final rendering. It significantly aids in creating more compact and readable composite visualizations.


title: CAVEATS
content:
<b>gvpack</b> aims for efficiency but does not guarantee the absolute optimal packing arrangement in all cases, especially for complex graph collections.<br><br>Extremely large graphs or a very high number of graphs might still result in layouts that require manual adjustments or alternative strategies.<br><br>While <b>gvpack</b> minimizes overlap between distinct graphs, internal node/edge overlaps within a single graph are handled by the layout engine (e.g., <b>dot</b>, <b>neato</b>) that processes the output of <b>gvpack</b>.


title: TYPICAL WORKFLOW
content:
<b>gvpack</b> is often used as a preprocessing step in a Graphviz pipeline. A common workflow involves piping the output of <b>gvpack</b> to another Graphviz layout engine for final rendering.<br>Example: <i>cat</i> graphs/*.dot | <b>gvpack -P | dot -Tpng -o</b> combined_graphs.png


title: INPUT AND OUTPUT
content:
The primary input format for <b>gvpack</b> is the Graphviz DOT language. The output is also in DOT format by default, making it interoperable with other Graphviz tools. This allows for flexible pipelines where packing is just one step in a larger visualization process.


title: HISTORY
content:
<b>gvpack</b> is an integral part of the open-source Graphviz graph visualization software suite, which originated at AT&T Labs Research. Developed to address the challenge of efficiently visualizing multiple graphs, it became a crucial utility for generating composite layouts. Its evolution parallels the broader development of Graphviz, continuously improving algorithms for better graph packing and layout optimization, adapting to diverse visualization needs for complex data structures and networks.


title: PARAMETERS
content:
<b><b>-P</b><i>printer</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific printer device for rendering. This parameter sets the default device that <I>gxditview</I> uses for its internal display calculations, which can affect font metrics and page layout.<br><br><b><b>-r</b><i>res</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Ignored) Intended to set the horizontal device resolution in dots per inch (dpi). However, in current versions, this option has no effect on the display.<br><br><b><b>-s</b><i>res</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Ignored) Intended to set the vertical device resolution in dots per inch (dpi). Similar to <b>-r</b>, this option is currently not functional.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version number of <I>gxditview</I> and then exits immediately.<br><br><b><i>file</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to <I>ditroff</I> formatted files to be displayed. If no file arguments are provided, <I>gxditview</I> will read its input from standard input (stdin).<br><br><b><b>-display</b> <i>display</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to specify the X display server to connect to (e.g., ':0.0').<br><br><b><b>-geometry</b> <i>geometry</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to set the initial size and position of the viewer window (e.g., '800x600+100+50').<br><br><b><b>-bg</b> <i>color</i> or <b>-background</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to set the background color of the viewer window.<br><br><b><b>-fg</b> <i>color</i> or <b>-foreground</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to set the foreground color (text color) of the viewer window.<br><br><b><b>-font</b> <i>fontname</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to set the default font to be used by the viewer's GUI elements.<br><br><b><b>-title</b> <i>string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to set the title of the viewer window.<br><br><b><b>-name</b> <i>string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to set the application name, used for resource lookups in X resource databases.<br><br><b><b>-xrm</b> <i>resourcestring</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard X option to specify an arbitrary X resource string to be loaded and applied.<br><br>


title: DESCRIPTION
content:
<i>gxditview</i> is a graphical viewer for files formatted in the <I>groff ditroff</I> output format. It's part of the <I>groff</I> document formatting system, designed to display documents processed by commands like <I>groff -Tdit</I>. Utilizing the X Window System, <I>gxditview</I> provides an interactive interface to view formatted text, including support for various fonts, sizes, and basic graphics, as interpreted from the <I>ditroff</I> stream. Users can navigate through pages, zoom in and out, and even print documents directly from the viewer. It's particularly useful for authors and developers working with <I>groff</I> to preview their formatted output before final production or printing, ensuring the layout and content appear as intended. The command supports loading multiple files and can also read its input from standard input, making it versatile for piping output from other <I>groff</I> commands.


title: CAVEATS
content:
The <I>-r</I> and <I>-s</I> options for setting device resolution are currently ignored, meaning <I>gxditview</I> does not respect these settings for rendering its output. <br> Only the <I>ditroff</I> output format is parsed and displayed. <I>gxditview</I> does not support device-specific outputs generated by other <I>groff</I> drivers, such as <I>grops</I> (PostScript) or <I>gxdvi</I> (DVI). <br> Page headers, if present in the <I>ditroff</I> stream, are not displayed by the viewer. <br> As a graphical application, <I>gxditview</I> requires the X Window System to be running and accessible.


title: INPUT SOURCE
content:
If no <i>file</i> arguments are provided on the command line, <I>gxditview</I> will automatically read its <I>ditroff</I> input from standard input (stdin). This makes it highly versatile for use in pipelines, for example, to directly view the output of a <I>groff</I> command: <br> <b>groff -Tdit </b><i>myfile.txt</i><b> | gxditview</b>


title: X RESOURCES
content:
Like many X applications, <I>gxditview</I> respects X resources. This allows for extensive customization of its appearance and behavior through your X resource database (e.g., defined in files like <I>.Xdefaults</I> or <I>.Xresources</I> in your home directory, or via the <I>xrdb</I> utility).


title: HISTORY
content:
<i>gxditview</i> emerged as part of the GNU <I>groff</I> project, a free software implementation of the <I>troff</I>/<I>ditroff</I> document formatting system. Its development aimed to provide a modern, graphical interface for previewing <I>groff</I>'s device-independent <I>ditroff</I> output directly within the X Window System environment. Prior to its widespread use, users might have relied on simpler, text-based viewers or an older X viewer like <I>xditview</I>, or had to convert <I>ditroff</I> output to other formats (e.g., PostScript) for viewing. <I>gxditview</I> offered an integrated and more user-friendly solution for developers and authors working with <I>groff</I>, allowing for immediate visual feedback on their formatted documents without leaving the graphical environment.


title: PARAMETERS
content:
<b><I>-o outfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output file. If this option is not provided, <b>gxl2gv</b> writes the converted GV (DOT) output to standard output (<i>stdout</i>).<br><br><b><I>files</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input files in GXL format to be converted. If no files are specified, <b>gxl2gv</b> reads its input from standard input (<i>stdin</i>).<br><br>


title: DESCRIPTION
content:
The <b>gxl2gv</b> command is a utility within the Graphviz suite designed to transform graph data from the GXL (Graph eXchange Language) format into the GV (Graphviz DOT) language. GXL is an XML-based standard for representing and exchanging graph structures, commonly used in various graph-related applications. The GV (DOT) language, on the other hand, is Graphviz's proprietary plain text graph description language, widely used for specifying graphs that can then be rendered into visual representations (like images or PDFs) by other Graphviz tools such as <i>dot</i>, <i>neato</i>, or <i>fdp</i>. <br><br>This conversion utility acts as a bridge, allowing users who have graph data in GXL format to leverage the powerful visualization capabilities of Graphviz. It reads a GXL file (or standard input), parses its graph structure, and outputs a corresponding DOT file (or to standard output), which can then be directly fed into a Graphviz renderer for visualization.


title: CAVEATS
content:
The output of <b>gxl2gv</b> is a DOT language file, not a direct graphical rendering. To visualize the graph, the generated DOT file must be processed by another Graphviz layout and rendering engine (e.g., <i>dot</i>, <i>neato</i>, <i>fdp</i>). <br>Input GXL files must conform to the GXL DTD or schema; malformed input may result in errors or unexpected output.


title: USAGE WITH STANDARD INPUT/OUTPUT
content:
<b>gxl2gv</b> can be used effectively in pipelines. For instance, to convert GXL from one source and immediately render it: <br><br><b>cat input.gxl | gxl2gv | dot -Tpng -o output.png</b>


title: GXL AND DOT LANGUAGE
content:
While GXL is a comprehensive XML-based standard for graph data exchange, providing rich semantic information, the DOT language focuses on the structural and visual attributes of graphs for rendering. <b>gxl2gv</b> performs a syntactic transformation, mapping GXL graph elements (nodes, edges, attributes) to their DOT equivalents to enable visualization.


title: HISTORY
content:
<b>gxl2gv</b> is part of the open-source Graphviz project, which was originally developed at AT&T Labs Research. Graphviz, an acronym for Graph Visualization Software, has been continuously developed to provide a powerful and flexible platform for drawing abstract graphs and networks. <b>gxl2gv</b> was introduced as a specialized utility to facilitate interoperability between the GXL graph exchange standard and Graphviz's native DOT language, reflecting the project's commitment to supporting various graph data formats for visualization purposes.


title: SYNOPSIS
content:
<i>gyb</i> [--email &lt;email_address&gt;] [--action &lt;action&gt;] [--service &lt;service&gt;] [options]<br>Example: <i>gyb</i> --email user@example.com --action backup --service gmail --folder inbox


title: PARAMETERS
content:
<b>--email &lt;email_address&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Google Workspace user account to operate on.<br><br><b>--action &lt;action&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the operation to perform (e.g., <i>backup</i>, <i>restore</i>, <i>info</i>, <i>purge</i>).<br><br><b>--service &lt;service&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Google service to interact with (e.g., <i>gmail</i>, <i>calendar</i>, <i>drive</i>, <i>contacts</i>, <i>keep</i>, <i>photos</i>).<br><br><b>--oauth &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the OAuth2 client secrets file.<br><br><b>--local-folder &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the local directory for storing backup data.<br><br><b>--messages &lt;query&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Gmail) Filters messages based on a Gmail search query.<br><br><b>--folder &lt;folder_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Gmail) Specifies specific Gmail folders/labels to back up.<br><br><b>--all-labels</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Gmail) Backs up messages from all labels, including system labels.<br><br><b>--restore-to &lt;email_address&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Restore) Specifies the target email for restoration.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output for troubleshooting.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current <i>gyb</i> version and exits.<br><br>


title: DESCRIPTION
content:
<i>gyb</i> (Got Your Back) is a powerful and flexible command-line tool designed for backing up and restoring data from Google Workspace (formerly G Suite) accounts. It supports comprehensive backups of various Google services, including <b>Gmail</b> messages, <b>Google Calendar</b> events, <b>Google Drive</b> files, <b>Google Contacts</b>, <b>Google Keep</b> notes, and <b>Google Photos</b> metadata.<br><br>Developed primarily in Python, <i>gyb</i> is cross-platform and can run on Linux, macOS, and Windows. It leverages Google's APIs for secure authentication via OAuth2, ensuring that your data is accessed with appropriate permissions. Its key strength lies in its ability to perform incremental backups, only downloading new or changed data, which saves bandwidth and time. <i>gyb</i> is widely used by individuals and administrators for archiving important Google data or migrating it between accounts. It's a non-GUI solution, making it ideal for scripting and automated backup tasks.


title: CAVEATS
content:
<i>gyb</i> requires initial setup for OAuth2 authentication with Google, which involves creating a Google Cloud Project and obtaining client secrets. This process can be complex for new users. Data limitations and API quotas imposed by Google can affect large backup operations. While powerful, <i>gyb</i> is a command-line tool, which may not be suitable for users preferring a graphical interface. It's crucial to regularly update <i>gyb</i> to ensure compatibility with Google's evolving APIs and security protocols.


title: AUTHENTICATION SETUP
content:
<i>gyb</i> requires a one-time setup of OAuth2 client secrets through the Google Cloud Console. This process generates a <i>client_secrets.json</i> file, which <i>gyb</i> uses to authenticate with your Google account. Detailed instructions are available on the official <i>gyb</i> documentation.


title: INCREMENTAL BACKUPS
content:
One of <i>gyb</i>'s most valuable features is its ability to perform incremental backups. After the initial full backup, subsequent runs only download new or changed data, significantly reducing backup time and bandwidth usage. This is managed by <i>gyb</i> tracking the state of your data locally.


title: HISTORY
content:
<i>gyb</i> was created by <i>Jay Lee</i> and first released around 2011-2012, initially focusing on Gmail backups. Over the years, its capabilities expanded significantly to include other Google Workspace services like Calendar, Drive, Contacts, Keep, and Photos. Its development has been driven by the need for robust, automated, and secure command-line backups for Google's ecosystem. <i>gyb</i> gained popularity among system administrators, IT professionals, and technically proficient users due to its reliability and comprehensive feature set for managing Google data outside of the web interface. It continues to be actively maintained, adapting to changes in Google's APIs and adding new features.


title: PARAMETERS
content:
<b><i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompresses the specified <b>gzexe</b> file(s) back to their original uncompressed state.<br><br><b><i>name ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more executable files to be compressed or decompressed by <b>gzexe</b>.<br><br>


title: DESCRIPTION
content:
<b>gzexe</b> is a shell script that allows you to compress executable files while still being able to run them transparently. When you run <b>gzexe</b> on an executable, it replaces the original file with a compressed version that has a small shell script prepended to it. This script's purpose is to decompress the original executable into a temporary file (usually in <i>/tmp</i> or <i>/var/tmp</i>) and then execute it. The primary benefit of <b>gzexe</b> is disk space saving, particularly useful for large, infrequently used binaries. It effectively wraps the <b>gzip</b> compression and <b>zcat</b> decompression into a self-executing package. The original executable is preserved with a <i>~</i> suffix.


title: CAVEATS
content:
<i><br>Performance Overhead</i>: Executables processed by <b>gzexe</b> incur a slight delay on execution due to the decompression step, making it unsuitable for frequently used or performance-critical applications.<br><i>Temporary Files</i>: <b>gzexe</b> creates temporary files (e.g., in <i>/tmp</i>) during execution. While modern implementations use secure methods, the underlying mechanism relies on temporary file handling, which can be a point of concern if not properly secured.<br><i>Disk Space During Execution</i>: While it saves space on disk for the compressed binary, it requires additional temporary space for decompression during each execution.<br><i>Original File Renaming</i>: The original executable is renamed with a <i>~</i> suffix (e.g., <i>program~</i>), which might affect scripts or tools expecting the exact original file path.<br><i>Compatibility</i>: Primarily designed for standalone executables; may not work correctly with shared libraries or complex multi-file binaries.


title: WORKING MECHANISM
content:
When a file processed by <b>gzexe</b> is executed, the prepended shell script first checks for necessary permissions and temporary space. It then uses <b>zcat</b> to decompress the embedded original executable into a temporary file in a secure location (e.g., <i>/tmp</i> or <i>/var/tmp</i>). Once decompressed, the script executes this temporary file. After the execution finishes, the temporary file is typically removed, although abnormal termination might leave it behind. The temporary file is usually created with appropriate permissions to prevent unauthorized access.


title: SECURITY CONSIDERATIONS
content:
The reliance on temporary files for decompression, while generally handled securely by modern <b>gzexe</b> implementations using facilities like <b>mktemp</b>, historically posed potential vulnerabilities. Concerns included race conditions or symbolic link attacks if the temporary directory was not properly secured or if the script's handling of temporary files was naive. Users should ensure their temporary directories are configured securely (e.g., with <i>noexec</i> where appropriate, though <b>gzexe</b> can often work around this) and their system's <b>gzexe</b> version is up-to-date.


title: HISTORY
content:
<b>gzexe</b> is an integral part of the <b>gzip</b> package, which was developed by Jean-Loup Gailly and Mark Adler. <b>gzip</b> was initially released in 1992 as a free and more efficient replacement for the proprietary <b>compress</b> utility, quickly becoming the standard for file compression on Unix-like systems. <b>gzexe</b> was created as a complementary utility to allow users to save disk space on executable binaries while maintaining transparent execution. Its usage has decreased over time due to increasing disk capacities and the emergence of more specialized executable compressors like <b>UPX</b>.


title: SYNOPSIS
content:
<b>gzip</b> [<i>OPTION</i>]... [<i>FILE</i>]...<br><b>gunzip</b> [<i>OPTION</i>]... [<i>FILE</i>]...<br><b>zcat</b> [<i>OPTION</i>]... [<i>FILE</i>]...


title: PARAMETERS
content:
<b><b>-c</b>, <b>--stdout</b>, <b>--to-stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write on standard output, keep original files unchanged. Useful for piping output.<br><br><b><b>-d</b>, <b>--decompress</b>, <b>--uncompress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress a compressed file. Equivalent to using the <i>gunzip</i> command.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force compression or decompression even if the file has multiple links, already exists, or has a different suffix.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the uncompressed file name, uncompressed size, compressed size, and compression ratio for each compressed file.<br><br><b><b>-n</b>, <b>--no-name</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not save or restore the original file name and time stamp when compressing/decompressing.<br><br><b><b>-N</b>, <b>--name</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always save or restore the original file name and time stamp. This is the default when decompressing.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warning messages.<br><br><b><b>-r</b>, <b>--recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Traverse the directory structure recursively. If a file is a directory, <i>gzip</i> will descend into it.<br><br><b><b>-S</b> <i>.suf</i>, <b>--suffix</b> <i>.suf</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>.suf</i> as the suffix for compressed files instead of <i>.gz</i>.<br><br><b><b>-t</b>, <b>--test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the integrity of a compressed file without decompressing it.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the name and percentage reduction for each file compressed or decompressed.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number and exit.<br><br><b><b>-<i>num</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the compression level, where <i>num</i> is a digit from 1 to 9. <b>-1</b> (or <b>--fast</b>) is the fastest compression (less compression), and <b>-9</b> (or <b>--best</b>) is the slowest but provides the best compression. The default is <b>-6</b>.<br><br>


title: DESCRIPTION
content:
<i>gzip</i> (GNU zip) is a popular command-line utility used for compressing and decompressing files. It employs the DEFLATE algorithm, a combination of LZ77 and Huffman coding, which is known for its good compression ratio and speed. By default, <i>gzip</i> replaces the original file with its compressed version, appending a <i>.gz</i> suffix (e.g., <i>filename.txt</i> becomes <i>filename.txt.gz</i>).<br><br>While <i>gzip</i> excels at compressing individual files, it does not archive directories or multiple files into a single archive; for that, it's commonly used in conjunction with archiving tools like <i>tar</i>. <i>gzip</i> is stream-oriented, meaning it can compress or decompress data piped to and from standard input/output, making it versatile for scripting and pipeline operations. Its widespread adoption makes it a de facto standard for single-file compression in Unix-like systems.


title: CAVEATS
content:
<i>gzip</i> is designed for single-file compression and does not preserve directory structures or combine multiple files into a single archive. For this purpose, it is typically used in conjunction with archiving tools like <i>tar</i>. By default, <i>gzip</i> replaces the original file with its compressed or decompressed version. It is generally not effective for files already compressed with other lossy or lossless algorithms (e.g., JPEG images, MP3 audio, or <i>zip</i> archives), as re-compressing them often yields little or no size reduction, and can sometimes even increase file size.


title: COMPRESSION LEVELS
content:
<i>gzip</i> offers various compression levels, controlled by the <b>-<i>num</i></b> option, where <i>num</i> ranges from 1 to 9. <b>-1</b> provides the fastest compression speed but results in a larger file size, while <b>-9</b> offers the best compression ratio but takes longer to process. The default compression level is <b>-6</b>, which strikes a good balance between speed and compression effectiveness. Users can choose a level based on their specific needs for speed versus disk space.


title: USAGE WITH <I>TAR</I>
content:
A very common pattern in Linux is to combine <i>gzip</i> with the <i>tar</i> command to create compressed archives of directories or multiple files. For example, <i>tar -czf archive.tar.gz directory/</i> first archives <i>directory/</i> into <i>archive.tar</i>, then compresses this <i>tar</i> archive using <i>gzip</i>, resulting in a single <i>.tar.gz</i> file. This is the standard way to package and distribute file collections while ensuring a smaller footprint.


title: HISTORY
content:
<i>gzip</i>, short for GNU zip, was created by Jean-loup Gailly and Mark Adler. It was first released in 1992 as part of the GNU project. Its primary motivation was to replace the proprietary <i>compress</i> program, which used the LZW algorithm that was subject to patent restrictions. <i>gzip</i>'s adoption of the patent-free DEFLATE algorithm (also used in the <i>PKZIP</i> file format) quickly made it the standard compression utility in the Unix/Linux world, ensuring free and unencumbered usage and distribution.


title: SEE ALSO
content:
gunzip(1), zcat(1), zless(1), zmore(1), compress(1), uncompress(1), zip(1), unzip(1), bzip2(1), bunzip2(1), xz(1), unxz(1), tar(1)


title: SYNOPSIS
content:
<B>h2ph</B> <I>[<B>-d</B> &lt;dir&gt;] [<B>-r</B>] [<B>-l</B>] [<B>-D</B>] [<B>-v</B>] [filenames...]</I>


title: PARAMETERS
content:
<b><B>-d</B> <I>&lt;dir&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output directory where the generated Perl header files will be placed. If not specified, it defaults to <B>$(installsitelib)/auto</B> (a Perl installation-specific directory).<br><br><b><B>-r</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables recursive processing of directories. If a directory is provided as input, <I>h2ph</I> will process all C header files found within that directory and its subdirectories.<br><br><b><B>-l</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used in conjunction with <B>-r</B>, this option instructs <I>h2ph</I> to follow symbolic links encountered during recursive directory traversal.<br><br><b><B>-D</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates debug mode. In this mode, <I>h2ph</I> will dump the raw output from the underlying C preprocessor (<I>cpp</I>) to standard output, which can be useful for troubleshooting parsing issues.<br><br><b><B>-v</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose mode, causing <I>h2ph</I> to display progress information and details about the files being processed during the conversion.<br><br>


title: DESCRIPTION
content:
<I>h2ph</I> is a utility designed to translate C header files (typically those with a <B>.h</B> extension) into corresponding Perl header files (with a <B>.ph</B> extension). Its primary function is to enable Perl scripts to access and utilize values from C preprocessor macros and <B>enum</B> declarations defined within C headers. The command attempts to parse these C constructs, often by leveraging the C preprocessor (<I>cpp</I>) to resolve macro values, and then generates equivalent Perl code. While it can process individual files, <I>h2ph</I> also supports recursive conversion of entire directory trees, making it suitable for processing standard system header directories like <B>/usr/include</B>. The resulting <B>.ph</B> files can then be <B>require</B>d by Perl scripts, providing a means to use C constants and definitions within Perl.


title: CAVEATS
content:
<I>h2ph</I> has several known limitations. It may not reliably parse all complex C preprocessor constructs, especially intricate macros or function-like macros, which can lead to incomplete or incorrect translations. Its functionality is heavily dependent on the correct operation and availability of the system's C preprocessor (<I>cpp</I>). Furthermore, the generated Perl header files may sometimes require manual inspection or cleanup to ensure proper functionality or adherence to modern Perl coding practices.<br><br>For contemporary Perl development and interfacing with C code, more robust and flexible utilities like <I>ExtUtils::ParseXS</I> or <I>Inline::C</I> are generally preferred, as <I>h2ph</I> represents an older approach primarily used for accessing system call constants via <B>require 'sys/syscall.ph'</B> type calls.


title: INPUT FILES AND DEFAULT BEHAVIOR
content:
If no specific <B>filenames</B> are provided on the command line, <I>h2ph</I> defaults to searching for C header files in standard system include paths. This typically involves directories like <B>/usr/include</B> and its subdirectories (or other system-specific locations defined by the build environment). It will then attempt to process these found files, generating corresponding Perl header files based on their content.


title: HISTORY
content:
<I>h2ph</I> is an older utility, primarily associated with earlier versions of Perl. Its initial purpose was to facilitate accessing system-specific constants (such as system call numbers or library constants) defined within C header files. This allowed Perl scripts to utilize these values through simple <B>require</B> statements, like <B>require 'sys/syscall.ph'</B>. While it served a crucial role in enabling early Perl-C integration, its design reflects a time before more sophisticated C interface tools, such as <I>ExtUtils::ParseXS</I> and <I>Inline::C</I>, became prevalent. As these newer, more robust methods for C interoperability in Perl have emerged, the direct usage of <I>h2ph</I> has diminished.


title: PARAMETERS
content:
<b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate auxiliary files like <i>Makefile.PL</i>, <i>README</i>, <i>test.pl</i>, etc. Only creates the <i>.xs</i> file.<br><br><b><b>-B</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not add a <i>BOOT:</i> section to the <i>.xs</i> file.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate a <i>CHANGES</i> file.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate POD documentation in the <i>.pm</i> file. (Same as <b>-P</b>).<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not create a <i>Makefile.PL</i> file.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not include <i>ExtUtils::MakeMaker</i> specific hints in <i>Makefile.PL</i>.<br><br><b><b>-M</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not include any <i>ExtUtils::MakeMaker</i> specific options or arguments in <i>Makefile.PL</i>.<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate POD documentation in the <i>.pm</i> file. (Same as <b>-D</b>).<br><br><b><b>-T</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate <i>test.pl</i> or <i>t/*.t</i> files.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information and exit.<br><br><b><b>-X</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not add <i>extern "C"</i> declaration in the generated <i>.xs</i> file.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add boilerplate for the <i>AUTOLOAD</i> subroutine.<br><br><b><b>-c</b> [<I>header_file</I> ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Take existing C header files to generate an <i>.xs</i> file. Overrides new module creation.<br><br><b><b>-d</b> <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create generated files in the specified <i>directory</i>.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force export of all symbols found in the header file(s).<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwrite of existing files without prompting.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep <i>Makefile.PL</i> around after <i>perl Makefile.PL</i> runs.<br><br><b><b>-l</b> <I>library</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>-l<I>library</I></i> to <i>LIBS</i> in <i>Makefile.PL</i>. Can be specified multiple times.<br><br><b><b>-m</b> <I>module</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the module name. Equivalent to <b>-n</b>.<br><br><b><b>-n</b> <I>module_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the module name for a new extension. Creates a new module structure.<br><br><b><b>-o</b> <I>output_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write <i>.xs</i> code to <i>output_file</i> instead of the default.<br><br><b><b>-p</b> <I>prefix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prefix all XS function names with <i>prefix_</i>.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip generating <i>sub</i> definitions for certain functions.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output during operation.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate code for handling C structures (<i>struct</i>s).<br><br>


title: DESCRIPTION
content:
<b>h2xs</b> is a powerful utility included with Perl that significantly automates the creation of a Perl extension module. It can generate a module skeleton either from a specified C header file or by simply providing a module name.<br>The tool populates a new directory with all the necessary boilerplate files for a Perl XS module, including <i>Makefile.PL</i> (configured for <i>ExtUtils::MakeMaker</i>), a <i>.pm</i> file, an <i>.xs</i> file, basic test scripts, and documentation templates.<br>This automation dramatically simplifies the often-complex process of wrapping existing C libraries or writing new C code to be called directly from Perl, enabling Perl developers to leverage high-performance C routines and interface seamlessly with system APIs or legacy codebases.


title: CAVEATS
content:
<b>h2xs</b> is a helpful starting point, but it does not parse C code perfectly; complex macros, pointers, and custom types often require significant manual adjustments to the generated <i>.xs</i> and <i>.pm</i> files.<br>It's designed primarily for C interfaces, and while it can handle <i>extern "C"</i>, direct C++ class wrapping is beyond its scope. Always review and refine the generated code.


title: TYPICAL WORKFLOW
content:
A common workflow involves running <i><b>h2xs</b> <b>-n</b> <I>My::Module</I></i> to create the module skeleton.<br>Then, manually edit <i>My/Module.xs</i> to add XS glue code, and <i>My/Module.pm</i> for Perl logic.<br>Finally, <i><b>perl</b> Makefile.PL</i>, <i><b>make</b></i>, <i><b>make</b> test</i>, and <i><b>make</b> install</i> are used to build and install the module.


title: HISTORY
content:
<b>h2xs</b> has been an integral part of the Perl distribution for a long time, evolving alongside the Perl XS mechanism and <i>ExtUtils::MakeMaker</i>.<br>Its core purpose has remained consistent: to facilitate the creation of Perl modules that interface with C code, simplifying the initial setup and reducing boilerplate for developers.<br>It is an essential tool for extending Perl's capabilities with high-performance C routines or leveraging existing C libraries.


title: SYNOPSIS
content:
<i>Not applicable.</i> The term 'hack' is not a standard executable command on Linux systems. Users looking for 'hacking' capabilities should identify and utilize specific security tools or programming utilities, rather than searching for a generic 'hack' command.


title: PARAMETERS
content:
<b><i>N/A</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;As 'hack' is not a standard Linux command, it does not have any defined parameters or options.<br><br>


title: DESCRIPTION
content:
The term 'hack' is <b>not a recognized or standalone Linux command</b>. It typically refers to the act of gaining unauthorized access to, or modifying, computer systems, or to creative and unconventional solutions to technical problems. In the context of the Linux operating system, 'hacking' often involves the use of a variety of specialized tools for network scanning (e.g., Nmap), vulnerability assessment (e.g., OpenVAS), or penetration testing (e.g., Metasploit Framework). These tools are distinct commands, not consolidated under a single 'hack' utility. Therefore, there is no generic <i>hack</i> command to invoke directly for system manipulation or security operations.


title: CAVEATS
content:
Attempting to execute `hack` in a standard Linux shell will result in a 'command not found' error, unless a user-defined alias, script, or a non-standard application named 'hack' has been specifically installed or created on the system.<br>It is crucial to understand that using tools for 'hacking' without proper authorization is <b>illegal and unethical</b>.


title: UNDERSTANDING 'HACKING' ON LINUX
content:
When people refer to 'hacking' on Linux, they usually mean utilizing a collection of specialized <B>security tools</B> and utilities that come with or can be installed on Linux distributions (especially those geared towards security, like Kali Linux or Parrot OS). These tools are used for tasks such as network reconnaissance, vulnerability scanning, exploit development, and post-exploitation. It's crucial to understand the ethical implications and legality of using such tools, as well as the distinction between ethical hacking (penetration testing with permission) and malicious activities.


title: HISTORY
content:
<i>Not applicable.</i> As 'hack' is not a standard Linux command, it does not have a development or usage history within the official Linux command-line utilities. The term 'hack' itself has a rich history in computing, evolving from its initial connotation of clever problem-solving to its more modern, often negative, implications related to unauthorized access and cybercrime.


title: SYNOPSIS
content:
<b>hadolint</b> [<i>OPTIONS</i>] <i>&lt;FILE | -&gt;</i><br><b>hadolint</b> [<i>OPTIONS</i>] <i>--version</i><br><b>hadolint</b> [<i>OPTIONS</i>] <i>--help</i>


title: PARAMETERS
content:
<b>-f, --format &lt;FORMAT&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the output format (tty, json, checkstyle, codeclimate, github_actions).</i><br><br><b>-s, --strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Treat warnings as errors, causing <i>hadolint</i> to exit with an error code.</i><br><br><b>-c, --config &lt;FILE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Path to a custom configuration file for rules and settings.</i><br><br><b>-i, --ignore &lt;CODE,...&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Comma-separated list of rules to ignore (e.g., DL3006,SC2039).</i><br><br><b>--override &lt;RULE=SEVERITY,...&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override severity of specific rules (e.g., 'DL3000=error', 'SC2000=info').</i><br><br><b>--no-fail</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not exit with a non-zero exit code on linting failures; always exit with 0.</i><br><br><b>--disable-security</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disable all security-related rules (rules starting with DL30xx).</i><br><br><b>--target-arch &lt;ARCH&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify target architecture for rules that depend on it (e.g., 'amd64', 'arm64').</i><br><br><b>--disable-warnings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disable all warning messages from being displayed.</i><br><br><b>--error-exit-code &lt;CODE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the exit code for errors (default: 1).</i><br><br><b>--failure-threshold &lt;LEVEL&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Exit with non-zero if any issue of severity &lt;LEVEL&gt; or higher is found (info, warning, error).</i><br><br><b>--rule-url &lt;URL&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>URL to download custom rules from, allowing for dynamic rule sets.</i><br><br><b>--color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force color output, even if the terminal doesn't support it.</i><br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disable color output in the console.</i><br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show the version number of <i>hadolint</i>.</i><br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show the help message and exit.</i><br><br>


title: DESCRIPTION
content:
<i>hadolint</i> is a powerful static analysis tool for Dockerfiles, designed to enforce best practices and identify common issues. Written in Haskell, it parses Dockerfiles and checks them against a comprehensive set of rules derived from Docker's official documentation, community best practices, and security considerations.<br><br>By integrating <i>hadolint</i> into development workflows, users can significantly improve the security, efficiency, and maintainability of their container images, catch errors early in the development cycle, and ensure compliance with organizational standards. It's a valuable tool for anyone working with Docker, from individual developers to large CI/CD pipelines, helping to build robust and reliable containerized applications.


title: CAVEATS
content:
<i>hadolint</i> performs static analysis, meaning it checks the Dockerfile's syntax and adherence to rules without executing any commands or building the image. Therefore, it cannot detect runtime issues, errors that occur during the actual container build process, or logical flaws within the application itself.<br><br>While comprehensive, its rules are based on common best practices, and specific project requirements might necessitate ignoring certain rules or developing custom ones. It should be used as one part of a comprehensive quality assurance and security strategy, not as a standalone solution for all container image vulnerabilities.


title: RULE CUSTOMIZATION
content:
<i>hadolint</i> offers extensive customization options to tailor its behavior to specific project needs. Users can ignore specific rules using the <i>--ignore</i> flag or a configuration file. The severity of existing rules can be overridden, changing them from warnings to errors or vice-versa. Furthermore, entirely new custom rules can be defined and loaded from local files or remote URLs, allowing organizations to enforce their specific compliance and best practice requirements effectively.


title: CI/CD INTEGRATION
content:
Due to its command-line interface and support for various machine-readable output formats (including CheckStyle and Code Climate), <i>hadolint</i> is exceptionally well-suited for integration into Continuous Integration/Continuous Delivery (CI/CD) pipelines. It can be run as a pre-commit hook to catch issues early, or as part of a build step within a CI/CD job. This provides immediate feedback on Dockerfile quality and security, preventing problematic images from being built or deployed and helping to automate adherence to coding standards.


title: HISTORY
content:
<i>hadolint</i> was created to address the growing need for automated Dockerfile validation in the rapidly expanding DevOps landscape. It emerged as an open-source project written in Haskell, leveraging the language's strong type system and parsing capabilities for robust analysis. Its development has been community-driven, continually expanding its rule set and improving its performance and feature set. Adopted widely by organizations and individual developers, it has become a de-facto standard for linting Dockerfiles, integrating seamlessly into CI/CD pipelines to enforce quality and security standards from the earliest stages of container image development.


title: PARAMETERS
content:
<b><I>DIRECTORY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional path specifying the directory where the new Hakyll project will be initialized. If omitted, the command defaults to creating the project files within the current working directory.<br><br>


title: DESCRIPTION
content:
<I>hakyll-init</I> is a command-line utility provided by the <b>Hakyll</b> static site generator, a powerful and flexible tool built in Haskell. Its primary function is to quickly scaffold and initialize a new Hakyll project from scratch. When executed, it creates a standard, well-organized directory structure and essential boilerplate files. This includes the main <I>site.hs</I> configuration file, designated directories for content like posts and pages, and dedicated folders for templates, CSS, images, and other static assets. This command significantly streamlines the initial setup process, allowing developers to immediately start focusing on content creation and site customization rather than laborious manual project configuration. It establishes a foundational, yet fully functional, static site ready for development and deployment, following Hakyll's conventions.


title: CAVEATS
content:
To use <I>hakyll-init</I>, you must have the Haskell toolchain installed, typically either <b><I>Stack</I></b> or <b><I>Cabal</I></b>. Additionally, the <b><I>Hakyll</I></b> library itself must be accessible within your Haskell environment. The initialized project provides a basic template that often requires significant customization to match specific site requirements and design aesthetics.


title: <B>PROJECT STRUCTURE</B>
content:
Upon execution, <b><I>hakyll-init</I></b> typically creates a project with the following core directories and files:<br><ul><li><I>site.hs</I>: The main Haskell configuration file for the site.</li><li><I>posts/</I>: Directory for blog posts or articles.</li><li><I>pages/</I>: Directory for static pages.</li><li><I>templates/</I>: Contains HTML templates for pages, posts, and general layouts.</li><li><I>css/</I>: For stylesheets.</li><li><I>images/</I>: For images and other static assets.</li></ul>


title: <B>BUILDING AND DEVELOPMENT</B>
content:
After initializing a project with <b><I>hakyll-init</I></b>, you typically use <b><I>Stack</I></b> or <b><I>Cabal</I></b> to build and run the site. Common commands include:<br><ul><li><code>stack build</code> or <code>cabal build</code>: To compile the Hakyll executable.</li><li><code>stack exec site rebuild</code> or <code>cabal run site rebuild</code>: To generate the static site files (usually in a <code>_site/</code> directory).</li><li><code>stack exec site watch</code> or <code>cabal run site watch</code>: To run a local development server with live reloading, which automatically rebuilds the site when files change.</li></ul>


title: HISTORY
content:
<b><I>Hakyll</I></b> was created by <b><I>Jasper Van der Jeugt</I></b> as a static site generator written in <b><I>Haskell</I></b>. The <b><I>hakyll-init</I></b> command has been an integral part of the <b><I>Hakyll</I></b> distribution since its early stages, evolving alongside the main project to provide up-to-date project templates and reflect best practices in static site generation with <b><I>Hakyll</I></b>. It simplifies the initial setup, reflecting a common need for boilerplate generation in development tools.


title: PARAMETERS
content:
<b><b>-p</b>, <b>--poweroff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Halts the system and then powers it off. This is often the default behavior on modern systems, making the <b>poweroff</b> command synonymous with <b>halt -p</b>.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force halt, bypassing some normal shutdown procedures. This does not call the <b>reboot(2)</b> system call. Use with caution as it may prevent proper unmounting of file systems.<br><br><b><b>-w</b>, <b>--wtmp-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not actually halt the system, but only writes the <i>wtmp</i> record, indicating a system shutdown event. Useful for logging without an actual halt.<br><br><b><b>-d</b>, <b>--no-wtmp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not write the <i>wtmp</i> record. This suppresses the logging of the halt event.<br><br><b><b>-n</b>, <b>--no-sync</b>, <b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not sync disks before halting. This is extremely dangerous and can lead to severe data loss or file system corruption if used without proper understanding of disk buffer flushing.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit, showing common usage and available options.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information of the <b>halt</b> utility and exit.<br><br>


title: DESCRIPTION
content:
The <b>halt</b> command is used to shut down or halt the operating system. Historically, it would stop the system without necessarily cutting power, requiring a manual power-off. On modern Linux distributions, especially those using <i>systemd</i>, <b>halt</b> is often a symlink to <b>systemctl</b> or a wrapper around it, behaving identically to <b>poweroff</b>. When executed, it sends signals to processes, unmounts filesystems, and eventually brings the system to a state where the CPU stops execution. Depending on the hardware and kernel support, this state may or may not include automatic power termination. For a complete power down, the <b>--poweroff</b> option or the <b>poweroff</b> command itself is typically used, though often redundant on contemporary systems.


title: CAVEATS
content:
On many modern Linux distributions that utilize <i>systemd</i>, the <b>halt</b> command is often a symbolic link or a wrapper that simply invokes <b>systemctl poweroff</b>. This means its traditional distinction from <b>poweroff</b> (where <b>halt</b> might leave the machine powered on in a stopped state) is largely obsolete, and it will typically perform a full system power-off. For explicit and future-proof system control, using <b>systemctl poweroff</b> directly is generally recommended. Additionally, using options like <b>--no-sync</b> can bypass critical disk synchronization steps, leading to unrecoverable data loss or filesystem corruption if the system is not already quiescent.


title: SECURITY AND PERMISSIONS
content:
Executing <b>halt</b> typically requires root privileges (superuser access) to prevent unauthorized system shutdowns by regular users. This is a critical security measure to maintain system availability and integrity. If a non-root user attempts to execute <b>halt</b>, they will usually receive a 'permission denied' error.


title: RECOMMENDED MODERN USAGE
content:
While <b>halt</b> remains available for backward compatibility and convenience, the contemporary and preferred method for initiating a system shutdown on <i>systemd</i>-based systems is to use <b>systemctl poweroff</b>. This command offers more granular control and is part of the standardized <i>systemd</i> service management framework, which handles dependencies and service termination more robustly during shutdown.


title: HISTORY
content:
The <b>halt</b> command has been a fundamental utility in Unix-like operating systems since their early days, providing a basic mechanism to stop system execution. Historically, its primary function was to bring the system to a 'halted' state where the CPU would stop, but the power supply might remain active, requiring a manual power off. The <b>poweroff</b> command later emerged to specifically handle automatic power termination. With the widespread adoption of <i>systemd</i> as the init system in major Linux distributions (like Fedora, RHEL, Ubuntu, Debian), the distinct behaviors of <b>halt</b>, <b>poweroff</b>, and <b>reboot</b> have largely converged. They are now often implemented as front-ends or symbolic links to <b>systemctl poweroff</b>, <b>systemctl reboot</b>, etc., ensuring a consistent and integrated shutdown process managed by <i>systemd</i>.


title: SYNOPSIS
content:
<b>handlr</b> [<i>GLOBAL_OPTIONS</i>] <i>SUBCOMMAND</i> [<i>SUBCOMMAND_OPTIONS</i>] [<i>ARGUMENTS</i>]<br><br><b>handlr open</b> [<b>-ps</b>] <<i>PATH|URL</i>><br><b>handlr set</b> <<i>MIMETYPE|SCHEME</i>> <<i>APP_ID</i>><br><b>handlr get</b> <<i>MIMETYPE|SCHEME</i>><br><b>handlr list</b> [<<i>MIMETYPE|SCHEME</i>>]<br><b>handlr launch</b> <<i>APP_ID</i>><br><b>handlr install</b> <<i>APP_ID</i>><br><b>handlr uninstall</b> <<i>APP_ID</i>><br><b>handlr select</b> <<i>MIMETYPE|SCHEME</i>><br><br><b>handlr</b> [<b>-h</b>|<b>--help</b>|<b>-V</b>|<b>--version</b>|<b>--list-schemes</b>|<b>--list-mime-types</b>]


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the command or a subcommand and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information for handlr and exits.<br><br><b><b>--list-schemes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all registered URL schemes (e.g., <i>http</i>, <i>mailto</i>).<br><br><b><b>--list-mime-types</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all registered MIME types (e.g., <i>text/plain</i>, <i>image/jpeg</i>).<br><br><b><b>open</b> <<i>PATH|URL</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a file or URL with its currently configured default handler.<br><i>Options:</i><br><b>-p</b>, <b>--prompt</b>: Prompts the user to select an application if multiple handlers are available.<br><b>-s</b>, <b>--stream</b>: Streams the content of a file to stdout (only for certain MIME types, like text).<br><br><b><b>set</b> <<i>MIMETYPE|SCHEME</i>> <<i>APP_ID</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default application for a specified MIME type or URL scheme. <i>APP_ID</i> is typically the desktop entry filename (e.g., <i>firefox.desktop</i>).<br><br><b><b>get</b> <<i>MIMETYPE|SCHEME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves and prints the currently set default application for a given MIME type or URL scheme.<br><br><b><b>list</b> [<<i>MIMETYPE|SCHEME</i>>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all applications associated with a specific MIME type or scheme. If no argument is provided, it lists all registered associations.<br><br><b><b>launch</b> <<i>APP_ID</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches a specific application directly by its desktop entry ID, without opening a file or URL.<br><br><b><b>install</b> <<i>APP_ID</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a <i>.desktop</i> file (application launcher) into the user's local applications directory (<i>~/.local/share/applications/</i>), making it discoverable by handlr and the desktop environment.<br><br><b><b>uninstall</b> <<i>APP_ID</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstalls a <i>.desktop</i> file previously installed by <b>handlr install</b> or manually placed in the user's local applications directory.<br><br><b><b>select</b> <<i>MIMETYPE|SCHEME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively presents a list of available applications and allows the user to select and set the default handler for a given MIME type or URL scheme.<br><br>


title: DESCRIPTION
content:
handlr is a command-line tool designed to streamline the management of default applications for file types (MIME types) and URL schemes on Linux. It offers a more intuitive and powerful alternative to traditional utilities like <b>xdg-open</b> and <b>xdg-mime</b>, which can sometimes be less user-friendly or consistent.<br><br>Written in Rust, handlr aims to provide a reliable and fast way to configure and use application handlers. It interacts directly with the freedesktop.org specifications, particularly the <b>mimeapps.list</b> standard, and desktop entry files (<b>.desktop</b>). Users can easily open files or URLs with their preferred applications, set new defaults, retrieve current handlers, list all known associations, and even launch specific applications or manage their desktop entries directly from the command line. Its focus on simplicity and adherence to modern Linux desktop standards makes it a valuable tool for both power users and those seeking a more consistent desktop experience.


title: CAVEATS
content:
handlr relies on the freedesktop.org desktop entry and MIME type specifications. Its functionality is most robust in desktop environments that adhere to these standards and have a proper <b>xdg-desktop-portal</b> or similar infrastructure. In minimal or non-standard environments, some features, particularly <b>open</b> and <b>launch</b>, might not behave as expected or might require manual configuration of <b>XDG_DATA_HOME</b> and <b>XDG_CONFIG_HOME</b> paths.<br>While handlr aims for consistency, discrepancies can still arise if system-wide and user-specific <b>mimeapps.list</b> files or desktop entry caches are inconsistent or corrupted.


title: CONFIGURATION FILES
content:
handlr primarily interacts with <i>~/.config/mimeapps.list</i> for user-specific default associations and <i>~/.local/share/applications/</i> (and system-wide equivalents like <i>/usr/share/applications/</i>) for desktop entry files (<i>.desktop</i>). These files are central to how handlr discovers and manages applications.


title: USAGE EXAMPLES
content:
<ul><li>Set default browser: <b>handlr set http firefox.desktop</b></li><li>Open a file: <b>handlr open document.pdf</b></li><li>Get current handler for text files: <b>handlr get text/plain</b></li><li>List all available PDF viewers: <b>handlr list application/pdf</b></li><li>Interactively select image viewer: <b>handlr select image/jpeg</b></li></ul>


title: HISTORY
content:
handlr is a relatively new project, developed in Rust, addressing common frustrations with existing <b>xdg-utils</b> related to default application management. Its development was driven by a desire for a more modern, efficient, and user-friendly command-line interface for handling MIME types and URL schemes. It has gained popularity in the Linux community for its focus on simplicity and adherence to contemporary desktop standards, providing a more reliable and consistent experience compared to older shell-script based utilities.


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the entire dictionary of words that <i>hangman</i> uses. This option can be used to 'cheat' or to explore the word list.<br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an 'old' output style, which may feature simpler or less graphical representations of the gallows and other game elements, suitable for older terminals or specific preferences.<br><br><b><b>-w</b> <i>wordlist</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <i>wordlist</i> file to use as the dictionary for words to guess. If this option is not provided, <i>hangman</i> typically uses its default internal or system-wide word file.<br><br>


title: DESCRIPTION
content:
<i>hangman</i> is a text-based adaptation of the classic word-guessing game. The computer selects a random word from its dictionary, and the player attempts to guess the word by suggesting letters. For each incorrect guess, a part of a 'hanged man' drawing is added. The goal is to guess the word before the drawing is complete, thereby 'saving' the man.<br><br>The game typically provides feedback on correct and incorrect guesses, showing the progress of the word being revealed and the state of the gallows. It's a simple yet engaging game designed for the command line, often included as part of traditional Unix/Linux games packages.


title: CAVEATS
content:
The <i>hangman</i> command is typically part of the <i>bsdgames</i> package and may not be installed by default on all Linux distributions. Users might need to install it manually (e.g., <code>sudo apt-get install bsdgames</code> on Debian/Ubuntu or <code>sudo yum install bsdgames</code> on Fedora/CentOS).


title: FILES
content:
<i>/usr/share/games/bsdgames/hangman.words</i><br>The default dictionary file used by <i>hangman</i>. The exact path may vary depending on the system and distribution.


title: AUTHORS
content:
The exact authorship details for <i>hangman</i> can be difficult to pinpoint precisely due to its long history and evolution within the BSD games collection. However, it is generally considered part of the collaborative efforts of the original BSD developers and subsequent contributors.


title: BUGS
content:
Given its age and simplicity, <i>hangman</i> is relatively stable. Any potential bugs would likely be minor, such as issues with word parsing in custom word lists or very specific terminal rendering quirks, rather than critical functionality failures. Refer to your system's documentation or bug tracking for specific distribution-related issues.


title: HISTORY
content:
<i>hangman</i> is a venerable component of the collection of classic Unix games, often found within the <i>bsdgames</i> suite. Its origins trace back to early Unix systems, providing simple entertainment in the command-line environment. Like many such games, it reflects the simplicity and directness of early computing interfaces, focusing on core gameplay mechanics without graphical overhead. It has been maintained and ported across various Unix-like operating systems for decades.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit, displaying available options and usage.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug logging, providing more verbose output for troubleshooting.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the program's version number and exit.<br><br><b>--log <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file path to which all log messages will be written.<br><br><b>--json-output</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output Hangouts messages in JSON format, useful for programmatic parsing.<br><br><b>--token-path <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the path to the refresh token file used for authentication with Google.<br><br><b>--config-path <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the configuration file used by hangups.<br><br>


title: DESCRIPTION
content:
The <I>hangups</I> command is a non-standard, open-source Python application and library designed to interact with Google Hangouts. It provides a command-line interface (CLI) for users to chat and manage conversations directly from their Linux terminal. Beyond its CLI capabilities, <I>hangups</I> also serves as a robust Python library, allowing developers to build custom bots, scripts, and integrations that leverage Google Hangouts functionality programmatically. It gained significant popularity after Google deprecated its XMPP gateway, providing a much-needed alternative for automated and terminal-based Hangouts access.


title: CAVEATS
content:
It is crucial to note that <I>hangups</I> is not a standard Linux command bundled with most distributions. It is a third-party Python application that needs to be installed separately, typically via <I>pip</I>. Its functionality relies entirely on Google's Hangouts API, meaning changes to this API by Google could potentially break or alter <I>hangups</I>' behavior. Users must ensure they have Python and <I>pip</I> installed to use it.


title: INSTALLATION
content:
To install <I>hangups</I>, ensure you have Python 3 and <I>pip</I> installed on your system. Then, you can install it using the following command:<br><br><B>pip install hangups</B>


title: USAGE EXAMPLE
content:
After installation, simply running <B>hangups</B> in your terminal will initiate the interactive command-line client. The first time, it will guide you through the authentication process with your Google account. Subsequent runs will directly connect and display your Hangouts conversations.


title: HISTORY
content:
Developed by a community of open-source contributors, <I>hangups</I> emerged as a response to Google's decision to shut down the XMPP gateway for Google Talk/Hangouts, which many third-party clients and bots relied upon. Its development aimed to provide a stable and open-source alternative for accessing Hangouts functionality via the Google Hangouts API, ensuring continued programmatic and terminal-based access to the platform.


title: PARAMETERS
content:
<b><b>-b</b>, <b>--bin</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the hardening status of a specific binary or a list of binaries. This is the default behavior if arguments are provided as files.<br><br><b><b>-p</b>, <b>--pie-libs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Also checks <b>PIE</b> (Position-Independent Executable) support for shared libraries.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output for checks that pass, only showing failures or warnings.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows more detailed output for each check, including successful ones.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks all executables currently running on the system.<br><br><b><b>-s</b>, <b>--status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the general system hardening status, including kernel parameters (e.g., ASLR effectiveness, kernel module loading restrictions).<br><br><b><b>-r</b>, <b>--run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks hardening for running processes. This option implies <b>--all</b>.<br><br><b><b>-k</b>, <b>--kernel-modules</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the hardening status of loaded kernel modules.<br><br><b><b>-c</b>, <b>--config-files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the hardening status of important system configuration files.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, providing more information for troubleshooting.<br><br><b><b>-x</b>, <b>--xml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the results in XML format.<br><br><b><b>-j</b>, <b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the results in JSON format.<br><br><b><b>-t</b>, <b>--text</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the results in human-readable text format (default).<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information and exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<i>hardening-check</i> is a utility designed to audit the security hardening status of a Linux system, focusing on both the system-wide configuration and individual executables. It verifies the presence of various exploit mitigation technologies such as <b>Address Space Layout Randomization (ASLR)</b>, <b>Non-Executable (NX)</b> stack/heap, <b>Position-Independent Executables (PIE)</b>, <b>Fortify Source</b>, and <b>Stack Smashing Protector (SSP)</b>.<br><br>Beyond executables, it can assess kernel parameters related to security, loaded kernel modules, important configuration files, and running processes to identify potential weaknesses. Its primary goal is to help administrators identify areas where system security can be improved by ensuring that compiled binaries utilize modern security features and that the system configuration aligns with security best practices. It supports various output formats, including text, XML, and JSON, making it suitable for automated security auditing.


title: CAVEATS
content:
<i>hardening-check</i> relies on information gathered from the system (e.g., <i>/proc</i> filesystem, <i>readelf</i> output). While comprehensive, it cannot guarantee absolute security and should be used as one component of a broader security auditing strategy. False positives or negatives might occur depending on specific system configurations or custom compilation flags. It primarily focuses on compile-time and kernel-level hardening features, not application-level vulnerabilities or network security.


title: INTERPRETATION OF RESULTS
content:
The output typically indicates <b>YES</b> for enabled features, <b>NO</b> for disabled features, and <b>N/A</b> for checks not applicable to a specific binary or system.<br>For executables, it checks properties like <i>No EXECUTE</i>, <i>Position Independent Executable (PIE)</i>, <i>Stack Smashing Protector</i>, <i>Fortify Source</i>, and <i>Read-Only GOT</i>.


title: INTEGRATION
content:
<i>hardening-check</i> can be easily integrated into CI/CD pipelines or automated security scanning tools due to its support for machine-readable output formats (XML, JSON).


title: HISTORY
content:
<i>hardening-check</i> is part of the <i>hardening-wrapper</i> package, primarily maintained within the Debian/Ubuntu ecosystem. It was developed to help users and package maintainers ensure that software packages and the underlying system adhere to modern security best practices regarding exploit mitigation. Its evolution has been driven by new compiler features (like PIE by default, ASLR improvements) and kernel security enhancements.


title: SYNOPSIS
content:
<i>npx hardhat <I>[command]</I> <I>[args]</I> <I>[options]</I></i><br><i>yarn hardhat <I>[command]</I> <I>[args]</I> <I>[options]</I></i><br><i>The `npx` or `yarn` prefix is crucial as Hardhat is a Node.js package, not a system-level executable.</i>


title: PARAMETERS
content:
<b><i>compile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Compiles all Solidity contracts found in the project.</i><br><br><b><i>test</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Executes all tests written for the smart contracts, typically using JavaScript/TypeScript.</i><br><br><b><i>run &lt;script-path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Runs a specified JavaScript or TypeScript script within the Hardhat environment, useful for deployment or custom tasks.</i><br><br><b><i>node</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Starts a local Hardhat Network instance, an in-memory Ethereum network ideal for fast development and testing.</i><br><br><b><i>clean</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Deletes the cache and artifacts directories to ensure a clean build.</i><br><br><b><i>help [command]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays comprehensive help information for Hardhat itself or a specific command/task.</i><br><br><b><i>--network &lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the Ethereum network to connect to (e.g., `localhost`, `sepolia`, `mainnet`), as defined in the Hardhat configuration.</i><br><br><b><i>--config &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Provides an explicit path to the Hardhat configuration file (`hardhat.config.js` or `hardhat.config.ts`).</i><br><br>


title: DESCRIPTION
content:
<i>Hardhat is not a standard, native Linux command. Instead, it is a popular, open-source development environment designed for compiling, deploying, testing, and debugging decentralized applications (dApps) and smart contracts on the Ethereum blockchain. It's primarily a JavaScript/TypeScript project, typically installed via `npm` or `yarn`, and executed using `npx hardhat` or `yarn hardhat` within a project directory. Hardhat provides a robust local Ethereum network (Hardhat Network) for rapid development, a flexible plugin system for extending functionality, and seamless integration with JavaScript and TypeScript testing frameworks. It simplifies the entire smart contract development lifecycle, from writing Solidity code to deploying on mainnet.</i>


title: CAVEATS
content:
<i>Hardhat is not a native Linux command-line utility. It relies on Node.js and a package manager (`npm` or `yarn`) being installed on the system. Its primary application is in blockchain development for Ethereum and EVM-compatible networks, and it's not part of the standard Linux toolset. Commands are almost always prefixed with `npx` or `yarn` to execute the locally installed Hardhat CLI.</i>


title: INSTALLATION
content:
<i>Hardhat is typically installed locally within a project using npm: `npm install --save-dev hardhat`. A new project can be initialized by navigating into an empty directory and running `npx hardhat` to set up basic project files. Global installation (`npm install -g hardhat`) is also possible but less common for project-specific development.</i>


title: CONFIGURATION
content:
<i>Every Hardhat project includes a `hardhat.config.js` (or `.ts`) file. This central configuration file defines networks, Solidity compiler versions, paths to contracts and tests, and enables various plugins. It's essential for tailoring Hardhat's behavior to specific project requirements.</i>


title: HISTORY
content:
<i>Hardhat was developed by Nomic Labs and officially launched in 2020. It rapidly gained prominence in the Ethereum development community as a modern, robust, and developer-centric alternative to existing tools. Its key innovations, such as the built-in Hardhat Network with console.log functionality for smart contracts and an extensible plugin architecture, significantly improved the development experience for Solidity smart contracts and dApps.</i>


title: SYNOPSIS
content:
<b>hardinfo</b> [<i>options</i>]<br><b>hardinfo</b> <b>-r</b> [<b>-f</b> <i>&lt;format&gt;</i>] [<i>filename</i>]<br><b>hardinfo</b> <b>--help</b><br><b>hardinfo</b> <b>--version</b><br><b>hardinfo</b> <b>--about</b>


title: PARAMETERS
content:
<b><b>--report</b>, <b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a system report without launching the GUI. This option is typically used for automated reporting.<br><br><b><b>--format</b> <i>&lt;format&gt;</i>, <b>-f</b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for the generated report. Supported formats include <i>html</i>, <i>text</i>, <i>json</i>, and <i>xml</i>. This option requires the <b>-r</b> or <b>--report</b> flag.<br><br><b><b>--no-gui</b>, <b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the graphical user interface from starting. This is useful when generating reports from the command line, ensuring the command exits after report generation.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with available command-line options and exits.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of <i>hardinfo</i> and exits.<br><br><b><b>--about</b>, <b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the "About" dialog box for <i>hardinfo</i> and exits.<br><br>


title: DESCRIPTION
content:
<i>hardinfo</i> is a comprehensive system information and benchmarking tool for Linux and FreeBSD. It provides detailed insights into a system's hardware components (CPU, memory, storage, network, display) and software environment (operating system, kernel, running processes). <i>hardinfo</i> offers both a user-friendly graphical interface for interactive exploration and a command-line interface for generating various types of system reports (HTML, plain text, JSON, XML). Its benchmarking capabilities allow users to compare their system's performance against reference data, making it valuable for troubleshooting, upgrading, or simply understanding a system's configuration.


title: CAVEATS
content:
<i>hardinfo</i> might require elevated privileges (e.g., <b>sudo</b>) to access some hardware information, especially for detailed sensor readings or certain kernel modules. Its benchmarks are basic and may not reflect real-world performance accurately for complex workloads. The GUI might not be available in headless environments.


title: GUI USAGE
content:
When run without any arguments, <i>hardinfo</i> launches its graphical user interface. This GUI provides an organized tree-view of system components, allowing users to browse various hardware and software categories interactively, and also execute benchmarks.


title: REPORT GENERATION
content:
The primary command-line utility of <i>hardinfo</i> is its ability to generate detailed system reports. These reports can be saved in various formats (HTML, text, JSON, XML), making it easy to share system configurations or archive them for later reference.


title: HISTORY
content:
<i>hardinfo</i> has been a popular tool for system information on Linux for many years. Initially developed by Louis Bouchard, it gained recognition for its user-friendly graphical interface and comprehensive reporting capabilities. Its consistent presence in various Linux distributions highlights its utility as a go-to utility for users needing to quickly assess system hardware and software details without deep command-line expertise.


title: SYNOPSIS
content:
<b>hash</b> [<i>-r</i>] [<i>-d</i> <i>name</i>] [<i>-t</i> <i>name</i> ...] [<i>-l</i>] [<i>name</i> ...]


title: PARAMETERS
content:
<b><i>(no options)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the contents of the shell's hash table, showing hit counts and full paths of remembered commands.<br><br><b><i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Locates the command <i>name</i> in the <b>PATH</b> and adds its full path to the hash table. If <i>name</i> is already hashed, its entry is updated.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>r</b>emove</i>: Clears all entries from the shell's hash table, forcing the shell to re-search the <b>PATH</b> for subsequent command invocations.<br><br><b><b>-d</b> <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>d</b>elete</i>: Removes the entry for <i>name</i> from the hash table. If <i>name</i> is not found in the table, no action is taken.<br><br><b><b>-t</b> <i>name</i> [<i>name</i> ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>t</b>ell</i>: Displays the full path to <i>name</i> (or multiple <i>names</i>). If a command is not found in the hash table or the <b>PATH</b>, an error message is printed and the command exits with a non-zero status.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>l</b>ist</i>: Displays the contents of the hash table in a format that can be re-input as commands (e.g., <code>hash -t /bin/ls</code>). This option is often combined with other options or used for scripting.<br><br>


title: DESCRIPTION
content:
<b>hash</b> is a fundamental shell built-in command designed to optimize the execution speed of frequently used commands. When you type a command, the shell typically searches through directories listed in your <b>PATH</b> environment variable to locate the executable. This search can introduce overhead, especially with a long <b>PATH</b>.<br><br><b>hash</b> mitigates this by maintaining an internal hash table. Once a command's location is found during the initial execution, its full path is stored in this table. Subsequent calls to the same command can then retrieve its path directly from the hash table, bypassing the potentially time-consuming <b>PATH</b> search. This significantly speeds up command invocation.<br><br>Beyond caching, <b>hash</b> also allows users to inspect the current hash table, add new entries, or remove specific commands or the entire cache, providing control over this performance optimization mechanism.


title: CAVEATS
content:
<b>hash</b> is a shell built-in command, meaning it is part of the shell itself (e.g., Bash, Zsh) and not an external executable file. Its behavior and available options can vary slightly between different shells. The hash table only stores paths for commands found within the user's <b>PATH</b> environment variable.<br><br>If an executable's location changes after it has been hashed, the cached path will become stale, leading to errors until the entry is removed (using <b>hash -d</b> or <b>hash -r</b>) or the shell is restarted.


title: EXIT STATUS
content:
The <b>hash</b> command returns an exit status of 0 (success) unless an invalid option is provided, or if the <b>-t</b> option is used and the specified command <i>name</i> is not found either in the hash table or in the <b>PATH</b>.


title: PERFORMANCE IMPACT
content:
While <b>hash</b> significantly speeds up subsequent executions of commands, the initial lookup still involves a <b>PATH</b> search. For commands executed only once or very rarely, the performance gain is negligible. Its primary benefit is for frequently used commands in busy shell sessions.


title: HISTORY
content:
The concept of command hashing for performance optimization has been a fundamental feature of Unix-like shells for decades. It's not a standalone utility but rather an integral part of shells like Bash, Zsh, and others, designed to improve the interactive user experience by reducing command lookup times. Its core functionality has remained consistent over time.


title: PARAMETERS
content:
<b>-m <hash_type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the hash type ID. Hashcat supports thousands of different hash types, each with a unique numeric ID.<br><br><b>-a <attack_mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the attack mode to be used. Common modes include 0 (dictionary), 1 (combinator), 3 (brute-force/mask), 6 (hybrid wordlist + mask), and 7 (hybrid mask + wordlist).<br><br><b>-o <outfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes cracked passwords and corresponding hashes to the specified output file.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the use of unsupported devices, drivers, or specific situations that Hashcat might otherwise prevent.<br><br><b>-D <device_type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the device type to use for cracking. 1 for CPU, 2 for GPU, 3 for OpenCL, 4 for CUDA, etc.<br><br><b>--show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows cracked hashes and their corresponding plaintexts from the hashcat.potfile.<br><br><b>--status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the cracking status regularly, showing progress, speed, and estimated time to completion.<br><br><b>-r <rule_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies rules from a specified rule file to words from a dictionary (e.g., to add numbers, symbols, or common transformations).<br><br><b>-i --increment</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables increment mode for brute-force or mask attacks, which intelligently increases the length of the password being tried.<br><br><b>-1, -2, -3, -4 <charset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines custom character sets for mask attacks. For example, '-1 ?l?d' defines set 1 as lowercase letters and digits.<br><br>


title: DESCRIPTION
content:
<i>Hashcat is a highly advanced, GPU-accelerated password recovery utility known for its versatility and speed. It supports an extensive array of hashing algorithms, from common formats like MD5 and SHA1 to more complex ones such as NTLM, WPA/WPA2, and various database hashes. Designed for both auditing and security testing, Hashcat offers numerous attack modes including dictionary attacks, brute-force, combinator, hybrid, mask attacks, and rule-based transformations. Its ability to leverage the computational power of modern GPUs (via OpenCL and CUDA) makes it exceptionally efficient for cracking large sets of hashes. Hashcat is a crucial tool for cybersecurity professionals conducting penetration tests, incident response, or forensic analysis, enabling them to assess password strength and recover lost credentials. Its robust feature set and continuous development ensure it remains a leading solution in the field of password auditing.</i>


title: CAVEATS
content:
<i>Hashcat's powerful capabilities make it a sensitive tool. It should only be used for legal and ethical purposes, such as penetration testing on systems you have explicit permission to test, or for recovering your own forgotten passwords. Misuse can lead to severe legal consequences.<br>Performance heavily depends on hardware (especially GPUs), hash type, and the complexity of the password. High-end GPUs are often required for efficient cracking of complex hashes.</i>


title: ATTACK MODES
content:
<i>Hashcat supports various attack modes, each optimized for different scenarios. These include <B>dictionary attack</B> (0), which uses wordlists; <B>combinator attack</B> (1), combining two wordlists; <B>brute-force attack</B> (3) for trying all possible character combinations; <B>mask attack</B> (3, with masks), a more targeted brute-force; and <B>hybrid attacks</B> (6, 7) combining dictionary with mask components. Understanding the appropriate mode is crucial for efficient cracking.</i>


title: HASH TYPE IDENTIFICATION
content:
<i>Before cracking, it's essential to identify the hash type. Hashcat offers a <B>--hash-info</B> or <B>--identify</B> option (or requires manual identification via online tools like Hash-ID) to help determine the correct <B>-m</B> value, which is critical for successful cracking. Incorrect hash type specification will result in failure.</i>


title: HISTORY
content:
<i>Hashcat's origins trace back to independent projects: <I>oclHashcat</I> for OpenCL-based GPU cracking and <I>cudaHashcat</I> for CUDA-based GPU cracking. Developed by atom, these tools quickly gained prominence for their unparalleled speed and efficiency. In 2015, these two projects were merged into a single, unified codebase under the name <B>hashcat</B>, providing a consistent interface and broader hardware support. This consolidation cemented its position as the premier open-source password recovery tool, continuously evolving with new features, attack modes, and supported hash algorithms. Its development remains active, driven by the community and the ever-changing landscape of password security.</i>


title: SYNOPSIS
content:
<b>hashdeep</b> [OPTIONS] [FILE_OR_DIRECTORY...]<br><b>hashdeep</b> -k <I>hashfile</I> [OPTIONS] [FILE_OR_DIRECTORY...]


title: PARAMETERS
content:
<b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively process all files in the specified directories.<br><br><b><b>-k</b> <I>hashfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read known hashes from <I>hashfile</I> for verification mode.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verification mode. If <I>hashfile</I> is specified, compare; otherwise, report any issues. Exits 0 on success, non-zero on failure.<br><br><b><b>-a</b> <I>algo</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <I>algo</I> to the list of algorithms to compute. Can be used multiple times (e.g., --md5, --sha1).<br><br><b><b>-c</b> <I>algo</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;In verification mode, only compare hashes using the specified <I>algo</I>.<br><br><b><b>-j</b> <I>count</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <I>count</I> parallel jobs for hashing, speeding up processing on multi-core systems.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all file paths encountered during processing, even if not hashing.<br><br><b><b>-m</b> <I>size</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum file size to process. Files larger than <I>size</I> are skipped. Size can be like '10M' or '2G'.<br><br><b><b>-M</b> <I>count</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum amount of memory (in bytes) to use for storing hashes in verification mode. Can be like '1G'.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Silent mode. Suppress output except for error messages.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose mode. Display more information about the processing.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in CSV (Comma Separated Values) format.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in pretty format, with human-readable bytes and aligned columns.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bare output. Suppress the header line and any comments.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Follow symbolic links encountered during recursive directory traversal.<br><br><b><b>-o</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results to the specified <I>filename</I> instead of standard output.<br><br><b><b>-i</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read list of files/directories to process from <I>filename</I>, one per line. If '-' is specified, read from stdin.<br><br><b><b>--md5</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable MD5 hashing (shortcut for -a md5).<br><br><b><b>--sha1</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable SHA-1 hashing (shortcut for -a sha1).<br><br><b><b>--sha256</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable SHA-256 hashing (shortcut for -a sha256).<br><br><b><b>--sha512</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable SHA-512 hashing (shortcut for -a sha512).<br><br><b><b>--tiger</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable Tiger hashing (shortcut for -a tiger).<br><br><b><b>--whirlpool</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable Whirlpool hashing (shortcut for -a whirlpool).<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:
<I>hashdeep</I> is a powerful command-line utility for recursively computing and verifying cryptographic checksums (hashes) of files and directories. It is part of the <I>hashdeep</I> package, which also includes specialized tools like <I>md5deep</I> and <I>sha1deep</I>. <br><br>Capable of generating hash lists for entire directory structures, <I>hashdeep</I> supports multiple algorithms, including MD5, SHA-1, SHA-256, SHA-512, Tiger, and Whirlpool. This makes it invaluable for digital forensic analysis, data integrity verification, identifying duplicate files, and ensuring the authenticity of data. <br><br>It can output hash lists in various formats and, critically, can take a previously generated list of hashes as input to verify the integrity of the data at a later time, reporting any discrepancies or missing files. Its recursive nature and ability to process large datasets efficiently make it a go-to tool for large-scale data integrity checks.


title: CAVEATS
content:
When performing recursive operations, <I>hashdeep</I> does not follow symbolic links by default. Use the <b>-L</b> option explicitly if symbolic link traversal is desired, as this can significantly change the scope of files processed. <br><br>Verification mode with large hash sets (<b>-k</b>) can consume substantial memory; consider using <b>-M</b> to limit memory usage if necessary. <br><br>The accuracy of integrity checks relies on the cryptographic strength of the chosen hash algorithms. For robust security, modern algorithms like SHA-256 or SHA-512 are recommended over MD5 or SHA-1 for new applications.


title: OUTPUT FORMATS
content:
<I>hashdeep</I> offers several output formats. By default, it produces a header followed by entries showing the size, hash, and path for each file. The <b>-C</b> option changes the output to a CSV format, which is machine-parseable. The <b>-p</b> (pretty) option formats the output for human readability, aligning columns and showing file sizes in a more intuitive way. The <b>-b</b> (bare) option suppresses the header and comments, providing only the raw data entries. Choosing the appropriate format depends on whether the output is intended for human review or automated processing.


title: VERIFICATION PROCESS
content:
In verification mode (enabled with <b>-k</b> <I>hashfile</I>), <I>hashdeep</I> reads a list of known hashes and compares them against the files found on the system. It reports various states: <I>MATCH</I> for files with matching hashes, <I>MISMATCH</I> for files whose hashes do not match, <I>MISSING</I> for files listed in the hashfile but not found on the system, and <I>NEW FILE</I> for files found on the system but not present in the hashfile. This comprehensive reporting is crucial for detecting unauthorized modifications, missing data, or unexpected new files.


title: HISTORY
content:
The <I>hashdeep</I> command is a successor to a suite of deep-hashing tools, originally known as <I>md5deep</I>, <I>sha1deep</I>, etc. Developed by Jesse Kornblum, these tools were designed primarily for digital forensic purposes, allowing investigators to quickly and reliably calculate cryptographic hashes of files and entire directory structures. The <I>hashdeep</I> command was introduced to unify the functionality of these separate tools into a single, more versatile utility capable of supporting multiple hashing algorithms simultaneously, thereby streamlining integrity verification and data analysis workflows.


title: SYNOPSIS
content:
hashid [OPTIONS] <I>HASH_STRING</I><br>hashid [OPTIONS] <b>-m</b> <I>MODULE_ID</I><br>hashid [OPTIONS] <b>-d</b> <I>DESCRIPTION</I>


title: PARAMETERS
content:
<b><b>-m</b> <I>MODULE_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information for a specific hash module ID found in the <i>hashid</i> database.<br><br><b><b>-d</b> <I>DESCRIPTION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for hash modules by their descriptive name or a keyword within their description.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows extended information about identified hashes, including algorithm families and typical use cases.<br><br><b><b>-j</b>, <b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the identification results in JSON format, useful for scripting and integration.<br><br><b><b>-o</b>, <b>--optimize</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimizes the internal hash database (primarily for development or maintenance purposes).<br><br><b><b>-s</b>, <b>--show-stats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays statistics about the internal hash database, such as the total number of supported hash types.<br><br><b><b>-r</b>, <b>--regex</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats the input <I>HASH_STRING</I> as a regular expression for advanced pattern matching against hash formats.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's help message and available options.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's version information.<br><br>


title: DESCRIPTION
content:
<i>hashid</i> is a utility designed to identify the type of an unknown hash string. It works by analyzing the format, length, and characteristics of the provided hash and comparing it against an extensive database of known hash algorithms and structures. This is particularly useful for penetration testers, security researchers, and forensic analysts who encounter hash strings and need to determine their origin or algorithm before attempting to crack them with tools like <i>Hashcat</i> or <i>John the Ripper</i>. It can identify cryptographic hashes (e.g., MD5, SHA-1, SHA-256), password hashes (e.g., NTLM, WPA, various Unix formats), and many more. By providing the hash type, <i>hashid</i> streamlines the process of selecting the correct cracking module, saving significant time in security assessments.


title: CAVEATS
content:
While <i>hashid</i> boasts an extensive database, it does not cover every possible hash type. Some hash formats might have overlapping characteristics, leading to multiple potential identifications (false positives) which <i>hashid</i> will list. It identifies the <i>type</i> of hash, not its original value or validity.


title: IDENTIFICATION LOGIC
content:
<i>hashid</i> employs a sophisticated logic combining hash length, character sets, presence of specific prefixes or delimiters, and regular expressions to match input strings against its internal database. This database includes over 300 known hash types, each corresponding to a unique <i>Hashcat</i> module ID, enabling seamless integration with hash cracking workflows.


title: COMMON USE CASES
content:
Primarily utilized by ethical hackers, penetration testers, and forensic analysts, <i>hashid</i> quickly identifies hash types encountered in various contexts, such as configuration files, database dumps, and network captures. This identification is vital for selecting appropriate cracking tools and techniques, greatly aiding in security assessments and incident response by providing the necessary context for further analysis.


title: HISTORY
content:
<i>hashid</i> is a key component of the <i>hashcat-utils</i> suite, which complements the popular password cracking tool <i>Hashcat</i>. It was developed to streamline the process of identifying unknown hash formats, a crucial first step before attempting to crack them. Its development is intertwined with the evolution of <i>Hashcat</i> itself, aiming to provide a comprehensive ecosystem for hash analysis and cracking. It's commonly found pre-installed or available in security-focused Linux distributions like <i>Kali Linux</i> and <i>Parrot OS</i>.


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed Hatch version and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the general help message for Hatch, or for a specific command (e.g., <b>hatch new --help</b>).<br><br><b>COMMAND</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific subcommand to execute, dictating the action Hatch will perform (e.g., <b>new</b>, <b>env</b>, <b>run</b>, <b>build</b>, <b>publish</b>). Each command has its own set of options and arguments.<br><br><b>[ARGS]...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional arguments specific to the chosen <i>COMMAND</i>, which can include paths, names, or other options.<br><br>


title: DESCRIPTION
content:
Hatch is a comprehensive, modern, and extensible command-line interface (CLI) tool designed for managing Python projects. Unlike traditional system commands, it's primarily a Python application installed via `pip`. It provides a unified workflow for various aspects of the Python development lifecycle, including project creation, dependency management, virtual environment handling, executing custom scripts, building distributions, and publishing packages. Hatch emphasizes configuration through `pyproject.toml`, aligning with modern Python packaging standards, and offers a robust plugin system for custom workflows and integrations. It aims to streamline the development and deployment of Python applications and libraries.


title: CAVEATS
content:
Hatch is a Python-based tool and requires a Python installation (typically 3.8+) along with `pip` to be available on the system. It manages Python project-specific concerns, so it's not a general-purpose Linux system utility like file or process management commands. Its functionality is entirely tied to the Python ecosystem and project structure conventions.


title: PROJECT CONFIGURATION
content:
Hatch centralizes project configuration within the standard `pyproject.toml` file. This single source of truth defines project metadata, dependencies, custom scripts, and environment settings, simplifying project setup and ensuring consistency across development teams.


title: ENVIRONMENT MANAGEMENT
content:
Hatch provides powerful and flexible virtual environment management. It allows developers to define and activate isolated environments (e.g., <i>test</i>, <i>lint</i>, <i>docs</i>) within a project, ensuring dependency isolation and reproducible builds across different development contexts.


title: PLUGIN SYSTEM
content:
A core feature of Hatch is its extensible plugin system. This allows users to create custom project templates, environment types, builders, and hooks, enabling deep customization and integration with various tools and workflows specific to a project's needs.


title: HISTORY
content:
Hatch was created by Ofek Lev and first publicly released in 2021. It emerged as a modern, consolidated alternative to fragmented Python packaging and project management solutions. Its development prioritizes extensibility, adherence to contemporary Python Enhancement Proposals (PEPs) like `pyproject.toml` (PEP 517/660), and providing a streamlined, opinionated, yet highly configurable developer experience for managing Python projects end-to-end.


title: SYNOPSIS
content:
<b>haxelib</b> <i>[global_options] &lt;command&gt; [command_options] [arguments]</i><br><b>haxelib</b> <i>--help | -h</i><br><b>haxelib</b> <i>--version | -v</i>


title: PARAMETERS
content:
<b><b>install</b> <i>&lt;library&gt; [&lt;version&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specified library from the HaxeLib repository. If no version is specified, the latest stable version is installed.<br><br><b><b>update</b> <i>[&lt;library&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates one or all installed libraries to their latest available versions.<br><br><b><b>remove</b> <i>&lt;library&gt; [&lt;version&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstalls a specified library. If no version is specified, all versions are removed.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of all currently installed Haxe libraries along with their versions.<br><br><b><b>run</b> <i>&lt;library&gt; &lt;command&gt; [args...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a command provided by a specified library, useful for running library-specific tools.<br><br><b><b>set</b> <i>&lt;library&gt; &lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the active version for a given library, if multiple versions are installed.<br><br><b><b>path</b> <i>&lt;library&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installation path of a specified library, useful for debugging or integrating with build systems.<br><br><b><b>setup</b> <i>[&lt;path&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the root directory where <i>haxelib</i> stores libraries. If no path is provided, it prompts for one.<br><br><b><b>config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current Haxelib root directory.<br><br><b><b>search</b> <i>&lt;keyword&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches the HaxeLib repository for libraries matching the given keyword.<br><br><b><b>info</b> <i>&lt;library&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specified library, including available versions and description.<br><br><b><b>submit</b> <i>&lt;zipfile&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Submits a library package (as a zip file) to the HaxeLib repository. Requires user authentication.<br><br><b><b>user</b> <i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages HaxeLib user accounts. Subcommands include <i>login</i>, <i>logout</i>, <i>register</i>, <i>info</i>.<br><br><b><b>help</b> <i>[&lt;command&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows general help or specific help for a given <i>haxelib</i> command.<br><br><b><b>--version</b> <i>| <b>-v</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>haxelib</i> version information.<br><br><b><b>--debug</b> <i>| <b>-debug</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output for troubleshooting.<br><br><b><b>--quiet</b> <i>| <b>-quiet</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output, showing only errors.<br><br><b><b>--neko</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Neko executable to use (relevant for some older Haxe setups).<br><br><b><b>--connect</b> <i>&lt;host&gt; &lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a Haxe compilation server.<br><br>


title: DESCRIPTION
content:
<i>haxelib</i> is the official command-line tool for managing Haxe libraries. It allows developers to easily install, update, remove, and manage external dependencies for their Haxe projects. Beyond basic library management, <i>haxelib</i> also facilitates sharing custom libraries by enabling users to publish their packages to the HaxeLib repository and search for existing ones. It is an essential component of the Haxe development ecosystem, ensuring consistent dependency management across different Haxe projects and environments.


title: CAVEATS
content:
<i>haxelib</i> relies on the Haxe compiler and runtime (like Neko) being correctly installed and configured. Installation path can sometimes cause permission issues if not set up correctly (e.g., trying to install into system-wide locations without proper permissions). Older versions of Haxe and <i>haxelib</i> might have different behaviors or command structures.


title: HAXELIB ROOT DIRECTORY
content:
The environment variable <i>HAXELIB_PATH</i> can be used to override the default Haxelib root directory, which is typically <i>~/.haxelib</i> on Linux or a user-specific path on Windows. This is where all libraries are physically installed.


title: LOCAL LIBRARIES
content:
<i>haxelib</i> supports installing libraries directly from local directories using <i>haxelib dev &lt;library_name&gt; &lt;path_to_library&gt;</i>. This is very useful for developing a library locally and testing it within other projects without publishing.


title: HISTORY
content:
<i>haxelib</i> has been an integral part of the Haxe ecosystem since its early days, evolving alongside the Haxe language and compiler. It was introduced to standardize and simplify the process of distributing and consuming Haxe libraries, moving away from manual file copying. Its development closely tracks the Haxe compiler's releases, with updates often reflecting new language features or changes in how Haxe projects are structured. Its design principles are rooted in providing a robust, centralized, and easy-to-use solution for dependency management, similar to package managers in other language ecosystems.


title: PARAMETERS
content:
<b><b><PAYLOAD_FILE></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <i>mandatory</i> argument specifying the path to the binary Homebrew Payload file to be decoded.<br><br><b><b>-o</b> <i>FILE</i>, <b>--output</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an output <i>FILE</i> where the decoded information will be written instead of standard output (stdout).<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <i>verbose</i> output, providing more detailed information during the decoding process, potentially including raw hexadecimal dumps or more intricate structural breakdowns.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a <i>help message</i> outlining the command's usage and available options.<br><br>


title: DESCRIPTION
content:
<i>hbpldecode</i> is a specialized command-line utility designed to <b>analyze and decode binary Homebrew Payloads</b> primarily used within the Nintendo 3DS homebrew ecosystem. These payloads are often complex, custom-formatted binary files that contain executable code and data structures for various exploits or applications on the 3DS.<br><br>The command's primary function is to <b>parse the internal structure</b> of these payloads, extracting and presenting information such as their entry points, sections, size, and other metadata in a human-readable format. This is invaluable for developers, reverse engineers, and security researchers working on 3DS exploits or custom firmware. Unlike general-purpose binary analysis tools, <i>hbpldecode</i> is tailored specifically to understand the unique characteristics and formats of 3DS-specific homebrew payloads, providing a targeted and efficient way to inspect their contents and ensure their integrity or understand their behavior.


title: CAVEATS
content:
<i>hbpldecode</i> is <b>not a standard Linux distribution utility</b> and typically needs to be compiled from source code or obtained from specific repositories related to Nintendo 3DS homebrew development. Its functionality is highly specific to the <b>Nintendo 3DS Homebrew Payload format</b>, meaning it will not be useful for decoding arbitrary binary files or payloads from other platforms. The exact options and their behavior may vary slightly depending on the specific version or fork of the utility being used.


title: UNDERSTANDING HOMEBREW PAYLOADS
content:
A <i>Homebrew Payload</i> on the Nintendo 3DS typically refers to a custom, small, self-contained executable binary designed to be loaded and executed by a vulnerability or exploit. These payloads are often the first stage in a chain of events that leads to the execution of unsigned code, eventually granting access to the Homebrew Launcher or custom firmware. They are specifically crafted to interact with the 3DS's hardware and software at a very low level, often written in C or assembly for the ARM architecture. Their binary format is not a standard ELF or PE format but rather a custom structure optimized for direct memory loading and execution, which is why specialized tools like <i>hbpldecode</i> are necessary to parse them.


title: HISTORY
content:
<i>hbpldecode</i> emerged from the active and innovative <b>Nintendo 3DS homebrew and security research community</b>. It was developed as a crucial utility to aid in the understanding and debugging of custom binary payloads created by various developers and exploit implementers (such as smea, yellows8, and others) during the early days of 3DS hacking and the subsequent evolution of homebrew entrypoints like Homebrew Launcher. Its development was driven by the necessity to analyze the low-level structure of these unique binary formats, which are often highly optimized and specific to the ARM architecture and custom loaders on the 3DS console.


title: SYNOPSIS
content:
<b>hciattach</b> [<i>-n</i>] [<i>-p</i>] [<i>-b baud_rate</i>] [<i>-t timeout</i>] [<i>-l</i>] [<i>-r</i>] [<i>-s initial_speed</i>] [<i>-f</i>] [<i>-e</i>] [<i>-c channel</i>] [<i>-i</i>] [<i>-m</i>] [<i>-d</i>] [<i>-v</i>] <i>device</i> <i>type</i> [<i>speed</i>] [<i>flow_control</i>]


title: PARAMETERS
content:
<b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The serial port device file to be used (e.g., /dev/ttyS0, /dev/ttyUSB0).<br><br><b><i>type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The type of Bluetooth chip. Common types include <b>any</b> (autodetect), <b>broadcom</b>, <b>csr</b>, <b>texas</b>, <b>intel</b>, <b>marvell</b>, <b>atheros</b>, <b>st</b>, <b>cc256x</b>.<br><br><b><i>speed</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary baud rate to set the serial port to (e.g., <b>115200</b>). This is the communication speed after initialization.<br><br><b><i>flow_control</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument to specify flow control, typically <b>flow</b> for hardware flow control or <b>noflow</b> to disable it.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>No flow control.</i> Disables RTS/CTS hardware flow control explicitly.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Pick PTS baud rate.</i> Selects a baud rate commonly used for PTS (Protocol Testing System) testing.<br><br><b><b>-b</b> <i>baud_rate</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Reset baud rate.</i> Specifies an alternative baud rate that is used during the device's reset sequence.<br><br><b><b>-t</b> <i>timeout</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Initialization timeout.</i> Sets a timeout in seconds for the device initialization process. If the device doesn't respond within this time, <b>hciattach</b> will abort.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Log to syslog.</i> Redirects all output and error messages from <b>hciattach</b> to the system log (syslog).<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Hardware reset.</i> Attempts to perform a hardware reset on the device before beginning the initialization process.<br><br><b><b>-s</b> <i>initial_speed</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Initial speed.</i> Sets an initial baud rate for devices that require speed negotiation or a lower speed for initial communication.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Force reset.</i> Forces a reset attempt even if the device times out during initialization.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Exit on error.</i> The command will terminate immediately if any error occurs during operation.<br><br><b><b>-c</b> <i>channel</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>BCSP channel.</i> Specifies the BCSP (Bluetooth Serial Protocol) channel number, typically used with CSR (Cambridge Silicon Radio) devices.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Intel initialization.</i> Activates specific initialization routines designed for Intel Bluetooth devices.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Marvell initialization.</i> Activates specific initialization routines designed for Marvell Bluetooth devices.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Debug mode.</i> Enables verbose debugging output to assist in troubleshooting.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Version information.</i> Displays the <b>hciattach</b> version and exits.<br><br>


title: DESCRIPTION
content:
hciattach is a Linux command-line utility used to initialize and attach serial-port-based Bluetooth devices to the Linux Bluetooth subsystem (BlueZ). It configures the specified serial port (e.g., /dev/ttyUSB0 or /dev/ttyS0) to communicate with a Bluetooth host controller. This process typically involves setting the correct baud rate, applying flow control settings, and uploading necessary firmware or initialization scripts specific to the Bluetooth chip type (e.g., Broadcom, CSR, Texas Instruments, Intel). Once hciattach successfully completes, the serial device becomes a recognized HCI (Host Controller Interface) device, accessible via tools like hciconfig or hcitool, allowing Bluetooth communication to commence. It bridges the gap between the physical serial connection and the software Bluetooth stack.


title: CAVEATS
content:
hciattach typically requires root privileges to access serial ports and configure the Bluetooth stack. Selecting the incorrect <i>type</i> argument can prevent the device from initializing correctly, often due to a failure in uploading the proper firmware. For certain chipsets, the required firmware files must be present in specific system directories (e.g., /lib/firmware/brcm). Services like ModemManager might interfere with serial port access and may need to be disabled. Debugging usually involves checking serial port permissions, cable connections, and system logs (<b>dmesg</b>, <b>syslog</b>) for detailed error messages.


title: FIRMWARE LOADING
content:
Many Bluetooth chipsets require specific firmware to be loaded onto them after power-on for proper operation. <b>hciattach</b> is frequently responsible for this task, reading firmware files (e.g., .hcd files for Broadcom devices) from system paths like /lib/firmware/brcm based on the specified chip <i>type</i>. If the correct firmware is not found or successfully loaded, the device may fail to appear as an HCI device or function erratically.


title: PERSISTENT CONFIGURATION
content:
For automatic initialization of Bluetooth devices upon system boot, <b>hciattach</b> commands are typically integrated into system startup configurations. This can involve adding entries to files like /etc/rc.local (on older systems) or, more commonly in modern Linux distributions, creating custom systemd service units that execute the <b>hciattach</b> command during the boot process, ensuring the Bluetooth device is always ready for use.


title: HISTORY
content:
<b>hciattach</b> is an integral part of the BlueZ project, which serves as the official Bluetooth protocol stack for Linux. Its development emerged from the necessity to standardize the setup of serial-based Bluetooth host controllers, commonly found in embedded systems, older hardware, or when using external USB-to-serial Bluetooth dongles. The command has evolved over time to support a wider array of Bluetooth chipsets, each often requiring unique initialization sequences and firmware uploads to integrate seamlessly with the Linux HCI stack.


title: PARAMETERS
content:
<b><i>hciX</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Bluetooth device to configure (e.g., <i>hci0</i>, <i>hci1</i>). If omitted, <i>hciconfig</i> typically operates on the first available device or lists all devices if no command is given.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used without a command, displays all available information for all configured Bluetooth devices, including extended statistics.<br><br><b><b>up</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the specified Bluetooth device, making it ready for connections and scans.<br><br><b><b>down</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates the specified Bluetooth device, taking it offline and preventing connections.<br><br><b><b>reset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the specified Bluetooth device to its default state, often used to resolve communication issues.<br><br><b><b>rstat</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays run-time statistics for the specified Bluetooth device, such as transmitted and received packets, and error counts.<br><br><b><b>nstat</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the run-time statistics for the specified Bluetooth device to zero.<br><br><b><b>pscan</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables page scan mode, allowing the device to be discoverable and connectable by other Bluetooth devices.<br><br><b><b>iscan</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables inquiry scan mode, allowing the device to respond to inquiries from other Bluetooth devices, making it discoverable.<br><br><b><b>noscan</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables both page and inquiry scan modes, making the device undetectable and unconnectable by other Bluetooth devices (unless already paired).<br><br><b><b>lm</b> [<i>mode</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets or displays the link mode. Common modes include <i>auth</i> (authentication), <i>encrypt</i> (encryption), <i>sauth</i> (secure authentication), <i>sencrypt</i> (secure encryption).<br><br><b><b>lp</b> [<i>policy</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets or displays the link policy. Policies include <i>master/slave switch</i>, <i>hold</i>, <i>sniff</i>, and <i>park</i> modes for power management and connection efficiency.<br><br><b><b>name</b> [<i>name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets or displays the local human-readable name of the Bluetooth device. If <i>name</i> is omitted, the current name is displayed.<br><br><b><b>class</b> [<i>class</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets or displays the Class of Device (CoD) for the Bluetooth adapter. CoD is a 24-bit value that describes the primary service class, major device class, and minor device class.<br><br><b><b>auth</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables authentication for new connections, requiring pairing or passkey exchange.<br><br><b><b>noauth</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables authentication, allowing connections without pairing requirements (less secure).<br><br><b><b>encrypt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables encryption for new connections, securing data transfer.<br><br><b><b>noencrypt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables encryption for new connections (less secure).<br><br><b><b>leadv</b> [<i>type</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures LE (Low Energy) advertising type for the device.<br><br><b><b>leadvdata</b> [<i>data</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets LE advertising data, which is broadcasted to other LE devices.<br><br><b><b>lescan</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables LE (Low Energy) scanning mode, allowing the device to discover other LE devices.<br><br><b><b>nolescan</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables LE (Low Energy) scanning mode.<br><br>


