# CommandSection

title: CONFIGURATION
content:
<i>s3cmd</i> requires a configuration file, typically located at <i>~/.s3cfg</i>. This file stores your AWS Access Key ID, Secret Access Key, and other default settings. It can be easily generated or modified using the <b>s3cmd --configure</b> command, which guides you through the setup process. Proper configuration is essential for <i>s3cmd</i> to authenticate and interact with your S3 buckets.


title: S3 CONCEPTS: BUCKETS AND OBJECTS
content:
Amazon S3 operates on two primary concepts: <i>buckets</i> and <i>objects</i>. A <i>bucket</i> is a container for objects, similar to a top-level directory. It must have a globally unique name. An <i>object</i> is the fundamental entity stored in S3, consisting of data (e.g., a file) and its metadata. <i>s3cmd</i> allows you to manage both, creating/delleting buckets and uploading/downloading/manipulating objects within them.


title: HISTORY
content:
<i>s3cmd</i> originated as an open-source project written in Python, designed to provide a simple command-line interface for Amazon S3. It gained popularity as one of the earliest and most widely used non-official tools for S3 interaction, preceding the development of the official <i>AWS CLI</i>. Over the years, it has been maintained by a community of developers, adapting to changes in the S3 API and remaining a popular choice for straightforward S3 operations and scripting.


title: SYNOPSIS
content:
<b>sails</b> <i>&lt;command&gt;</i> [<i>options</i>]<br><b>sails</b> <i>&lt;command&gt;</i> [<i>arguments</i>]


title: PARAMETERS
content:
<b><b>new</b> <i>&lt;project-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new Sails.js project in a directory named <I>project-name</I>.<br><br><b><b>lift</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lifts (starts) the Sails.js application in the current directory.<br><br><b><b>generate</b> <i>&lt;blueprint&gt;</i> [<i>name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new file based on a blueprint (e.g., <I>controller</I>, <I>model</I>, <I>service</I>).<br><br><b><b>console</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens an interactive Node.js REPL (Read-Eval-Print Loop) with access to the Sails.js application's global variables and models.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed Sails CLI version.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the main command or a specific subcommand.<br><br><b><b>--port</b> <i>&lt;number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>lift</I>) Specifies the port on which to run the server.<br><br><b><b>--prod</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>lift</I>) Lifts the application in production mode, optimizing performance and logging.<br><br><b><b>--no-install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>new</I>) Skips the 'npm install' step after creating a new project.<br><br>


title: DESCRIPTION
content:
The <b>sails</b> command-line interface (CLI) is the primary tool for interacting with the <I>Sails.js</I> web framework. Sails.js is a Model-View-Controller (MVC) framework for Node.js, designed to streamline the development of custom enterprise-grade Node.js applications, aiming to replicate the rapid development experience of Ruby on Rails. The <b>sails</b> command enables developers to scaffold new projects, generate controllers, models, and services, lift (start) the application server, run database migrations, and manage other aspects of a Sails.js application. It significantly boosts developer productivity by automating repetitive setup tasks and providing powerful code generation capabilities. While not a native Linux utility, it is widely used in environments where Node.js web applications are developed and deployed.


title: CAVEATS
content:
The <b>sails</b> command is not a standard Linux system utility. It requires Node.js and npm (Node Package Manager) to be installed on your system. It is specifically designed for developing and managing applications built with the Sails.js framework, and its functionality is entirely dependent on the context of a Sails.js project.


title: INSTALLATION
content:
To use the <b>sails</b> command, you must first install it globally via npm:<br>npm install -g sails<br>This makes the <b>sails</b> command available in your system's PATH.


title: PROJECT CONTEXT
content:
Many <b>sails</b> commands (e.g., <I>lift</I>, <I>generate</I>, <I>console</I>) must be executed within the root directory of an existing Sails.js project for them to function correctly.


title: HISTORY
content:
The Sails.js framework, and consequently its CLI tool, was first released in 2012 by Mike McNeil. It was conceived to provide a more structured and rapid development experience for Node.js web applications, drawing inspiration from established frameworks like Ruby on Rails. Over the years, the <b>sails</b> CLI has evolved alongside the framework, incorporating new features and streamlining workflows for generating code, managing dependencies, and deploying applications, making it an indispensable tool for Sails.js developers.


title: SYNOPSIS
content:
<b>sbctl</b> [<i>OPTIONS</i>] <i>COMMAND</i> [<i>ARGUMENTS...</i>]<br><b>sbctl</b> <i>status</i><br><b>sbctl</b> <i>create-keys</i><br><b>sbctl</b> <i>enroll-keys</i> [--microsoft]<br><b>sbctl</b> <i>sign</i> [--save] <i>&lt;file&gt;</i>


title: PARAMETERS
content:
<b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the current Secure Boot status and key enrollment.<br><br><b>create-keys</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new Secure Boot key hierarchy (Platform Key, Key Exchange Key, Signature Database).<br><br><b>enroll-keys</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enrolls the generated Secure Boot keys into the UEFI firmware. Can include <i>--microsoft</i> to enroll Microsoft keys.<br><br><b>sign <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Signs an EFI binary, kernel image, or initramfs with the generated Secure Boot keys.<br><br><b>validate <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Validates the Secure Boot signature of a specified EFI binary.<br><br><b>list-enrolled</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all Secure Boot keys currently enrolled in the UEFI firmware.<br><br><b>verify-files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the signatures of all files configured to be signed by <i>sbctl</i>.<br><br><b>help [<i>command</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help information or specific help for a given <i>sbctl</i> subcommand.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an operation to proceed, overriding certain safety checks or warnings.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about <i>sbctl</i>'s operations.<br><br>


title: DESCRIPTION
content:
<i>sbctl</i> is a command-line utility designed to simplify the management of Secure Boot on Linux systems.<br>It allows users to generate, enroll, and manage Secure Boot keys (PK, KEK, DB) and to sign EFI binaries, kernel images, and bootloaders.<br>This tool is crucial for users who want to enable Secure Boot while using custom kernels, bootloaders, or third-party EFI applications, as it provides a straightforward way to create trusted signatures that the UEFI firmware can verify.<br>By using <i>sbctl</i>, users can ensure the integrity of their boot process, preventing unauthorized code from executing before the operating system loads.<br>It typically interacts with the UEFI firmware to enroll keys and with the file system to sign files, making the Secure Boot setup process more accessible for a wider range of Linux users.


title: CAVEATS
content:
Requires UEFI firmware with Secure Boot support enabled in the BIOS/UEFI settings.<br>Incorrect key management can lead to an unbootable system, requiring manual intervention or Secure Boot disablement.<br>Typically requires root privileges (sudo) to interact with UEFI variables and system files.<br>Relies on underlying utilities like <i>efivarfs</i> for UEFI variable access.


title: KEY HIERARCHY
content:
<i>sbctl</i> manages the standard Secure Boot key hierarchy: <b>Platform Key (PK)</b>, <b>Key Exchange Key (KEK)</b>, and <b>Signature Database (DB)</b>.<br>The PK signs the KEK, and the KEK signs the DB.<br>UEFI firmware verifies boot components against the keys present in the DB.


title: FILE SIGNING PROCESS
content:
<i>sbctl</i> signs files by embedding a cryptographic signature directly into the Portable Executable (PE/COFF) header of EFI executables (e.g., kernels, bootloaders).<br>When the UEFI firmware attempts to load a signed EFI executable, it verifies this embedded signature against the enrolled keys in its Signature Database (DB). If the signature is valid, the executable is allowed to run; otherwise, it is blocked.


title: HISTORY
content:
<i>sbctl</i> is a relatively modern tool, gaining traction with the increased adoption of Secure Boot on Linux distributions. It was developed to simplify the often complex process of managing Secure Boot keys and signing binaries, which previously required more manual steps involving disparate utilities.<br>Its development aimed to provide a unified, user-friendly interface for setting up Secure Boot, particularly for systems utilizing <i>systemd-boot</i> or other minimalistic bootloaders.<br>It emerged as a response to the growing need for a streamlined approach to Secure Boot on personal Linux systems, bridging the gap between hardware security features and user-friendliness.


title: SYNOPSIS
content:
<B>sbigtopgm</B> [ <I>-b|--bias bias_file</I> ] [ <I>-d|--dark dark_file</I> ] [ <I>-f|--flat flat_file</I> ] [ <I>-v|--verbose</I> ] [ <I>-g|--gamma gamma_value</I> ] [ <I>-i|--input-offset offset_value</I> ] [ <I>-o|--output-gain gain_value</I> ] [ <I>-p|--precision</I> ] [ <I>-s|--scale</I> ] [ <I>-c|--crop x,y,width,height</I> ] [ <I>input_file</I> ]<br><br>When <I>input_file</I> is not specified, <B>sbigtopgm</B> reads from standard input. Output is always to standard output.


title: PARAMETERS
content:
<b>-b, --bias bias_file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Subtracts the specified bias frame from the image. The <I>bias_file</I> must be in SBIG format.<br><br><b>-d, --dark dark_file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Subtracts the specified dark frame from the image. The <I>dark_file</I> must be in SBIG format.<br><br><b>-f, --flat flat_file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Divides the image by the specified flat field frame. The <I>flat_file</I> must be in SBIG format.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints detailed information about the input file and the processing steps to standard error.<br><br><b>-g, --gamma gamma_value</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies gamma correction to the image. A <I>gamma_value</I> greater than 1 brightens shadows, less than 1 darkens them.<br><br><b>-i, --input-offset offset_value</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a constant offset to all pixel values before any other processing (e.g., calibration frames).<br><br><b>-o, --output-gain gain_value</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Multiplies all pixel values by a gain factor after processing, affecting the overall brightness.<br><br><b>-p, --precision</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves the original pixel depth of the SBIG file. The output PGM will use the exact maximum value from the input, without scaling to the PGM maxval (65535 for 16-bit).<br><br><b>-s, --scale</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scales the output pixel values to the full PGM intensity range (e.g., 0-65535 for 16-bit). This is the default behavior if <I>-p</I> is not used, ensuring the PGM file uses its full dynamic range.<br><br><b>-c, --crop x,y,width,height</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Crops the image to the specified rectangular region, where <I>x</I> and <I>y</I> are the top-left coordinates, and <I>width</I> and <I>height</I> define the size of the crop.<br><br>


title: DESCRIPTION
content:
<B>sbigtopgm</B> is a utility from the <B>Netpbm</B> package designed to convert raw image files produced by <B>SBIG (Santa Barbara Instrument Group)</B> astronomical cameras into the standard <B>Portable Graymap (PGM)</B> format. This is crucial for astronomers and astrophotographers who use SBIG CCD cameras, as it allows them to process and view their captured images using a wide range of image processing tools that support the PGM format.<br><br>The command supports various image calibration techniques essential for astronomical imaging, including <B>dark frame subtraction</B>, <B>flat field correction</B>, and <B>bias frame subtraction</B>, to remove noise and correct for sensor imperfections. It also offers options for scaling, gamma correction, and cropping, enabling users to prepare images for further analysis or visual presentation.


title: CAVEATS
content:
<ul><li><B>SBIG File Format Specificity:</B> <B>sbigtopgm</B> is designed for the specific raw image format produced by Santa Barbara Instrument Group (SBIG) cameras and may not work with other camera raw formats.</li><li><B>Monochrome Output:</B> The command produces Portable Graymap (PGM) files, which are inherently monochrome. While SBIG cameras can sometimes capture color data (e.g., with Bayer filters), <B>sbigtopgm</B> primarily processes the raw grayscale intensity data.</li><li><B>Calibration Frame Requirement:</B> For effective noise reduction and image correction using dark, bias, and flat frames, these calibration frames must also be in the SBIG format.</li></ul>


title: USAGE IN ASTROPHOTOGRAPHY
content:
This tool is fundamental for astrophotographers using SBIG cameras. It allows them to convert proprietary raw files into a standard format, making it possible to apply advanced astronomical image processing techniques (e.g., stacking, deconvolution) using other software that commonly supports PGM or can convert from PGM.


title: STANDARD INPUT/OUTPUT
content:
Like many Unix-philosophy tools, <B>sbigtopgm</B> can read from standard input if no input file is specified, and always writes its output to standard output. This facilitates piping it with other commands, for example: <I>cat image.sbig | sbigtopgm -v | pgmtopng > image.png</I>.


title: HISTORY
content:
<B>sbigtopgm</B> is a component of the <B>Netpbm</B> project, a suite of graphics utilities for converting, processing, and creating various image formats. Its inclusion reflects the need within the astronomical community to process specialized raw image data from SBIG CCD cameras into a more universally accessible format. It has been developed and maintained as part of the broader Netpbm toolkit, ensuring compatibility and integration with other image manipulation functionalities offered by the suite.


title: PARAMETERS
content:
<b><i>-o</i> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file for the CSV data. If not provided, output is written to standard output (<i>stdout</i>).<br><br><b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all possible fields in the CSV output, overriding any default field selections.<br><br><b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the output of the header line in the CSV file, which normally contains the column names.<br><br><b><i>-d</i> <i>&lt;delimiter&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the column delimiter for the CSV output. Default is typically a comma (<i>,</i>).<br><br><b><i>-f</i> <i>&lt;fields&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of fields to include in the CSV output. E.g., '<i>hop_ip,rtt,ttl</i>'.<br><br><b><i>-F</i> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads a list of desired fields from the specified <i>&lt;file&gt;</i>, with one field per line.<br><br><b><i>-m</i> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output to include only measurements of a specific type, such as '<i>ping</i>', '<i>traceroute</i>', or '<i>paris-traceroute</i>'.<br><br><b><i>warts_file ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input <i>warts</i> files to be processed. If no files are specified, input is read from standard input (<i>stdin</i>).<br><br>


title: DESCRIPTION
content:
<i>sc_warts2csv</i> is a utility designed to transform binary network measurement data, typically collected by the <i>scamper</i> tool, from its native <i>warts</i> format into a comma-separated values (CSV) format. The <i>warts</i> format is a compact, binary representation optimized for storing large volumes of network probing results, such as those from <i>traceroute</i> or <i>ping</i> operations.<br><br>Converting to CSV makes the data easily readable by humans and importable into various analysis tools, spreadsheets (like Excel, Google Sheets, LibreOffice Calc), and databases. This conversion is crucial for post-measurement analysis, enabling researchers and network administrators to extract specific metrics, visualize trends, and perform statistical analysis on the collected network performance data without needing specialized <i>warts</i> parsers. It simplifies data sharing and interoperability with other data processing pipelines.


title: CAVEATS
content:
<i>sc_warts2csv</i> requires <i>warts</i> files as input, which are typically generated by the <i>scamper</i> network measurement tool. It cannot directly process raw network traffic captures.<br><br>The exact set of available fields for CSV output can vary depending on the <i>warts</i> file's content (i.e., what type of measurements it contains) and the version of <i>scamper</i> that generated it. Not all fields are universally present across all <i>warts</i> records. Converting very large <i>warts</i> files can be memory and CPU intensive, and the resulting CSV can also be very large.


title: DEFAULT OUTPUT FIELDS
content:
By default, <i>sc_warts2csv</i> attempts to output a reasonable set of common fields based on the measurement type (e.g., <i>traceroute</i> will typically have <i>hop_ip</i>, <i>rtt</i>, <i>ttl</i>). Users can override this with the <i>-a</i>, <i>-f</i>, or <i>-F</i> options to customize the output fields.


title: INPUT FROM <I>STDIN</I>
content:
If no input <i>warts_file</i> is specified, <i>sc_warts2csv</i> will read <i>warts</i> data from standard input (<i>stdin</i>). This allows it to be efficiently chained with other <i>scamper</i> utilities, for example: <i>scamper -O warts | sc_warts2csv -s -m ping</i>.


title: HISTORY
content:
<i>scamper</i> and its associated utilities, including <i>sc_warts2csv</i>, were developed by the Center for Applied Internet Data Analysis (CAIDA) as part of their efforts to provide robust tools for large-scale internet measurement. The <i>warts</i> format itself was designed specifically for <i>scamper</i> to efficiently store diverse network measurement data.<br><br><i>sc_warts2csv</i> was created to make this rich, binary data more accessible for analysis using common spreadsheet and database tools, reflecting the community's need for interoperable data formats in network research. Its development paralleled the growth and refinement of the <i>scamper</i> tool itself, ensuring that collected data could be easily consumed and analyzed by a broader audience of researchers and operators.


title: SYNOPSIS
content:
<b>sc_warts2json</b> [<i>-o output_file</i>] [<i>-p</i>] [<i>-r</i>] [<i>-R</i>] [<i>-v</i>] [<i>warts_file ...</i>]<br>If no <i>warts_file</i> is specified, <i>sc_warts2json</i> reads data from standard input.


title: PARAMETERS
content:
<b><b>-o</b> <i><output_file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the JSON output to the specified <i>output_file</i> instead of standard output (stdout).<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables "pretty printing" of the JSON output, adding indentation and newlines to make it more human-readable.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, <i>sc_warts2json</i> outputs the converted Warts records as elements within a single JSON array. Without this option, it prints a stream of individual JSON objects (one per line).<br><br><b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a single JSON object with two top-level fields: a <i>status</i> field indicating the processing outcome (e.g., success or error), and a <i>data</i> field containing an array of the converted Warts records. This provides more context about the conversion process itself.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates verbose mode, causing <i>sc_warts2json</i> to print informational and diagnostic messages to standard error (stderr) during processing.<br><br>


title: DESCRIPTION
content:
<i>sc_warts2json</i> is a utility from the <b>scamper</b> suite designed to transform network measurement data stored in the binary Warts format into a human-readable and machine-parseable JSON (JavaScript Object Notation) format. Warts is a specialized format used by <i>scamper</i> for efficient storage of various network measurement types, including traceroute paths, ping results, and Multi-Destination Address (MDA) probing data.<br><br>The conversion to JSON facilitates easier analysis and integration of <i>scamper</i>'s output with other tools and programming languages that readily support JSON parsing. Each individual measurement record within a Warts file (e.g., a single traceroute or ping) is converted into a distinct JSON object. By default, these objects are output as a stream of JSON entities, but options are available to enclose them within a single JSON array for a more structured output. This command is invaluable for researchers and network engineers who collect large volumes of network performance data and need to process it programmatically.


title: CAVEATS
content:
The <i>sc_warts2json</i> command is specifically designed for Warts files generated by <i>scamper</i>. Compatibility with Warts files from other sources is not guaranteed and may lead to parsing errors.<br><br>For very large Warts files, converting to pretty-printed JSON (using the <i>-p</i> option) can significantly increase the output file size and may consume more memory and processing time.<br><br>Ensure that the input Warts file is not corrupted; corrupted files may cause the conversion process to fail or produce incomplete JSON output.


title: INPUT/OUTPUT BEHAVIOR
content:
By default, <i>sc_warts2json</i> reads from standard input if no specific Warts files are provided as arguments. It writes the resulting JSON output to standard output, which can then be piped to other commands or redirected to a file.


title: ERROR HANDLING
content:
The command typically exits with a non-zero status code if it encounters errors during file parsing or processing, indicating a failure. Verbose mode (<i>-v</i>) can provide more details on such errors.


title: HISTORY
content:
<i>sc_warts2json</i> was first implemented in March 2017 as part of the ongoing development of the <b>scamper</b> network measurement suite by the Center for Applied Internet Data Analysis (CAIDA). Its creation addressed the growing need for easier programmatic access and analysis of <i>scamper</i>'s measurement data, moving from a binary-centric format (Warts) to a widely adopted, interoperable text-based format (JSON).


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and commands.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current <b>scalafmt</b> version.<br><br><b>--config <path>, -c <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the <code>.scalafmt.conf</code> configuration file.<br><br><b>--test, --check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if files are formatted according to the configuration without modifying them. Exits with a non-zero code if any files are not formatted correctly.<br><br><b>--diff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats only the lines that have changed in the current Git diff, typically against the master branch.<br><br><b>--stdout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the formatted content of the input files to standard output instead of writing back to the files.<br><br><b>--stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads Scala code from standard input, formats it, and prints the result to standard output.<br><br><b>--files <glob...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a list of files or glob patterns to format. Overrides patterns defined in the configuration file.<br><br><b>--exclude <glob...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies files or glob patterns to exclude from formatting.<br><br><b>--respect-project-filters</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <b>scalafmt</b> to respect <code>.scalafmtignore</code> and <code>.gitignore</code> files for filtering files.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows which files would be formatted without actually writing any changes to disk.<br><br><b>--non-interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses prompts and assumes default or affirmative answers.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most informational output, only showing errors.<br><br>


title: DESCRIPTION
content:
<b>scalafmt</b> is a powerful and opinionated code formatter for Scala. Its primary goal is to ensure consistent code style across projects and development teams, enhancing readability and maintainability. By parsing Scala source code into an Abstract Syntax Tree (AST), <b>scalafmt</b> applies a set of configurable rules to reformat the code, adhering to predefined stylistic guidelines.<br><br>It aims to eliminate bikeshedding over code style, allowing developers to focus on logic rather than formatting. While <b>scalafmt</b> comes with sensible default settings, it is highly configurable via a <code>.scalafmt.conf</code> file, enabling teams to customize formatting rules to match their specific preferences or adhere to organizational standards. This configuration file allows fine-grained control over aspects like indentation, line breaks, brace style, and more.<br><br><b>scalafmt</b> integrates seamlessly into various development workflows, including command-line usage, build tools like sbt and Mill, and IDEs. It supports different Scala versions and offers features like checking formatting without modifying files, formatting only changed lines (useful in Git hooks), and piping input/output for scripting. Its deterministic output ensures that running the formatter multiple times on the same input yields identical results.


title: CAVEATS
content:
<ul><li><b>Configuration Complexity</b>: While powerful, the <code>.scalafmt.conf</code> file can become complex, requiring familiarity with HOCON syntax and <b>scalafmt</b>'s specific options.</li><li><b>Performance</b>: On very large codebases with many files, <b>scalafmt</b> can take a noticeable amount of time to run, especially if invoked without caching or incremental analysis.</li><li><b>Scala Version Compatibility</b>: Ensure the <b>scalafmt</b> version is compatible with your project's Scala version, as new Scala language features might require a more recent formatter.</li><li><b>Integration Challenges</b>: Integrating with specific IDEs or older build setups might require custom scripting or plugin configurations.</li></ul>


title: CONFIGURATION FILE
content:
The primary way to configure <b>scalafmt</b> is through a <code>.scalafmt.conf</code> file, typically located at the project root. This file uses the HOCON format and allows defining rules for indentation, line length, blank lines, imports, and many other stylistic aspects.


title: BUILD TOOL INTEGRATION
content:
<b>scalafmt</b> is commonly integrated into Scala build tools. For sbt, the <code>sbt-scalafmt</code> plugin provides sbt tasks like <code>scalafmt</code> and <code>scalafmtCheck</code>. This allows formatting code as part of the build process or before committing changes, ensuring all code adheres to the defined style.


title: HISTORY
content:
<b>scalafmt</b> was primarily developed by VirtusLab as an opinionated code formatter for the Scala programming language. Its development began around 2016-2017, aiming to provide a robust and highly configurable tool to address the common problem of inconsistent code styles within Scala projects.<br><br>It gained significant traction within the Scala community due to its reliability, rich configuration options, and seamless integration with popular build tools like sbt and Mill. Over time, it has become a standard and widely adopted tool for maintaining code quality and consistency in Scala codebases, playing a crucial role in enabling large-scale collaborative development. Its design emphasizes determinism, ensuring that formatted code remains stable across runs and different environments.


title: SYNOPSIS
content:
<b>scamper</b> <i>[OPTIONS] [COMMAND [ARGS...]]</i><br><b>scamper</b> <i>-I &lt;input_file&gt; -o &lt;output_file&gt; -D &lt;data_type&gt; [OPTIONS]</i>


title: PARAMETERS
content:
<b><b>-I</b> <i>&lt;filename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an input file containing target IP addresses or hostnames for measurements.<br><br><b><b>-o</b> <i>&lt;filename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file where measurement results will be stored.<br><br><b><b>-D</b> <i>&lt;data_type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the type of data to collect (e.g., <b>tr</b> for traceroute, <b>ping</b> for ping, <b>paris-tr</b> for Paris traceroute).<br><br><b><b>-c</b> <i>&lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of probes or queries to send for each target.<br><br><b><b>-O</b> <i>&lt;options&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides additional, comma-separated options specific to the chosen data collection type (e.g., <b>tr.max-hops=30</b>).<br><br><b><b>-p</b> <i>&lt;procs&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of parallel probing processes or threads to run concurrently.<br><br><b><b>-i</b> <i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific network interface for sending probes.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs measurement output to standard output (stdout) instead of a file.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the execution process.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>scamper</i> version information and exits.<br><br>


title: DESCRIPTION
content:
<i>scamper</i> is a sophisticated command-line tool designed for active Internet topology discovery and measurement. Unlike simpler utilities like <i>traceroute</i>, <i>scamper</i> can conduct multiple concurrent measurements, offering various probing methods including ICMP, UDP, and TCP. It is commonly used by network researchers to map the Internet's structure, identify network paths, and diagnose connectivity issues on a large scale.<br><br>It supports multiple output formats, most notably "warts" (Wide Area Reverse Traceroute Storage), which is optimized for storing large volumes of path data, but also JSON and CSV for easier processing. <i>scamper</i> allows for precise control over probing parameters, making it a powerful tool for detailed network analysis beyond basic reachability checks. Its ability to perform parallel measurements significantly speeds up large-scale data collection.


title: CAVEATS
content:
<i>scamper</i> typically requires <b>root</b> privileges to perform raw socket operations for its measurements.<br>It can generate significant network traffic, especially when conducting large-scale topology scans, which might impact network performance or trigger rate limits.<br>Its native "warts" output format is a binary format that may require dedicated tools or <i>scamper</i> itself for parsing and analysis, making direct human readability challenging.


title: COMMON DATA TYPES (<B>-D</B> OPTION)
content:
The <b>-D</b> option specifies the type of measurement to perform:<br><b>tr</b>: Performs standard <i>traceroute</i> measurements.<br><b>ping</b>: Conducts simple <i>ping</i> measurements to check reachability.<br><b>paris-tr</b>: Executes Paris <i>traceroute</i>, a variant designed to identify paths more accurately, even with load-balancing.<br><b>warts-dump</b>: Used for processing existing "warts" files, often to convert them to other formats like JSON or CSV when combined with <b>-s</b> and appropriate parsing tools.


title: WARTS FILE FORMAT
content:
The "warts" (Wide Area Reverse Traceroute Storage) format is <i>scamper</i>'s native binary output format. It is specifically optimized for storing large volumes of active measurement data, particularly Internet paths collected by traceroute-like tools. Due to its binary nature, it's not human-readable directly and typically requires <i>scamper</i> itself or companion tools like <b>scamper-parse</b> (often distributed with <i>scamper</i>) to extract and convert the data into more accessible formats like JSON or CSV.


title: HISTORY
content:
<i>scamper</i> was primarily developed at CAIDA (Center for Applied Internet Data Analysis) as a robust and scalable tool for active Internet topology measurement. It evolved from earlier research tools like <i>skitter</i> and <i>capm</i>. Its development has been driven by the need for more accurate, efficient, and parallelizable methods to map the global Internet infrastructure for academic and research purposes. The introduction of its specialized "warts" output format has been a key innovation, enabling the storage and efficient analysis of vast amounts of path-based measurement data.


title: SYNOPSIS
content:
<b>scan-build</b> [<i>scan-build options</i>] &lt;<i>command</i>&gt; [<i>command options/arguments</i>]<br><br><i>Examples:</i><br><b>scan-build make clean all</b><br><b>scan-build -o analysis_results cmake ..</b><br><b>scan-build gcc -c my_file.c</b>


title: PARAMETERS
content:
<b>-o &lt;directory&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output directory for the generated HTML analysis reports. If not provided, a temporary directory is created.<br><br><b>--output &lt;directory&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form alias for <b>-o</b>.<br><br><b>--enable-checker &lt;checker&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables a specific static analysis checker. For example, <i>--enable-checker security.insecureAPI.gets</i>.<br><br><b>--disable-checker &lt;checker&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables a specific static analysis checker that would otherwise be active.<br><br><b>--use-analyzer &lt;analyzer_path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>clang</i> analyzer executable to be used. Useful for custom <i>clang</i> installations.<br><br><b>--view</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically opens the generated HTML analysis report in your default web browser after the analysis completes.<br><br><b>--status-bugs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits with a non-zero status code if any bugs are found during the analysis, useful for CI/CD pipelines.<br><br><b>--analyze-headers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the analyzer to process and report issues found within header files as well, not just source files.<br><br><b>--exclude &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes files or directories from being analyzed. Can be specified multiple times for multiple exclusions.<br><br><b>--html-title &lt;title&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom title for the generated HTML analysis report, visible in the browser tab.<br><br><b>--plist</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs results in the XML Property List (plist) format, typically used for integration with Xcode or other tools.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides more detailed output during the analysis process, showing internal commands and progress.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available <i>scan-build</i> options and exits.<br><br>


title: DESCRIPTION
content:
<i>scan-build</i> is a powerful wrapper script for the <i>Clang Static Analyzer</i>, a tool designed to find bugs in C, C++, and Objective-C programs. Instead of requiring modifications to your build system, <i>scan-build</i> intercepts compiler invocations (like <b>gcc</b> or <b>g++</b>) and replaces them with calls to the static analyzer.<br><br>During the build process, it transparently runs the analysis, identifying potential issues such as null pointer dereferences, memory leaks, uninitialized variables, and use-after-free errors. Once the build completes, <i>scan-build</i> generates an HTML report, organized to easily navigate and examine the detected bugs, including execution paths leading to the defects. This makes it an invaluable tool for improving code quality and reliability early in the development cycle, integrating seamlessly with various build systems like Make, CMake, and Ninja.


title: CAVEATS
content:
<i>scan-build</i> can significantly increase build times, especially for large projects, due to the intensive static analysis performed.<br><br>It may produce false positives, which are reported issues that are not actual bugs, requiring manual review and discernment.<br><br>For comprehensive analysis, a 'clean' build is often necessary (e.g., <b>make clean && scan-build make</b>) to ensure all files are recompiled and thus analyzed.<br><br>While highly effective, it does not guarantee to find all possible bugs; it only detects issues covered by its available checkers. It relies on <i>clang</i> and its static analyzer being correctly installed and accessible.


title: HOW IT WORKS
content:
<i>scan-build</i> operates by temporarily modifying your system's <b>PATH</b> environment variable to prepend a directory containing symlinks or wrapper scripts for common compilers (like <b>gcc</b>, <b>g++</b>, <b>cc</b>). When your build system (e.g., <b>make</b>) invokes a compiler, it actually calls the <i>scan-build</i> wrapper, which then executes the <i>Clang Static Analyzer</i> on the source file before passing control to the real compiler. This clever interception allows it to analyze your code without any changes to your project's build files.


title: TYPES OF BUGS DETECTED
content:
The <i>Clang Static Analyzer</i>, via <i>scan-build</i>, can detect a wide array of bugs categorized into several checkers. These include:<br><i>Memory errors:</i> such as memory leaks, use-after-free, double-free, and uninitialized reads.<br><i>Logic errors:</i> like division by zero, null pointer dereferences, and unreachable code.<br><i>API misuse:</i> including incorrect API usage, security vulnerabilities (e.g., insecure string functions), and resource leaks (e.g., unclosed files or sockets).<br><i>Concurrency issues:</i> for instance, race conditions or deadlocks in multi-threaded code.


title: HISTORY
content:
<i>scan-build</i> is an integral part of the <i>LLVM</i> project's <i>Clang Static Analyzer</i>. The static analyzer project itself originated at <i>Apple Inc.</i> around 2007, with a primary goal of improving the quality and security of Apple's software.<br><br>It was later open-sourced as part of the broader <i>LLVM/Clang</i> initiative, making its powerful capabilities available to the wider development community. <i>scan-build</i> was specifically developed as a user-friendly wrapper script to simplify the integration of the static analyzer into existing build processes, bypassing the need for extensive build system modifications. This approach made static analysis more accessible and practical for everyday development workflows, quickly gaining adoption across various open-source and commercial projects.


title: SYNOPSIS
content:
<B>scancel</B> [<I>OPTIONS</I>] [<I>job_id[_step_id]</I> | <I>job_id.batch</I> | <I>job_id[+]</I> | <I>job_id-job_id</I> | <I>reservation_name</I>] [...]


title: PARAMETERS
content:
<b>-M <I>cluster_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the cluster name for a federated Slurm setup.<br><br><b>-n <I>job_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cancel jobs with the specified name.<br><br><b>-p <I>partition_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cancel jobs associated with the specified partition.<br><br><b>-s <I>signal_name</I> | <I>signal_number</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Send the specified signal to the job or job step instead of the default termination sequence. Signals can be by name (e.g., KILL, TERM) or number.<br><br><b>-t <I>job_state_list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cancel jobs that are currently in one of the specified states (e.g., PENDING, RUNNING, SUSPENDED).<br><br><b>-u <I>user_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cancel jobs belonging to the specified user.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cancel all jobs belonging to the calling user across all accessible clusters.<br><br><b>--batch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with a job ID, cancel only the batch job script itself, not its spawned job steps.<br><br><b>--reservation <I>reservation_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cancel a specific reservation.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt for confirmation before canceling jobs.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more detailed information about the cancellation process.<br><br>


title: DESCRIPTION
content:
<I>scancel</I> is a command-line utility used to terminate or signal jobs, job steps, or reservations managed by the Slurm Workload Manager. It provides a flexible way to remove unwanted jobs from the queue or stop currently running processes. By default, <I>scancel</I> sends a <B>SIGTERM</B> signal to the job or job step, followed by a <B>SIGKILL</B> signal after a configurable timeout (typically 30 seconds if the job doesn't exit gracefully). This two-phase termination allows applications to perform cleanup operations before being forcibly killed. Users can specify jobs by ID, user, name, partition, or state. It's an essential tool for managing computational resources in a Slurm cluster, enabling administrators and users to maintain system stability and resource availability.


title: CAVEATS
content:
<B>Permissions:</B> Users can only cancel their own jobs or reservations. Slurm administrators (e.g., root or users with <I>SlurmUser</I> privileges) can cancel any job or reservation.<BR><B>Signal Handling:</B> While <I>scancel</I> defaults to <B>SIGTERM</B> then <B>SIGKILL</B>, applications can catch <B>SIGTERM</B> to perform graceful shutdowns. If an application does not handle <B>SIGTERM</B> or fails to exit, <B>SIGKILL</B> will forcibly terminate it.<BR><B>Targeting:</B> Be precise when specifying job IDs. <I>job_id</I> cancels the entire job, <I>job_id_step_id</I> targets a specific job step, and <I>job_id.batch</I> cancels only the batch script itself. Using options like <B>-u</B> or <B>-n</B> can affect multiple jobs.


title: DEFAULT TERMINATION BEHAVIOR
content:
When no signal is specified, <I>scancel</I> first sends <B>SIGTERM</B> to allow for graceful shutdown. If the job or step does not terminate within the configured <I>KillWait</I> (default 30 seconds), a <B>SIGKILL</B> signal is sent to forcibly terminate it.


title: CANCELING JOB STEPS
content:
To cancel only a specific job step (e.g., a process launched by <I>srun</I> within a batch job), specify the job ID followed by an underscore and the step ID (e.g., <I>scancel 12345_0</I>). Omitting the step ID cancels the entire job, including all its running steps.


title: HISTORY
content:
<I>scancel</I> is a fundamental command within the Slurm Workload Manager suite, which began its development in the early 2000s at Lawrence Livermore National Laboratory. As Slurm evolved into one of the most widely adopted workload managers in high-performance computing (HPC), <I>scancel</I> has remained a core utility. Its design reflects the need for robust and flexible job control in large-scale cluster environments, allowing for precise termination of computational tasks and efficient resource management. Subsequent versions of Slurm have incrementally improved its capabilities, particularly in handling federated clusters and more complex job structures.


title: PARAMETERS
content:
<b><b>-L</b>, <b>--list-devices</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available scanner devices detected by SANE.<br><br><b><b>-d</b> <I>device</I>, <b>--device-name</b> <I>device</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific scanner device to use. The device name can be found using <b>--list-devices</b>.<br><br><b><b>--format</b> <I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output image format. Common formats include 'pnm' (default) and 'tiff'.<br><br><b><b>-o</b> <I>file</I>, <b>--output-file</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the acquired image data directly to the specified file instead of standard output.<br><br><b><b>--resolution</b> <I>dpi</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the scanning resolution in dots per inch (DPI). Common values are 100, 200, 300, 600.<br><br><b><b>--mode</b> <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the scan mode. Possible values often include 'Lineart' (black and white), 'Gray' (grayscale), and 'Color'.<br><br><b><b>--source</b> <I>source</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the scan input source, such as 'Flatbed', 'ADF' (Automatic Document Feeder), or 'Transparency.<br><br><b><b>--brightness</b> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the brightness level of the scan. The range of values is device-dependent.<br><br><b><b>--contrast</b> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the contrast level of the scan. The range of values is device-dependent.<br><br><b><b>-x</b> <I>width</I>, <b>-y</b> <I>height</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the width and height of the scan area in millimeters.<br><br><b><b>-l</b> <I>left</I>, <b>-t</b> <I>top</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the top-left corner coordinates (X and Y) of the scan area in millimeters.<br><br><b><b>--batch</b>[=<I>format</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables batch scanning mode, useful for ADF. Optionally specify output format, e.g., 'scanimage --batch=scan_%03d.pnm'.<br><br><b><b>--batch-start</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the starting number for batch scan filenames.<br><br><b><b>--batch-count</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the total number of images to scan in batch mode.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a general help message and basic options.<br><br><b><b>-A</b>, <b>--advanced-options</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all advanced and device-specific options available for the selected scanner.<br><br>


title: DESCRIPTION
content:
<b>scanimage</b> is a command-line program designed to control image acquisition devices such as flatbed scanners, handheld scanners, and video cameras. It serves as the official command-line interface for the <b>SANE</b> (Scanner Access Now Easy) project, providing a standardized way to access various scanning hardware on Unix-like operating systems.<br><br>This utility enables users to scan documents or images directly from the terminal, making it highly suitable for scripting, automation, and batch processing tasks. It supports various image formats, primarily <b>PNM</b> (PBM, PGM, PPM) and <b>TIFF</b>, and outputs the acquired image data to standard output, which is typically redirected to a file.<br><br><b>scanimage</b> offers a comprehensive set of options to control scanning parameters like resolution, color mode (lineart, grayscale, color), scan area, brightness, and contrast. The availability of these options largely depends on the capabilities of the specific scanner and its corresponding SANE backend driver.


title: CAVEATS
content:
<b>scanimage</b>'s functionality is entirely dependent on the presence and proper configuration of <b>SANE</b> backends (drivers) for your specific scanner model. If a backend is not available or not correctly configured (e.g., in <i>/etc/sane.d/</i>), <b>scanimage</b> will not be able to detect or operate the scanner.<br><br>Users often need appropriate permissions (e.g., membership in the 'scanner' group or correct udev rules) to access the scanner device directly. Without proper permissions, the command may report 'Permission denied' errors.<br><br>By default, <b>scanimage</b> writes image data to standard output. For saving to a file, output redirection (e.g., <code>&gt; image.pnm</code>) or the <b>--output-file</b> option is necessary.


title: DEVICE-SPECIFIC OPTIONS
content:
Many options available with <b>scanimage</b> are not universal but are specific to the selected scanner device and its <b>SANE</b> backend. To see a complete list of options for your particular scanner, use the command: <code>scanimage <b>-d</b> <I>your_device_name</I> <b>--help</b></code> or <code>scanimage <b>-d</b> <I>your_device_name</I> <b>-A</b></code>. This will display all adjustable parameters, including resolution ranges, available modes, and unique features of your hardware.


title: EXIT STATUS AND ERROR HANDLING
content:
<b>scanimage</b> typically exits with a status code of 0 upon successful completion. A non-zero exit status indicates an error during the scanning process (e.g., device not found, permission issues, or scanning failure). Diagnostic messages are usually printed to standard error (stderr) to provide more details about the problem, which can be useful for debugging automated scripts.


title: HISTORY
content:
<b>scanimage</b> is a foundational component of the <b>SANE</b> (Scanner Access Now Easy) project, which commenced in 1996. The project's genesis was to establish a standardized application programming interface (API) for accessing diverse image acquisition devices, thereby bridging the gap in scanner support on Unix-like operating systems compared to proprietary OS counterparts.<br><br>As the primary command-line tool, <b>scanimage</b> has consistently served as a testament to the versatility of the SANE backend architecture. Its evolution is intrinsically linked to the broader SANE objective of fostering universal scanner compatibility through community-driven, open-source driver development.


title: SYNOPSIS
content:
<b>scapy</b> [<i>options</i>] [<i>arguments</i>]<br><br>Typically, invoking <b>scapy</b> without options launches its interactive Python shell. Options allow for direct command execution, script execution, or reading PCAP files upon startup.


title: PARAMETERS
content:
<b><b>-r</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads packets from the specified PCAP (Packet Capture) file at startup.<br><br><b><b>-s</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified Python script file containing <i>Scapy</i> commands upon startup.<br><br><b><b>-c</b> <i>&lt;command(s)&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the given <i>Scapy</i> command(s) directly from the command line, without entering the interactive shell. Multiple commands can be separated by semicolons.<br><br><b><b>-i</b> <i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts sniffing packets on the specified network interface upon startup. This can be combined with other options like <b>-c</b>.<br><br><b><b>-p</b> <i>&lt;program&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a specific <i>Scapy</i> program or tool (e.g., 'traceroute', 'nmap', 'arpscan').<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in quiet mode, suppressing most informational messages and banners.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, providing more detailed output during operations.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits, showing available command-line options.<br><br>


title: DESCRIPTION
content:
<i>Scapy</i> is a powerful interactive packet manipulation program and library written in Python. It allows users to create, send, sniff, and decode network packets at various layers of the OSI model. Its flexibility makes it an invaluable tool for network discovery, security auditing, unit testing, penetration testing, and network development.<br><br>Unlike traditional sniffers or packet generators, <i>Scapy</i> provides a high degree of control over individual packet fields and layers, enabling the crafting of malformed packets, custom protocol implementation, and sophisticated network attacks or defenses. It can handle a wide array of protocols, from Ethernet and IP to higher-level protocols like HTTP, DNS, and more. Being Python-based, it easily integrates into larger scripts and automation workflows, offering a programmatic approach to network interaction and analysis.


title: CAVEATS
content:
<b>Root Privileges:</b> Many network operations, such as raw socket creation, packet sniffing, and injection, require root or elevated user privileges (e.g., using <b>sudo</b>) to function correctly.<br><br><b>Python Dependency:</b> <i>Scapy</i> is a Python library and requires a compatible Python environment (Python 3.x is recommended) along with necessary dependencies to be installed.<br><br><b>Learning Curve:</b> While powerful, mastering <i>Scapy</i> requires a foundational understanding of network protocols and Python programming, especially for complex packet crafting and analysis tasks.


title: INTERACTIVE SHELL
content:
When invoked without specific options, <i>Scapy</i> launches an interactive Python shell. This allows users to dynamically craft, send, and analyze packets using Python syntax, providing immediate feedback and a powerful environment for experimentation and debugging.


title: PYTHON LIBRARY
content:
Beyond its command-line utility, <i>Scapy</i> is primarily a powerful Python library. It can be imported into any Python script, enabling the automation of complex network tasks, integration into larger testing frameworks, and development of custom network utilities.


title: PACKET LAYERS AND PROTOCOLS
content:
<i>Scapy</i> provides an intuitive way to interact with various layers of the OSI model. Users can easily build packets layer by layer (e.g., Ethernet / IP / TCP / Raw), modify fields at any layer, and extend its functionality to support new or custom protocols. This deep-level control is one of its most significant strengths.


title: HISTORY
content:
<i>Scapy</i> was created by Philippe Biondi and first released around 2003-2004. Its development aimed to provide a more flexible and interactive alternative to existing packet manipulation tools. From its inception, <i>Scapy</i> stood out due to its deep integration with Python, allowing users to leverage the language's power for complex network tasks. Over the years, it has continuously evolved with contributions from a vibrant community, adding support for new protocols and expanding its capabilities, solidifying its position as a go-to tool for network security and analysis professionals.


title: SYNOPSIS
content:
scc <i>[OPTIONS]</i> <i>[PATH...]</i><br><br><i>PATH</i> specifies the directories or files to analyze. If no path is provided, <i>scc</i> processes the current directory.


title: PARAMETERS
content:
<b>--by-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display results for each individual file.<br><br><b>-c, --config <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom configuration file.<br><br><b>--count-as <lang></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat files as if they belong to a specific language.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose debug output.<br><br><b>-e, --exclude <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching the given pattern.<br><br><b>-f, --format <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output format (e.g., <b>plain</b>, <b>json</b>, <b>csv</b>, <b>html</b>).<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br><b>-i, --include <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include files or directories matching the given pattern.<br><br><b>-l, --languages</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all supported programming languages.<br><br><b>--no-group</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not group results by language.<br><br><b>--no-gitignore</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore .gitignore files when scanning.<br><br><b>-o, --output <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the command output to a specified file.<br><br><b>-s, --sort <field></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort results by a specific field (e.g., <b>lines</b>, <b>code</b>, <b>comments</b>, <b>blanks</b>).<br><br><b>-t, --top <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the output to the top N languages or files.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of <i>scc</i> and exit.<br><br>


title: DESCRIPTION
content:
<i>scc</i> (Source Code Count) is a powerful, fast command-line utility designed for accurately counting source code lines across a multitude of programming languages. It meticulously categorizes lines into code, blank, and comment lines, providing valuable insights into codebase size and complexity. Built with performance in mind using Go, <i>scc</i> efficiently processes large projects, offering various output formats like plain text, JSON, and CSV. It serves as an essential tool for developers, project managers, and auditors needing to quickly assess software projects. Its extensive language support and configurable options make it highly adaptable to diverse development environments.


title: CAVEATS
content:
<i>scc</i> is not a standard utility pre-installed on most Linux distributions; it usually requires manual installation. While highly accurate, the parsing of complex or custom language constructs might occasionally lead to minor discrepancies. Its performance benefits are most noticeable on large codebases due to its concurrent design.


title: INSTALLATION
content:
<i>scc</i> can typically be installed via Go's package manager (e.g., <b>go install github.com/boyter/scc/v3@latest</b>) or, less commonly, through distribution-specific repositories.


title: PERFORMANCE
content:
Renowned for its exceptional speed, <i>scc</i> leverages Go's concurrency features to efficiently scan and analyze large code repositories, often outperforming similar tools.


title: HISTORY
content:
<i>scc</i> emerged as a modern, Go-language based alternative to older code counting tools. Its development by Ben Boyter focused on achieving significantly faster performance and broader language support, aiming to provide a robust solution for large-scale code analysis.


title: SYNOPSIS
content:
<b>sccmap</b> [<i>options</i>]<br><b>sccmap</b> [<b>-a</b>|<b>-d</b>|<b>-l</b>] [<b>-f</b> <i>config_file</i>] [<b>-n</b> <i>slot_number</i>] [<b>-r</b> <i>reader_name</i>] [<b>-v</b>] [<b>-?</b>]


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a new reader mapping. This option typically requires specifying both a <b>-n</b> (slot number) and a <b>-r</b> (reader name).<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete an existing reader mapping. This option requires specifying either a <b>-n</b> (slot number) or a <b>-r</b> (reader name) to identify the mapping to be deleted.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all currently configured reader mappings. This provides an overview of how physical readers are assigned to logical slots.<br><br><b><b>-f</b> <i>config_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative configuration file path. By default, <i>sccmap</i> uses a standard OpenCT configuration file, often located in <i>/etc/openct/</i> or <i>/etc/</i>.<br><br><b><b>-n</b> <i>slot_number</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The logical slot number (typically 0-indexed) to which a reader is mapped or from which a mapping is deleted. Used with <b>-a</b> or <b>-d</b>.<br><br><b><b>-r</b> <i>reader_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The physical name of the smart card reader as detected by the system. Used with <b>-a</b> or <b>-d</b> to specify which reader to map or unmap.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, providing more detailed information about the operation being performed.<br><br><b><b>-?</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit, showing common usage options.<br><br>


title: DESCRIPTION
content:
<i>sccmap</i> is a utility from the OpenCT (OpenCard Framework Toolkit) project used to manage and configure how smart card readers are presented and mapped within the <i>scc</i> (Smart Card Connector) daemon.<br><br>It allows administrators to define logical slots for physical readers, enabling specific reader configurations, assigning particular readers to fixed slot numbers, or even disabling certain readers. This is particularly useful in environments with multiple smart card readers, where applications might expect readers at specific slot indices, or where fine-grained control over reader visibility and behavior is required. Changes made with <i>sccmap</i> typically affect the <i>scc</i> daemon's operational behavior and persist through configuration files.


title: CAVEATS
content:
Using <i>sccmap</i> typically requires root privileges to modify system-wide configuration files.<br><br>Changes made to reader mappings usually require restarting the <i>scc</i> daemon for them to take effect. <i>sccmap</i> configures the OpenCT-specific <i>scc</i> daemon, not the more common PCSC-Lite <i>pcscd</i> daemon, though both handle smart card access.


title: CONFIGURATION FILES
content:
<i>sccmap</i> primarily interacts with the <i>scc.conf</i> configuration file, typically located in <i>/etc/openct/</i> or <i>/etc/</i>. This file stores the persistent mapping definitions that the <i>scc</i> daemon reads upon startup. Users should be cautious when manually editing this file, as <i>sccmap</i> provides a safer, programmatic interface for modifications.


title: DAEMON INTERACTION
content:
For changes to take effect, the <i>scc</i> daemon must typically be restarted after running <i>sccmap</i>. This ensures that the daemon re-reads its configuration and applies the new reader mappings.


title: HISTORY
content:
<i>sccmap</i> is a component of the OpenCT (OpenCard Framework Toolkit) project, which provides a framework for smart card readers and smart cards under Linux. OpenCT was developed to offer a unified interface for various smart card readers, especially before PCSC-Lite became the predominant standard for smart card access on Linux.<br><br><i>sccmap</i> specifically addresses the configuration needs for the <i>scc</i> daemon within this framework, allowing for flexible management of reader resources. Its usage has become less common as <i>pcscd</i> has gained wider adoption, but it remains relevant in systems specifically utilizing the OpenCT stack.


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the scdaemon version information.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a comprehensive help message and exit.<br><br><b>--server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in server mode, typically for client communication.<br><br><b>--daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run scdaemon in the background as a daemon process.<br><br><b>--multi-server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow multiple clients to connect when in server mode.<br><br><b>--homedir <I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GnuPG home directory for configuration files.<br><br><b>--reader-port <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which smart card reader port to use (0, 1, etc.).<br><br><b>--disable-locking</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable file locking for specific operations (use with caution).<br><br><b>--list-hotplug-devices</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List detected hotplug smart card devices.<br><br>


title: DESCRIPTION
content:
The command 'scd' is not a standard, standalone executable commonly found in most Linux distributions. However, it is often used as a colloquial or shorthand reference for <B>scdaemon</B>, the Smart Card Daemon, which is an integral component of the GnuPG (GNU Privacy Guard) suite. <BR><BR><B>scdaemon</B> serves as an intermediary between GnuPG applications (such as <I>gpg-agent</I>) and physical smart card readers, along with the smart cards themselves. Its primary function is to manage the low-level communication protocols required to perform cryptographic operations directly on the smart card, including digital signing, decryption, and user authentication. It abstracts the complexities of various smart card types, like OpenPGP cards, providing a unified interface for GnuPG. While typically running as a background daemon managed by <I>gpg-agent</I>, it can be manually invoked for diagnostic purposes or specific smart card management tasks. It plays a crucial role in enhancing the security of cryptographic keys by enabling them to reside on tamper-resistant hardware.


title: CAVEATS
content:
The command <I>scd</I> is not a standard, general-purpose Linux command. This analysis focuses on <B>scdaemon</B>, a GnuPG component commonly referenced as <I>scd</I>.<BR>It requires the GnuPG suite to be installed and typically relies on a functional smart card reader and compatible smart card hardware.<BR>Usually, <B>scdaemon</B> runs implicitly in the background, managed by <I>gpg-agent</I>; direct manual invocation is primarily for diagnostics or advanced administration.


title: INTEGRATION WITH GNUPG AGENT
content:
<B>scdaemon</B> rarely needs direct user interaction as it's primarily managed by <I>gpg-agent</I>, handling smart card communications transparently on behalf of GnuPG applications.


title: RELIANCE ON PC/SC
content:
For low-level communication with smart card readers, <B>scdaemon</B> often depends on the PC/SC Lite daemon (<I>pcscd</I>), which provides a standardized interface for accessing card readers.


title: OPENPGP CARD SUPPORT
content:
It specifically supports smart cards compliant with the OpenPGP Card specification, allowing cryptographic keys to be securely stored on and used from a physical smart card.


title: HISTORY
content:
Part of the GnuPG project, <B>scdaemon</B> was developed to integrate smart card support for cryptographic operations. Its evolution closely tracks GnuPG's development and advancements in smart card technology, enabling secure key storage on hardware tokens.


title: PARAMETERS
content:
<b>FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a Scheme source <I>file</I> to be executed. The interpreter will typically read and run the code in this file.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the interpreter in interactive mode (REPL) after processing any specified files or expressions. This is often the default if no file or expression is provided.<br><br><b>-e <expression>, --eval <expression></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluates the given Scheme <I>expression</I> directly from the command line. This is useful for short, one-off computations or for passing data to a script.<br><br><b>-l <file>, --load <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads and executes the specified Scheme <I>file</I>. This can be used to load libraries or define functions before running other code or entering the REPL.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the Scheme interpreter.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options and usage information.<br><br><b>-- <arguments...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to separate command-line options from arguments that should be passed directly to the Scheme program being executed. Arguments after '--' are typically accessible by the Scheme script.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses startup messages and banners, leading to a quieter execution environment.<br><br>


title: DESCRIPTION
content:
The <b>scheme</b> command typically refers to an executable for a <I>Scheme interpreter</I>, a program that executes code written in the <b>Scheme programming language</b>. Scheme is a dialect of Lisp, known for its minimalist design, powerful expressiveness, and emphasis on functional programming paradigms. While there isn't a single universal "scheme" command installed by default on all Linux distributions, this name often serves as a symbolic link or a common choice for a specific Scheme implementation (e.g., Guile, Racket, MIT/GNU Scheme, Chicken Scheme) to provide a generic entry point.<br><br>When invoked, the <b>scheme</b> command can be used in several ways: to run a Scheme script from a file, to evaluate a single Scheme expression directly from the command line, or to enter an <I>interactive Read-Eval-Print Loop</I> (REPL). In a REPL, users can type Scheme expressions and see their results immediately, making it an excellent environment for experimenting with the language, debugging, and interactive development. The exact features, command-line options, and behavior depend heavily on the specific Scheme interpreter installed and invoked.


title: CAVEATS
content:
The specific `scheme` command and its available options are highly dependent on which Scheme interpreter is installed on the system (e.g., Guile, Racket, MIT/GNU Scheme, Chicken Scheme). Some systems may not have a generic `scheme` executable at all, requiring the user to invoke the specific interpreter directly (e.g., `guile`, `racket`). Functionality and adherence to the Scheme standard (R<SUB>n</SUB>RS) can vary between implementations.


title: INTERACTIVE REPL
content:
When run without arguments or with an explicit interactive flag, the Scheme interpreter enters a <I>Read-Eval-Print Loop</I> (REPL). This allows users to type Scheme expressions directly, have them evaluated, and see the results immediately. It's an essential tool for exploratory programming, quick tests, and debugging.


title: SCRIPT EXECUTION
content:
Scheme files (often with a `.scm` or `.ss` extension) can be made executable using a <I>shebang</I> line (e.g., `#!/usr/bin/env scheme` or `#!/usr/bin/guile`) at the top of the script. This allows them to be run directly like other shell scripts, making Scheme a viable language for system scripting tasks.


title: LANGUAGE FEATURES
content:
Scheme is known for its powerful features like <I>first-class functions</I> (functions that can be passed as arguments, returned from other functions, and assigned to variables), <I>continuations</I> (representing the entire future of a computation), and a robust <I>macro system</I> for extending the language itself. It adheres to a strict standard, ensuring portability across different implementations to a degree.


title: HISTORY
content:
Scheme was created by Guy L. Steele Jr. and Gerald Jay Sussman in 1975, primarily as a vehicle for studying various theoretical aspects of programming languages. It was the first dialect of Lisp to introduce lexical scoping and continuations, which are now common features in many programming languages. Its design principles emphasize simplicity and elegance, making it an influential language in computer science education and research. While various implementations have existed over the decades, a common `scheme` command on Linux typically emerged from users creating symbolic links to their preferred interpreter, rather than a single, universally adopted `scheme` binary. The standardization of Scheme itself is managed by a series of 'Revised<SUB>n</SUB> Report on the Algorithmic Language Scheme' (R<SUB>n</SUB>RS) documents, with R7RS being the latest.


title: SYNOPSIS
content:
<b>schroot</b> [<i>OPTIONS</i>] <b>-c</b> <<i>chroot</i>> [<i>COMMAND</i> [<i>ARGUMENTS</i>]]<br><b>schroot</b> [<i>OPTIONS</i>] <b>-l</b><br><b>schroot</b> [<i>OPTIONS</i>] <b>-i</b> <<i>session</i>><br><b>schroot</b> [<i>OPTIONS</i>] <b>-e</b> <<i>session</i>> <b>--</b> [<i>COMMAND</i> [<i>ARGUMENTS</i>]]


title: PARAMETERS
content:
<b><b>-c</b>, <b>--chroot</b> <<i>chroot</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the chroot environment to enter or operate on.<br><br><b><b>-d</b>, <b>--directory</b> <<i>path</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Change to the specified directory inside the chroot after entering it.<br><br><b><b>-u</b>, <b>--user</b> <<i>user</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute the command or shell as a different user inside the chroot.<br><br><b><b>-p</b>, <b>--preserve-environment</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserve the current environment variables from the host system inside the chroot.<br><br><b><b>-r</b>, <b>--run-session</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run an interactive login shell inside the chroot. This is the default if no command is specified.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available chroots defined in the configuration file.<br><br><b><b>-i</b>, <b>--info</b> <<i>session</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed information about a specific active session.<br><br><b><b>-e</b>, <b>--end-session</b> <<i>session</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;End an active schroot session, performing any configured cleanup actions.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most informational messages and warnings.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show verbose output, useful for debugging.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<b>schroot</b> provides a secure way to execute commands or a login shell within a chrooted environment. Unlike the standard <b>chroot</b> command, <b>schroot</b> is designed to be used by unprivileged users, managing the complex setup required for a usable chroot, such as mounting filesystems (proc, sys, dev), handling user ID mapping, and optionally setting up network access.<br><br>It relies on a configuration file, typically <i>/etc/schroot/schroot.conf</i>, to define various chroot environments, specifying their paths, types, and setup scripts. This allows system administrators to pre-configure safe and isolated environments for developers, testers, or users to build, test, or run software without affecting the host system. It promotes isolation, reproducibility, and security by containing operations within a defined filesystem hierarchy.


title: CAVEATS
content:
<ul><li><b>Configuration Dependency</b>: Requires a correctly configured <i>/etc/schroot/schroot.conf</i> file, which defines the available chroots and their settings. Incorrect configurations can lead to security vulnerabilities or usability issues.</li><li><b>Security Model</b>: While <b>schroot</b> aims to improve security over bare <b>chroot</b>, it's not a full-fledged containerization solution (like Docker). A compromised chroot might still find ways to affect the host system if not properly configured.</li><li><b>Root Privileges for Setup</b>: Initial chroot setup and configuration of <i>schroot.conf</i> still require root privileges.</li></ul>


title: CONFIGURATION FILE (SCHROOT.CONF)
content:
<b>schroot</b> relies heavily on its configuration file, typically located at <i>/etc/schroot/schroot.conf</i> (or in <i>/etc/schroot/chroot.d/</i> for modular configurations). This file defines the various chroot environments, their paths, types (e.g., <i>directory</i>, <i>plain</i>, <i>lvm</i>, <i>loopback</i>), and scripts to run before and after entering/exiting the chroot. Understanding this file is fundamental to using <b>schroot</b> effectively.


title: SESSION MANAGEMENT
content:
<b>schroot</b> supports session management, allowing multiple commands to be run within the same chroot environment without re-initializing it for each command. Sessions are created implicitly when you enter a chroot and can be explicitly ended with the <b>-e</b> option. This significantly speeds up operations that involve multiple steps inside a single chroot.


title: HISTORY
content:
<b>schroot</b> was developed to address the limitations and security concerns of directly using the <b>chroot(1)</b> command, particularly for unprivileged users. It aimed to simplify the process of setting up and entering chroot environments by handling the necessary bind mounts, device node creation, and user/group ID mapping automatically based on pre-defined configurations. It became a popular tool in Debian and Ubuntu for reproducible build environments, especially for <b>sbuild</b> (source package builder), allowing developers to build packages for different distributions or architectures without installing them on the host system, thus ensuring build reproducibility and isolation.


title: SYNOPSIS
content:
<i>scontrol</i> provides a general syntax but operates primarily through subcommands.<br><b>scontrol</b> [<i>OPTIONS</i>...] &lt;<i>COMMAND</i>&gt; [<i>COMMAND_OPTIONS</i>...] [<i>ARGUMENTS</i>...]<br>Examples of common commands include <i>show</i>, <i>update</i>, <i>hold</i>, <i>release</i>, <i>reconfigure</i>, etc.


title: PARAMETERS
content:
<b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message for <i>scontrol</i> or a specific subcommand.<br><br><b><i>-V</i>, <i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information.<br><br><b><i>-Q</i>, <i>--quiet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print informational messages, only error messages.<br><br><b><i>-M</i>, <i>--clusters=&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clusters to issue commands to (for federated clusters).<br><br><b><i>-d</i>, <i>--debug</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce more detailed output.<br><br><b><i>show &lt;object&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about various Slurm objects (e.g., <i>show node</i>, <i>show job</i>, <i>show part</i>).<br><br><b><i>update &lt;object&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modify the state of Slurm objects (e.g., <i>update node</i>, <i>update job</i>, <i>update reservation</i>).<br><br><b><i>hold &lt;jobid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Place a job or a set of jobs in a held state.<br><br><b><i>release &lt;jobid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Release a held job or set of jobs.<br><br><b><i>reconfigure</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <i>slurmctld</i> and <i>slurmd</i> daemons to re-read their configuration files.<br><br><b><i>drain &lt;node_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a node's state to DRAIN, preventing new jobs.<br><br><b><i>resume &lt;node_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a node's state to RESUME (opposite of DRAIN), allowing new jobs.<br><br>


title: DESCRIPTION
content:
<i>scontrol</i> is a powerful command-line utility used to view and modify the state of the Slurm Workload Manager. It allows administrators and privileged users to inspect various Slurm objects such as nodes, partitions, jobs, steps, and reservations. Furthermore, <i>scontrol</i> can be used to update object states (e.g., drain a node, hold a job, create a reservation) or reconfigure Slurm components dynamically. It serves as a primary interface for fine-grained control over the Slurm cluster, essential for cluster management and troubleshooting.


title: CAVEATS
content:
<i>scontrol</i> requires appropriate user permissions (often root or Slurm administrator privileges) to modify cluster state. Misuse can disrupt cluster operations or affect running jobs. Its output format can be verbose and sometimes requires parsing for scripting purposes, though <i>--json</i> option is available in newer versions for specific subcommands.


title: INTERACTIVE VS. SCRIPTING USE
content:
<i>scontrol</i> is used both interactively by administrators for immediate cluster management tasks and within scripts for automated operations like node maintenance, job management, or cluster health checks.


title: OUTPUT FORMATS
content:
While its default output is human-readable, many <i>scontrol show</i> commands support <i>--json</i> for programmatic parsing, providing structured data for automation.


title: PERMISSIONS
content:
Most <i>scontrol</i> modification commands require administrator (SlurmUser, root, or specific privileges) permissions to execute, while <i>show</i> commands can often be run by any user to query public information.


title: HISTORY
content:
<i>scontrol</i> is an integral part of the Slurm Workload Manager, which originated in 2002 at Lawrence Livermore National Laboratory (LLNL) as a free, open-source cluster management and job scheduling system. It was designed to provide a highly scalable and fault-tolerant alternative to existing proprietary solutions. <i>scontrol</i> has continuously evolved with Slurm, adding new functionalities and improving its command-line interface to manage increasingly complex cluster environments and features like federated clusters and burst buffering. Its development focuses on robust control and monitoring capabilities for high-performance computing (HPC) clusters.


title: SYNOPSIS
content:
<b>scp</b> [<I>options</I>] <I>[[user@]host1:]file1</I> <I>[[user@]host2:]file2</I><br><b>scp</b> [<I>options</I>] <I>[[user@]host:]source_file</I> <I>[[user@]host:]destination_directory</I><br><b>scp</b> [<I>options</I>] <I>source_file1</I> <I>source_file2</I> <I>[[user@]host:]destination_directory</I>


title: PARAMETERS
content:
<b>-P <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port to connect on the remote host. Note the uppercase 'P' for port.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively copy entire directories and their contents.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves modification times, access times, and modes of the source file(s).<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables quiet mode, suppressing the progress meter and non-error messages.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose mode, printing debugging messages about the connection and transfer.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables compression during the transfer.<br><br><b>-i <identity_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a file from which the identity (private key) for public key authentication is read.<br><br><b>-o <ssh_option></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Can be used to pass options directly to the underlying SSH client.<br><br><b>-l <limit></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the bandwidth used, specified in Kilobits per second (Kbit/s).<br><br><b>-B</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables batch mode, preventing any interactive questions or prompts (e.g., for passwords).<br><br>


title: DESCRIPTION
content:
<b>scp</b> (secure copy) is a command-line utility that allows you to securely copy files and directories between local and remote hosts, or between two remote hosts. It utilizes the Secure Shell (SSH) protocol for data transfer, ensuring that the data is encrypted during transit and that authentication is secure. This makes <b>scp</b> a reliable method for transferring sensitive information over unsecured networks. It supports various authentication methods, including password-based and public-key authentication, inherited from SSH. <b>scp</b> is widely used for simple, one-time file transfers due to its straightforward syntax and integration with existing SSH infrastructure. While newer tools like <b>rsync</b> and <b>sftp</b> offer more advanced features (e.g., resuming transfers, incremental copies), <b>scp</b> remains a fundamental tool for many system administrators and developers.


title: CAVEATS
content:
<b>scp</b> does not inherently support resuming interrupted transfers, meaning large file transfers might need to be restarted from scratch if the connection drops.<br>When copying files directly between two remote hosts (e.g., `host1:file host2:file`), the data typically traverses through the local machine where the <b>scp</b> command is executed, which can be inefficient for very large files or high-latency connections. For more advanced features like incremental transfers, resuming, or better handling of large directory structures, tools like <b>rsync</b> or <b>sftp</b> are generally recommended. Recent versions of OpenSSH have also shifted focus towards recommending <b>sftp</b> or <b>rsync</b> over <b>scp</b> due to <b>scp</b>'s limited feature set and security considerations with parsing paths.


title: AUTHENTICATION
content:
<b>scp</b> relies on SSH for authentication, supporting various methods including password-based authentication, public-key authentication (using SSH keys), and other methods configured for SSH.


title: DATA FLOW FOR REMOTE-TO-REMOTE
content:
When copying files between two remote hosts (e.g., `host1:file host2:file`), the data typically flows through the local machine where the <b>scp</b> command is initiated. This means the local machine acts as an intermediary, downloading from the source and uploading to the destination, which might impact performance on high-latency networks.


title: HISTORY
content:
<b>scp</b> originated as the secure counterpart to the older, insecure <b>rcp</b> (remote copy) command, leveraging the robust security features of the Secure Shell (SSH) protocol. It became an integral part of the OpenSSH suite, widely adopted as the standard for secure file transfers over networks. While its core functionality remained consistent for many years, recent developments in OpenSSH (starting around version 8.0) have transitioned <b>scp</b> to use an <b>sftp</b> backend by default. This change aims to improve <b>scp</b>'s reliability and security by utilizing the more structured SFTP protocol for data transfer and path handling, though it may introduce subtle behavioral changes for some edge cases.


title: PARAMETERS
content:
<b>startproject <i>&lt;project_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new Scrapy project with a basic directory structure and configuration files. This is usually the first command used when starting a new scraping task.<br><br><b>genspider <i>&lt;name&gt; &lt;domain&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new spider file inside the current Scrapy project. Spiders define how to crawl a site and extract data, specifying start URLs and parsing rules.<br><br><b>crawl <i>&lt;spider_name&gt;</i> [<i>-o output_file</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the crawling process using a specific spider defined within the project. It's the primary command to run your scraper and collect data. Output can be saved to various formats.<br><br><b>shell [<i>&lt;url&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens an interactive Scrapy shell, which is a powerful tool for testing and debugging your XPath or CSS selectors on specific URLs directly, without running the entire spider.<br><br><b>parse <i>&lt;url&gt;</i> [<i>--spider=spider_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches a given URL and parses it with the specified spider (or a dummy spider if none is given), showing how the items would be extracted. Useful for debugging parsing logic.<br><br><b>settings [<i>--get=setting_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Scrapy settings for the current project. Can be used to inspect individual setting values or all configured settings.<br><br><b>runspider <i>&lt;file.py&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a spider defined in a single Python file, without needing to create a full Scrapy project. Useful for quick, standalone scraping scripts.<br><br><b>version [<i>-v</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Scrapy version. The <i>-v</i> option provides more verbose information, including Python, Twisted, and lxml versions.<br><br><b>bench</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a quick benchmark test to check Scrapy's performance on your system, measuring request/response processing speed.<br><br>


title: DESCRIPTION
content:
Scrapy is an open-source web crawling framework written in Python. It provides a fast and powerful way to extract data from websites, process it, and store it in various formats. Built on an asynchronous architecture (Twisted), it efficiently handles numerous concurrent requests, making it suitable for large-scale data extraction tasks. Scrapy offers built-in functionalities for managing cookies, handling user agents, respecting robots.txt, and navigating complex website structures. Its extensible design, through middlewares, pipelines, and extensions, allows developers to tailor the scraping process to specific needs, making it a versatile tool for data mining, content aggregation, and automated testing.


title: CAVEATS
content:
Scrapy is a Python framework, not a native Linux command in the traditional sense; it's invoked via the Python environment. It requires Python 3.7+ and pip for installation. Large-scale crawling can be resource-intensive and may require careful management of system resources and network bandwidth. Websites may implement anti-bot measures, leading to IP blocking or CAPTCHAs, which require advanced handling strategies.


title: INSTALLATION
content:
Scrapy is installed using pip, the Python package installer. The command is: <br> <i>pip install scrapy</i> <br> It's recommended to install it within a Python virtual environment to manage dependencies.


title: PROJECT STRUCTURE
content:
A Scrapy project typically consists of multiple components: <b>spiders</b> (defining the crawling logic), <b>items</b> (structured data containers), <b>pipelines</b> (for processing scraped items), and <b>settings.py</b> (for project-wide configuration). The <i>startproject</i> command sets up this basic structure.


title: EXTENSIBILITY
content:
Scrapy offers numerous extension points for customization: <br> - <b>Item Pipelines</b>: Process items once they are scraped. <br> - <b>Downloader Middleware</b>: Process requests and responses passing through the downloader. <br> - <b>Spider Middleware</b>: Process requests and items passing through the spider. <br> - <b>Extensions</b>: Implement custom functionality to hook into Scrapy's core.


title: HISTORY
content:
Scrapy was initially released in 2008 by Scrapinghub (now Zyte), a company specializing in web scraping. It emerged from the need for a robust, flexible, and scalable framework for complex web data extraction projects. Built upon the Twisted asynchronous networking library, it was designed to handle high concurrency efficiently. Over the years, Scrapy has evolved significantly, adding new features, improving performance, and fostering a vibrant open-source community, making it a de-facto standard for web crawling in Python.


title: PARAMETERS
content:
<b>--always-on-top</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep the scrcpy window always on top of other windows.<br><br><b>-b <bit-rate>, --bit-rate <bit-rate></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the video bit-rate in bits per second (e.g., 2M for 2 megabits). Default is 8M.<br><br><b>--crop <width>:<height>:<x>:<y></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Crop the device screen to a specific region. Useful for specific applications or resolutions.<br><br><b>-d, --select-usb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a USB device. Useful when multiple devices are connected.<br><br><b>--display <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the display ID to mirror (e.g., 0 for default, 1 for secondary display).<br><br><b>--disable-screensaver</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable the screensaver on the computer while scrcpy is running.<br><br><b>-e, --select-tcpip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a TCP/IP device. Useful when multiple devices are connected (USB and TCP/IP).<br><br><b>-f, --fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the scrcpy window in fullscreen mode.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br><b>--max-fps <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the capture frame rate (e.g., 30 for 30 FPS). Useful for lower-end PCs or network constraints.<br><br><b>--max-size <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the video dimension (width or height). The other dimension is computed to maintain aspect ratio.<br><br><b>-n, --no-control</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable device control, providing mirroring only without keyboard/mouse input.<br><br><b>--no-audio</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable audio forwarding. Requires Android 11+ and scrcpy v1.23+ for audio forwarding to be available.<br><br><b>--no-display</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display the device window. Useful for background screen recording without showing the window.<br><br><b>-r <file>, --record <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Record the mirrored screen to an MP4 file specified by <file>.<br><br><b>-s <serial>, --serial <serial></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the device by its serial number, useful for managing multiple devices.<br><br><b>-S, --turn-screen-off</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turn the device screen off when mirroring starts and turn it back on when scrcpy exits.<br><br><b>-M, --show-touches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show physical touches on the device screen, useful for demonstrations or debugging.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the scrcpy version and exit.<br><br><b>--window-borderless</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable window decorations (title bar, borders).<br><br><b>--window-height <h></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial height of the scrcpy window.<br><br><b>--window-title <title></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the title of the scrcpy window.<br><br><b>--window-width <w></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial width of the scrcpy window.<br><br><b>--window-x <x></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial X position of the scrcpy window on the screen.<br><br><b>--window-y <y></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial Y position of the scrcpy window on the screen.<br><br>


title: DESCRIPTION
content:
<br><i>scrcpy</i> (screen copy) is a free and open-source application that allows you to display and control your Android device from your Linux desktop. It offers high performance, low latency, and high resolution by connecting directly to the device's screen and input. The application requires no root access on the Android device and works by executing an <b>adb</b> server on the computer and a small client on the Android device. This enables a seamless mirroring and control experience, whether connected via USB or wirelessly (through <b>adb</b> over TCP/IP). It's designed to be lightweight and fast, making it an excellent tool for developers, gamers, and anyone needing to interact with their Android device without physically touching it. Key features include screen mirroring, keyboard and mouse input, screen recording, and various customization options for resolution, bit-rate, and display settings.


title: CAVEATS
content:
<b>ADB Requirement:</b> <i>scrcpy</i> relies heavily on the Android Debug Bridge (ADB). You must have ADB installed and configured correctly on your Linux system, and your Android device must have USB debugging enabled.<br><b>Performance:</b> While generally high-performing, the actual latency and quality can vary based on your device's processing power, USB cable quality, and network conditions (for wireless connections).<br><b>Audio Forwarding:</b> Audio forwarding is a relatively newer feature (introduced in <i>scrcpy</i> v1.23) and requires Android 11 or higher. Its stability and performance can vary.<br><b>File Transfer:</b> <i>scrcpy</i> itself does not provide direct file transfer capabilities. For transferring files, you still need to use <b>adb push</b> or <b>adb pull</b> commands.


title: KEYBOARD SHORTCUTS
content:
<br><b>Ctrl+f</b>: Toggle fullscreen.<br><b>Ctrl+g</b>: Resize window to 1:1 pixel-perfect (may be very large).<br><b>Ctrl+x</b> / <b>double-click on black borders</b>: Resize window to remove black borders.<br><b>Ctrl+h</b>: Simulate "Home" button.<br><b>Ctrl+b</b>: Simulate "Back" button.<br><b>Ctrl+m</b>: Simulate "Menu" button.<br><b>Ctrl+w</b>: Turn device screen on/off.<br><b>Ctrl+o</b>: Turn device screen on.<br><b>Ctrl+p</b>: Power off device (Android 9+).<br><b>Ctrl+Shift+s</b>: Take a screenshot.<br><b>Ctrl+Shift+z</b>: Inject SCRCPY_TOGGLE_AUDIO_PLAYBACK (if audio is enabled).<br><b>Ctrl+Shift+f</b>: Open the file explorer (if on Android 10+).<br><b>Ctrl+c</b>: Copy device clipboard to computer.<br><b>Ctrl+v</b>: Paste computer clipboard to device.<br><b>Drag & drop APK</b>: Install an APK file onto the device (on Android 7+).<br><b>Right-click</b>: Simulate "Back" button.


title: CONNECTING WIRELESSLY
content:
<br>1. Connect your Android device to your computer via USB.<br>2. Enable ADB over TCP/IP on your device: <b>adb tcpip 5555</b> (you can choose any available port).<br>3. Disconnect the USB cable from your device.<br>4. Connect to your device wirelessly: <b>adb connect &lt;device_ip_address&gt;:5555</b>.<br>5. Run <i>scrcpy</i>: <b>scrcpy</b>


title: BASIC ADB SETUP
content:
<br>To use <i>scrcpy</i>, you need to enable USB debugging on your Android device and have ADB installed on your computer.<br>1. On your Android device, go to <b>Settings</b> > <b>About phone</b> and tap "Build number" seven times to enable Developer options.<br>2. Go to <b>Settings</b> > <b>System</b> > <b>Developer options</b> and enable "USB debugging".<br>3. Connect your device to your computer via USB.<br>4. On your computer, verify connection with <b>adb devices</b>. You might need to accept a prompt on your phone for "Allow USB debugging?" from your computer's RSA key fingerprint.


title: HISTORY
content:
<br><i>scrcpy</i> was developed by Genymobile, the company behind the Android emulator Genymotion. It was first publicly released in <b>March 2018</b>. The project's primary goal was to provide a free, open-source, lightweight, and high-performance solution for mirroring and controlling Android devices. It quickly gained popularity due to its simplicity, efficiency, and lack of root requirements, becoming a go-to tool for developers and general users alike. Constant development has added features like audio forwarding, multiple display support, and improved performance.


title: SYNOPSIS
content:
screen [<I>options</I>] [<I>command</I> [<I>arguments</I>]]<br>screen -r [<I>sessionid</I>]<br>screen -ls<br>screen -d [<I>sessionid</I>]<br>screen -wipe


title: PARAMETERS
content:
<b>-S <I>sessionname</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Assigns a meaningful name to the new session.</I><br><br><b>-r [<I>sessionid</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Reattaches to a detached screen session by ID or name.</I><br><br><b>-ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Lists all active or detached screen sessions.</I><br><br><b>-d [<I>sessionid</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Detaches a running screen session without killing it.</I><br><br><b>-dmS <I>sessionname</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Detaches if running and creates a new named session in detached mode.</I><br><br><b>-X <I>sessionid</I> <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sends a command to a specific screen session (e.g., 'stuff' for typing).</I><br><br><b>-RR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Reattaches to a session if one exists; otherwise, creates a new one.</I><br><br><b>-wipe</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Removes dead screen session sockets from the system, cleaning up.</I><br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays the version and copyright information for screen.</I><br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays a brief help message with common options.</I><br><br>


title: DESCRIPTION
content:
<b>screen</b> is a powerful GNU utility that allows users to manage multiple independent terminal sessions within a single physical terminal or SSH connection. It serves as a "terminal multiplexer," providing a robust way to keep processes running persistently even if the user disconnects, making it invaluable for long-running tasks, remote server management, and ensuring continuity during network interruptions. Users can detach from a session and reattach later from the same or a different location, preserving the state of all running programs. This capability is particularly useful for sysadmins and developers working on remote servers, preventing work from being lost due to dropped connections. Furthermore, <b>screen</b> supports sharing sessions among multiple users, enabling collaborative work where several people can view and interact with the same terminal session simultaneously. Each <b>screen</b> session can contain multiple "windows," each running a separate shell or program, allowing for efficient task switching and organization within a single terminal interface. It's a foundational tool for resilient command-line work.


title: CAVEATS
content:
<b>screen</b> has a notable learning curve, especially concerning its default keybindings which often use <B>Ctrl+a</B> as a prefix. Users might find it less intuitive initially compared to newer multiplexers. Its configuration can be complex, relying heavily on the <B>.screenrc</B> file for advanced customization. While powerful for session sharing, proper security measures should be considered when multiple users can access the same session.


title: <B>COMMON IN-SESSION KEYBINDINGS</B>
content:
Inside a screen session, commands are typically prefixed with <B>Ctrl+a</B> (or <B>Ctrl+b</B> for some installations). Some common keybindings include:<br><I>Ctrl+a c</I>: <I>Create a new window.</I><br><I>Ctrl+a n</I>: <I>Go to the next window.</I><br><I>Ctrl+a p</I>: <I>Go to the previous window.</I><br><I>Ctrl+a k</I>: <I>Kill the current window.</I><br><I>Ctrl+a d</I>: <I>Detach the current screen session.</I><br><I>Ctrl+a [num]</I>: <I>Switch to window number [num].</I><br><I>Ctrl+a "</I>: <I>Display a list of windows for selection.</I><br><I>Ctrl+a ?</I>: <I>Show all key bindings.</I>


title: <B>CONFIGURATION FILE (.SCREENRC)</B>
content:
The behavior of <I>screen</I> can be extensively customized via its configuration file, typically located at <B>~/.screenrc</B>. This file allows users to set default options, define custom keybindings, auto-start programs in specific windows, and manage visual aspects like the hardstatus line. It's a powerful tool for tailoring <I>screen</I> to individual workflows and automating session setup.


title: HISTORY
content:
<I>GNU Screen</I> was first released in 1987 by Oliver Laumann and Carsten Weinhold, with further development by others within the GNU Project. It predates many modern terminal multiplexers and established the paradigm of persistent terminal sessions. For decades, it was the de-facto standard for managing long-running processes on remote servers, playing a crucial role in systems administration and development before alternatives like <I>tmux</I> emerged. Its longevity speaks to its robust and reliable design and its continued widespread use.


title: SYNOPSIS
content:
<b>screendump</b> [<i>options</i>] [<i>&lt;console_number&gt;</i>]<br><br>Example: <b>screendump</b> 1 &gt; tty1_output.txt<br>Example: <b>screendump</b> <b>-n</b> &gt; current_scrollback.txt


title: PARAMETERS
content:
<b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps only the scrollback buffer, excluding the current screen content.<br><i>Requires kernel 2.6.9 or newer.</i><br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the current screen content. This is the default behavior when <b>-n</b> is not specified.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a dump even if the console is in graphics mode.<br><i>Output may be unreadable garbage.</i><br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><b>-w</b> <i>&lt;cols&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the width of the dumped screen in columns. Default is 80.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the contents of the current active virtual console. Often used implicitly or with '0'.<br><br><b><i>&lt;console_number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The numerical identifier of the virtual console (e.g., 1 for /dev/tty1) to dump.<br><i>If omitted, the current console is often assumed.</i><br><br>


title: DESCRIPTION
content:
<b>screendump</b> is a utility from the <b>kbd</b> package that allows users to dump the textual content of a Linux virtual console (VC) to standard output. Unlike graphical screenshot tools, <b>screendump</b> captures the characters and attributes (like colors) from the console's text buffer, including its scrollback history if available. This command is particularly useful for debugging console applications, capturing error messages from non-graphical environments, or preserving text-mode output that scrolls off the screen. It operates at a low level, interacting directly with the kernel's console driver to retrieve the raw screen data. The output is typically raw character data, which can then be redirected to a file for later review or processing. It's an essential tool for system administrators and developers working in a command-line-only environment.


title: CAVEATS
content:
<b>screendump</b> works exclusively with Linux text virtual consoles. It cannot be used to capture graphical desktop environments (like GNOME, KDE, XFCE) or applications running within them. For graphical screenshots, different tools like <b>scrot</b>, <b>gnome-screenshot</b>, or <b>import</b> (ImageMagick) are required. Dumping a console in graphics mode with <b>-f</b> can result in unreadable output. The <b>-n</b> (scrollback) option requires a relatively modern kernel (2.6.9+).


title: OUTPUT FORMAT
content:
The output of <b>screendump</b> is raw character data from the console buffer. It does not produce image files like PNG or JPEG. To save the output, it should typically be redirected to a file, e.g., `<b>screendump</b> 1 &gt; /tmp/tty1_dump.txt`. The output includes character attributes, but these are generally not directly visible unless parsed by a tool that understands console codes.


title: VIRTUAL CONSOLES
content:
Linux typically provides several virtual consoles (VTs), accessible via <b>Ctrl+Alt+F1</b> through <b>Ctrl+Alt+F6</b> (or higher). <b>screendump</b> targets a specific VT by its number, allowing administrators to capture output from background processes or other logged-in users on different consoles.


title: HISTORY
content:
<b>screendump</b> is part of the <b>kbd</b> package, which provides a set of utilities for controlling the Linux console and keyboard. These tools have been fundamental to the Linux command-line environment since its early days, predating widespread graphical desktop usage. <b>screendump</b> specifically addresses the need to capture ephemeral text output from the console, a common requirement for debugging and system management in a text-only setup. Its functionality has remained largely consistent, with minor enhancements like the scrollback buffer option (<b>-n</b>) being added as kernel capabilities evolved. It remains a niche but vital tool for interacting directly with the Linux console.


title: SYNOPSIS
content:
<b>screenfetch</b> [<i>OPTIONS</i>]<br><br><i>screenfetch is executed without arguments to display default system information. Various options can be supplied to customize the output, control screenshot functionality, or specify data manually.</i>


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version information and exit.<br><br><b>-V, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output for debugging.<br><br><b>-s, --screenshot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Take a screenshot after displaying system information.<br><br><b>--display &lt;display_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an X display to use for screenshot capture.<br><br><b>-o, --output &lt;file_path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file path for the screenshot.<br><br><b>-d, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run without actually taking a screenshot.<br><br><b>-u, --upload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upload the taken screenshot to Imgur.<br><br><b>-c, --color-range &lt;num&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Change the color range for the output (0-15).<br><br><b>-n, --no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable all ANSI colors in the output.<br><br><b>-N, --no-logo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable the ASCII distribution logo.<br><br><b>-L, --logo-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only display the ASCII logo without system information.<br><br><b>-r, --logo-on-right</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Place the ASCII logo on the right side of the output.<br><br><b>-t, --tune</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tune the output to fit the terminal width.<br><br><b>-w, --no-wrap</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable text wrapping for the output.<br><br><b>-p, --pipe</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format output for piping (no colors, logo, or headers).<br><br><b>-a, --autodetect</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to autodetect all information, even if it's slow.<br><br><b>-i, --show-items &lt;item1,item2&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show specified comma-separated items.<br><br><b>-I, --hide-items &lt;item1,item2&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hide specified comma-separated items.<br><br><b>-C, --config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a configuration file (~/.screenfetchrc).<br><br><b>-U, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update screenfetch from the latest git commit (requires git).<br><br><b>-O, --os &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the operating system.<br><br><b>-K, --kernel &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the kernel version.<br><br><b>-M, --uptime &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the system uptime.<br><br><b>-P, --packages &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the package count.<br><br><b>-S, --shell &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the shell.<br><br><b>-R, --resolution &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the screen resolution.<br><br><b>--desktop-environment &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the desktop environment.<br><br><b>-W, --window-manager &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the window manager.<br><br><b>-T, --theme &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the GTK theme.<br><br><b>-X, --icons &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the GTK icon theme.<br><br><b>-F, --font &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the GTK font.<br><br><b>--cpu &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the CPU information.<br><br><b>--gpu &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the GPU information.<br><br><b>--memory &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specify the memory information.<br><br><b>--disable-ssh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable SSH detection, useful for faster startup on SSH connections.<br><br>


title: DESCRIPTION
content:
screenfetch is a command-line tool designed to display system information in an aesthetic and easily shareable format. It gathers details such as the operating system, kernel, uptime, installed packages, shell, resolution, desktop environment, window manager, GTK theme, icons, font, CPU, GPU, and memory usage. This information is presented alongside a large ASCII art logo of the detected Linux distribution or operating system. Popular among Linux users for showcasing their desktop environments, screenfetch is frequently used in screenshots shared on communities like r/unixporn. Its primary appeal lies in its ability to quickly summarize system specifications in a visually engaging manner.


title: CAVEATS
content:
screenfetch relies on various external commands and system files to gather information, and its accuracy can depend on their presence and correct functioning. The screenshot feature specifically requires tools like <b>scrot</b> to be installed. While screenfetch was widely popular, its development has slowed significantly, leading to <b>neofetch</b> being a more actively maintained and feature-rich alternative for similar functionality. Users might find screenfetch less performant or less accurate on very new or obscure distributions compared to <b>neofetch</b>.


title: CONFIGURATION FILE
content:
screenfetch supports a user-specific configuration file located at <b>~/.screenfetchrc</b>. This file allows users to set default options, customize information display, and manage various settings persistent across sessions without needing to specify command-line arguments every time. It can be generated using the <b>--config</b> option.


title: SCREENSHOT DEPENDENCIES
content:
The built-in screenshot functionality (<b>-s</b>) of screenfetch is not self-contained. It typically relies on external command-line screenshot utilities like <b>scrot</b> (for X11) or other similar tools being installed on the system. Without these dependencies, the screenshot feature will not work.


title: HISTORY
content:
screenfetch emerged as a popular command-line utility in the Linux community, particularly within desktop customization scenes like r/unixporn. Developed primarily by Zane Bitter (KittyKatt), it gained traction for its ability to generate visually appealing system information alongside ASCII art distribution logos, making it ideal for sharing system configurations in screenshots. Its peak popularity was arguably in the mid-2010s. However, as its development became less active, a new tool called <b>neofetch</b> emerged, offering similar functionality with more features, better maintainability, and broader distribution support. While screenfetch remains functional, <b>neofetch</b> has largely superseded it as the go-to tool for this specific use case.


title: PARAMETERS
content:
<b><code>-s</code>, <code>--font-size</code> <i>SIZE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the font size in points for the displayed keystrokes.<br><br><b><code>-p</code>, <code>--position</code> <i>POS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the screen position for the display, e.g., <i>top</i>, <i>bottom</i>, <i>top-left</i>, <i>center</i>.<br><br><b><code>-t</code>, <code>--timeout</code> <i>SECONDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of seconds before displayed keystrokes disappear.<br><br><b><code>-b</code>, <code>--background-color</code> <i>COLOR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the background color for the text display (e.g., '#000000', 'black').<br><br><b><code>-c</code>, <code>--color</code> <i>COLOR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the foreground (text) color for the displayed keystrokes.<br><br><b><code>-o</code>, <code>--opacity</code> <i>VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the opacity level of the background, from 0.0 (transparent) to 1.0 (opaque).<br><br><b><code>-u</code>, <code>--modifier-only</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays only modifier keys (e.g., Shift, Ctrl, Alt) and not regular key presses.<br><br><b><code>-S</code>, <code>--scrub-password</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replaces password-like input (e.g., characters typed after 'passwd') with asterisks for privacy.<br><br><b><code>--persist-keys</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps previously pressed keys on screen until new input is received, rather than fading them out after a timeout.<br><br>


title: DESCRIPTION
content:
<b>screenkey</b> is a lightweight, open-source utility for Linux that displays your keystrokes and mouse clicks on screen in real-time. It's primarily used during screencasts, tutorials, or live presentations to help viewers understand which keys are being pressed. The displayed text is highly customizable, allowing users to adjust font size, color, background, position, and the duration keys remain visible. It supports displaying modifier keys (like Shift, Ctrl, Alt), special keys (like Enter, Space), and can be configured to hide sensitive input like passwords. Running discreetly in the background, <b>screenkey</b> provides clear visual feedback of user input, enhancing the clarity and comprehensibility of recorded or live demonstrations.


title: CAVEATS
content:
<b>screenkey</b> is primarily designed for X11 display servers and may require an XWayland session to function correctly on Wayland environments. It depends on `python3-xlib` and `xdotool` for capturing and simulating input, which might need separate installation. In some rare cases, it might conflict with specific desktop environments or custom keyboard layouts.


title: STOPPING SCREENKEY
content:
To stop a running <b>screenkey</b> instance, you can usually click its tray icon and select 'Quit'. Alternatively, use the <b>killall screenkey</b> command in your terminal to terminate all running instances. If you started it from a terminal, pressing <b>Ctrl+C</b> in that terminal will also stop it.


title: HISTORY
content:
<b>screenkey</b> originated as an open-source project to address the common need of screencasters and presenters to visually communicate keyboard input. Its development has focused on simplicity, customizability, and integration with standard Linux desktop environments. It's widely adopted due to its effectiveness in clarifying actions during technical demonstrations, evolving through community contributions to support various display options and input handling features.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append the output to <I>file</I> or `typescript`, instead of overwriting.<br><br><b><b>-c</b>, <b>--command</b> <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <I>command</I> and exit the script when the command exits.<br><br><b><b>-e</b>, <b>--return</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Return the exit code of the child process.<br><br><b><b>-f</b>, <b>--flush</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Flush output after each write, making the script useful for monitoring in near real-time.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be quiet, suppress start and done messages.<br><br><b><b>-t</b>, <b>--timing</b>[=<I>file</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output timing data to a separate file, allowing replaying with realistic delays. If <I>file</I> is not specified, a default `timing` file is used.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><b>-o</b>, <b>--output</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file. This is the default action if a non-option argument is given.<br><br><b><b>-r</b>, <b>--raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Record raw terminal output, including carriage returns. Useful for replaying.<br><br><b><b>-x</b>, <b>--log-timestamps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Log timestamps of each command output, useful for analyzing activity.<br><br><b><b>-F</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use script even if stdin is not a TTY.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make more verbose output, showing script's internal actions.<br><br>


title: DESCRIPTION
content:
The <b>script</b> command creates a typescript of everything displayed on your terminal. It's primarily used for recording interactive sessions, often for demonstration, documentation, or auditing purposes. When <b>script</b> is started, it begins writing all subsequent terminal input and output to a specified file. If no file is provided, it defaults to `typescript`. The recording continues until the <b>script</b> process is exited, typically by typing `exit`, `Ctrl+D`, or by killing the <b>script</b> process.<br><br>The output file contains raw terminal data, including ANSI escape codes, which means that full-screen applications or operations like backspacing will be recorded as their control sequences rather than just the final visible state. This makes it a powerful tool for capturing the exact behavior of a command-line interface.


title: CAVEATS
content:
<b>script</b> captures everything, including sensitive information (passwords, API keys) entered or displayed during the session. The output file can become very large quickly, especially with graphical or verbose commands. It captures raw terminal codes, which might make the output file difficult to read directly without a terminal emulator or tools like `less -R`. It is not ideal for recording applications that redraw the screen extensively (like text editors or `top`), as the recording will contain many control sequences rather than a clear view of the final state.


title: HOW IT WORKS
content:
The <b>script</b> command works by creating a pseudo-terminal (PTY) pair. It connects your standard input and output to the "master" side of the PTY, while the "slave" side is connected to a new shell (or specified command). All data written to the slave side (by the shell) is readable from the master side, and vice versa. <b>script</b> then captures all data flowing through the master side and writes it to the output file.


title: REPLAYING RECORDINGS
content:
To replay a session recorded with the <b>-t</b> (timing) option, you can use the <b>scriptreplay</b> command (often provided by the `util-linux` package, which also contains <b>script</b>). For example, `<b>scriptreplay -t <I>timing_file</I> <I>recorded_session_file</I></b>` will replay the session with the original delays, mimicking the live interaction. Without timing information, you can simply `<b>cat</b>` the output file, or `<b>less -R</b>` to view it with ANSI colors and formatting interpreted.


title: HISTORY
content:
The <b>script</b> command is a very old and fundamental Unix utility, first appearing in 4.2BSD in 1983. Its core functionality has remained largely consistent over the decades, providing a simple yet effective way to record terminal interactions. While more sophisticated session recording tools exist, <b>script</b> remains a widely used and often pre-installed utility for its simplicity and directness.


title: SEE ALSO
content:
<b>tee</b>(1), <b>cat</b>(1), <b>col</b>(1), <b>less</b>(1), <b>scriptreplay</b>(1), <b>tmux</b>(1), <b>screen</b>(1)


title: PARAMETERS
content:
<b><i>typescript_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the file containing the terminal session recording, typically generated by the <i>script(1)</i> command. This file usually contains the raw text output and potentially embedded timing information.<br><br><b><b>-d</b> <i>DELAY</i>, <b>--delay</b>=<i>DELAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add an artificial delay (in seconds) between characters or lines. This can be used to slow down or speed up the playback relative to the recorded timing, or to introduce a uniform delay if no timing information is available.<br><br><b><b>-s</b> <i>SPEED</i>, <b>--speed</b>=<i>SPEED</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjust the playback speed. A value of 1.0 means original recorded speed, 2.0 means twice as fast, 0.5 means half as fast. This modifies the pauses and delays between actions during playback.<br><br><b><b>-n</b>, <b>--no-timing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore any recorded timing information and play back the terminal session as fast as possible, primarily respecting only line breaks and basic output structure.<br><br><b><b>-c</b>, <b>--clear</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear the screen of the current terminal before starting the playback of the recorded session.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message that shows the command's syntax, options, and provides a brief explanation of its usage, then exit.<br><br>


title: DESCRIPTION
content:
The <i>scriptlive</i> command is a utility designed to replay terminal session recordings, typically generated by the <i>script(1)</i> command, in a live, real-time fashion. Unlike simply viewing the raw output file, <i>scriptlive</i> emulates the original session, showing delays, cursor movements, and character by character output as if the commands were being typed and executed in front of you again. It is particularly useful for demonstrations, training, or debugging, allowing users to observe a terminal interaction exactly as it occurred, with the original timing preserved or adjusted. While not a standard core utility on all Linux distributions, various implementations exist, often as Python scripts or similar wrappers around standard tools, aiming to provide this live playback functionality for <i>typescript</i> files.


title: CAVEATS
content:
<i>scriptlive</i> is not a universally standardized Linux command. Its availability and exact options may vary significantly depending on the distribution, specific package, or whether it's a custom script provided by a user or third-party project. Users should verify its presence and functionality on their specific system. Furthermore, different implementations might have varying levels of support for complex terminal escape sequences (e.g., cursor positioning, colors), potentially leading to rendering discrepancies compared to the original recording.


title: USAGE NOTES
content:
To effectively use <i>scriptlive</i>, you typically first record a terminal session using the <i>script</i> command. A common way to do this, capturing both output and timing, is:<br><code>script -t 2&gt;timing.log output.txt<br># ... perform your commands here ...<br>exit</code><br>This command creates two files: <i>output.txt</i> (the raw text of the session) and <i>timing.log</i> (timestamped delays between output). Some <i>scriptlive</i> implementations might expect a single combined file, while others, like the example above, might implicitly look for a companion timing file or expect a specific format. Once recorded, you can then replay it using <i>scriptlive</i>, often by simply providing the main output file:<br><code>scriptlive output.txt</code><br>For accurate playback, it's crucial that your current terminal emulator supports the same escape sequences and character sets that were present in the original recorded file.


title: HISTORY
content:
The concept of recording and replaying terminal sessions dates back to the early days of Unix, with the venerable <i>script(1)</i> command being a foundational tool for this purpose. While <i>script</i> effectively captures raw output and, optionally, timing data, directly replaying it with original timing and visual fidelity was often complex. <i>scriptlive</i> emerged as a specific solution to this challenge, building upon the output format of <i>script</i>. Various independent implementations have appeared over time, often as open-source projects or specialized utilities, driven by the persistent need for clear, reproducible demonstrations of command-line interactions for documentation, training, security analysis, or debugging.


title: SYNOPSIS
content:
<b>scriptreplay</b> [<i>options</i>] [<i>typescript_file</i> [<i>timing_file</i>]]<br><br>Commonly: <b>scriptreplay</b> [<b>-d</b> <i>delay</i>] [<b>-m</b> <i>multiplier</i>] [<b>-s</b> <i>typescript_file</i>] [<b>-t</b> <i>timing_file</i>]


title: PARAMETERS
content:
<b>-d <delay>, --delay <delay></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a fixed <i>delay</i> (in seconds) to each pause during playback. This can slow down or speed up the replay.<br><br><b>-m <multiplier>, --multiplier <multiplier></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Multiply all recorded delays by <i>multiplier</i>. A value of <i>0.5</i> plays back at half speed, <i>2.0</i> at double speed.<br><br><b>-s <file>, --typescript <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <i>typescript</i> file containing the recorded session output. Defaults to <b>typescript</b>.<br><br><b>-t <file>, --timing <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <i>timing</i> file containing the timestamp information. Defaults to <b>timing</b>.<br><br><b><typescript_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The positional argument for the <i>typescript</i> file. If <b>-s</b> is not used, this is the first argument. Defaults to <b>typescript</b>.<br><br><b><timing_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The positional argument for the <i>timing</i> file. If <b>-t</b> is not used, this is the second argument. Defaults to <b>timing</b>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
<i>scriptreplay</i> is a powerful utility used to replay a terminal session that was previously recorded using the <i>script</i> command. It is particularly useful for demonstrations, tutorials, or debugging by allowing users to accurately reproduce the exact output and timing of a past interactive session. For <i>scriptreplay</i> to work effectively, the <i>script</i> command must have been invoked with the <b>-t</b> or <b>--timing</b> option to capture timing information alongside the standard output. This timing data, typically stored in a separate file, dictates how fast or slow the output is displayed during playback, mimicking the original user's typing speed and command execution delays. <i>scriptreplay</i> leverages the <i>pv</i> (Pipe Viewer) utility to control the speed of output, ensuring a faithful reproduction of the original session's rhythm. By default, it expects a file named <b>typescript</b> for the recorded session and <b>timing</b> for the timing information, but these can be specified explicitly.


title: CAVEATS
content:
<i>scriptreplay</i> relies on <i>pv</i> (Pipe Viewer) being installed and available in the system's PATH for accurate timing control. If <i>pv</i> is not found, playback might occur at maximum speed without respecting delays.<br>Playback accuracy is directly dependent on the integrity and correctness of the <i>timing</i> file. Corrupted or incomplete timing data can lead to erratic replay behavior.<br>It re-displays output only; it does not re-execute commands. The interactive nature of the original session is simulated, not replicated.<br>Terminal size changes during the original recording might lead to visual inconsistencies during playback, as <i>scriptreplay</i> does not automatically adjust the terminal size.<br>ANSI escape codes and complex terminal applications might not always render identically across different terminal emulators or versions.


title: RECORDING AND REPLAYING A SESSION
content:
To use <i>scriptreplay</i>, first record a session with timing data. For example:<br><b>script -t 2>timing.log my_session.log</b><br>Perform your commands, then <b>exit</b>.<br><br>To replay the session, use:<br><b>scriptreplay timing.log my_session.log</b><br>Or, explicitly specifying files:<br><b>scriptreplay --timing timing.log --typescript my_session.log</b><br>If you use default names (<b>typescript</b> and <b>timing</b>), you can simply run <b>scriptreplay</b> after <b>script -t</b>.


title: HISTORY
content:
<i>scriptreplay</i> is part of the <i>util-linux</i> project, a collection of essential Linux utilities. Its development is closely tied to the <i>script</i> command. Initially, <i>script</i> only captured the standard output. However, the need to faithfully reproduce the timing and flow of a session led to the addition of the <b>-t</b> (or <b>--timing</b>) option in <i>script</i>, which captures timing metadata. This enhancement made <i>scriptreplay</i> a vital companion tool, allowing for precise re-enactment of recorded sessions for educational, diagnostic, or demonstration purposes. Its integration with <i>pv</i> further solidified its capability to accurately reflect real-world user interaction speeds.


title: SYNOPSIS
content:
<b>crontab</b> [ <b>-u</b> <i>user</i> ] <i>file</i><br><b>crontab</b> [ <b>-u</b> <i>user</i> ] { <b>-l</b> | <b>-r</b> | <b>-e</b> }<br><b>crontab</b> <b>-i</b> [ <b>-u</b> <i>user</i> ] { <b>-l</b> | <b>-r</b> | <b>-e</b> }<br><b>crontab</b> <b>-v</b> [ <b>-u</b> <i>user</i> ]


title: PARAMETERS
content:
<b><b>-u</b> <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>user</i> whose crontab is to be viewed, edited, or removed. This option is typically restricted to the <i>root</i> user. If omitted, the operation applies to the current user.<br><br><b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a file containing cron job definitions to be loaded into the current user's (or specified user's) crontab. This replaces any existing crontab.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the current crontab entries for the specified user or the current user to standard output.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the current crontab for the specified user or the current user. Use with caution.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edits the current crontab for the specified user or the current user. It opens the crontab file in the editor defined by the <b>VISUAL</b> or <b>EDITOR</b> environment variables (in that order).<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>interactive</i>) Used in conjunction with <b>-r</b>, this option prompts the user for confirmation before removing the crontab, providing a safety net.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>verbose</i>) Displays the date and time of the last modification to the current user's crontab. This is useful for verifying recent changes.<br><br>


title: DESCRIPTION
content:
The command '<b>scrontab</b>' is not a standard Linux command and is very likely a misspelling of '<b>crontab</b>'. This analysis will therefore focus on '<b>crontab</b>'.<br><br><b>crontab</b> (short for <i>'cron table'</i>) is a fundamental utility in Unix-like operating systems used to manage scheduled tasks, also known as <i>cron jobs</i>, for individual users. It allows users to define commands or scripts that should be executed automatically at specified times or regular intervals. These definitions are stored in a user-specific file, also called a <i>crontab</i> file, which is then interpreted and executed by the <b>cron</b> daemon running in the background. It's an an indispensable tool for automating routine system administration tasks, data backups, log file rotations, or any periodic command execution without manual intervention. Unlike commands like <b>at(1)</b> which schedule one-time jobs, <b>crontab</b> is designed for recurring tasks, making it a cornerstone for system automation.


title: CAVEATS
content:
As noted in the description, '<b>scrontab</b>' is not a standard command and is almost certainly a typo for '<b>crontab</b>'.<br><br>When using <b>crontab</b>, keep the following in mind:<br><i>Syntax Sensitivity</i>: The crontab file format is extremely strict. Even minor syntax errors can prevent jobs from running without explicit error messages, making debugging challenging.<br><i>Environment Variables</i>: Cron jobs run in a minimal environment. It's common to encounter issues with commands not found or incorrect behavior due to missing environment variables (like <b>PATH</b>). Always specify full paths to executables or set necessary environment variables within the crontab file.<br><i>Output Redirection</i>: Any output (both <i>stdout</i> and <i>stderr</i>) from a cron job is, by default, mailed to the user. This can quickly fill up mailboxes if not redirected to <b>/dev/null</b> or a log file.<br><i>Security Considerations</i>: Be mindful of permissions on scripts executed by cron. Misconfigured crontab entries can pose security risks.<br><i>System-wide Jobs</i>: The <b>crontab</b> command manages <i>user-specific</i> jobs. System-wide cron jobs are typically configured in <b>/etc/crontab</b> or files within <b>/etc/cron.d/</b>, and are not managed by the <b>crontab</b> command itself.


title: CRONTAB FILE FORMAT
content:
Each line in a crontab file (excluding comments and environment variable definitions) represents a single cron job and follows a specific six-field format:<br><br><b>minute hour day_of_month month_of_year day_of_week command_to_execute</b><br><br><ul><li><b>minute</b> (0-59)</li><li><b>hour</b> (0-23)</li><li><b>day_of_month</b> (1-31)</li><li><b>month_of_year</b> (1-12 or Jan-Dec)</li><li><b>day_of_week</b> (0-7 or Sun-Sat; both 0 and 7 are Sunday)</li><li><b>command_to_execute</b> (the shell command or script path)</li></ul><br>Wildcards (<b>*</b>) are commonly used to mean 'every' for a given field. For example, '<b>* * * * *</b>' runs a command every minute. Specific values, comma-separated lists (e.g., <b>1,15</b>), ranges (e.g., <b>9-17</b>), and step values (e.g., <b>*/5</b> for every 5 minutes) can be used within these fields.


title: COMMON ISSUES AND TROUBLESHOOTING
content:
Users frequently encounter issues with cron jobs not running as expected. Common pitfalls include:<br><i>Incorrect Paths</i>: Commands or scripts are not found because their full path is not specified, and the <b>PATH</b> environment variable is limited.<br><i>Environment Variables</i>: Cron jobs run with a minimal set of environment variables. It's often necessary to explicitly set variables like <b>PATH</b>, <b>HOME</b>, or <b>SHELL</b> within the crontab file.<br><i>Output Handling</i>: Unhandled output can be mailed to the user, potentially filling up the mailbox. Always redirect output (e.g., <b>&gt;/dev/null 2&gt;&amp;1</b>) for silent jobs.<br><i>Permissions</i>: Ensure scripts executed by cron have execute permissions.<br><i>Syntax Errors</i>: Use <b>crontab -e</b> to edit, which provides basic syntax checking, but still be vigilant. Online cron editors or validators can be helpful for complex schedules.<br><i>System Logs</i>: Check system logs (e.g., <b>/var/log/syslog</b> or <b>/var/log/cron</b> on some systems) for messages from the <b>cron</b> daemon regarding job execution or failures.


title: HISTORY
content:
The concept of scheduling tasks with a daemon, leading to <b>cron</b>, dates back to early Unix systems, with implementations appearing in V7 Unix in the late 1970s. The <b>crontab</b> command emerged as the primary user interface for managing these scheduled tasks, providing a standardized way for users to define their own recurring jobs without needing to directly interact with the system-wide <b>cron</b> configuration. Over decades, it has remained a core utility across various Unix-like operating systems, with its core functionality largely unchanged, emphasizing its robust and effective design for automating routine operations.


title: SEE ALSO
content:
<b>cron(8)</b>: The daemon responsible for executing scheduled commands., <b>crontab(5)</b>: The manual page describing the format of the crontab files., <b>at(1)</b>: Schedules commands to be executed once at a specified time., <b>anacron(8)</b>: Executes commands periodically on systems that are not continuously running.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--select</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively select a rectangular area of the screen with the mouse to capture.<br><br><b><b>-u</b>, <b>--focused</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Capture the currently focused window.<br><br><b><b>-b</b>, <b>--border</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include the window's border when capturing a focused window (used with <b>-u</b>).<br><br><b><b>-m</b>, <b>--monitor</b> <i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a specific monitor to capture. <i>NUM</i> refers to the monitor index.<br><br><b><b>-d</b>, <b>--delay</b> <i>SECONDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for the specified number of <i>SECONDS</i> before taking the screenshot. Useful for setting up the screen.<br><br><b><b>-c</b>, <b>--count</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a countdown in the terminal while waiting for the delay.<br><br><b><b>-z</b>, <b>--compression</b> <i>PERCENT</i><br><b>-q</b>, <b>--quality</b> <i>PERCENT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the JPEG compression/quality level (0-100). Higher values mean better quality but larger files.<br><br><b><b>-e</b>, <b>--exec</b> <i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specified <i>COMMAND</i> after the screenshot is taken. The filename of the screenshot is passed as a string to the command.<br><br><b><b>-t</b>, <b>--thumb</b> <i>PERCENT</i>|<i>SIZE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a thumbnail of the screenshot. <i>PERCENT</i> scales the original image (e.g., 50), or <i>SIZE</i> specifies the maximum dimension in pixels (e.g., 200px).<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>--display</b> <i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the X display to connect to.<br><br><b><b>--overwrite</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite the target file if it already exists without prompting.<br><br>


title: DESCRIPTION
content:
<i>scrot</i> (SCReenshOT) is a simple, command-line utility designed for taking screenshots on X Window System environments. Unlike more feature-rich GUI screenshot tools, <i>scrot</i> prioritizes minimalism and efficiency, making it an excellent choice for scripting, automation, or users who prefer command-line workflows and lightweight desktop environments. It can capture the entire screen, a specific window, or a user-selected rectangular area. <i>scrot</i> supports various image formats, including JPEG and PNG, and offers basic options for quality, delay, and execution of post-capture commands. Its straightforward design and minimal dependencies make it a popular tool for users looking for fast and reliable screen capturing without bloat.


title: CAVEATS
content:
<i>scrot</i> is specifically designed for the X Window System. It <i>does not</i> natively support Wayland, which is a newer display server protocol. Users on Wayland environments will typically need to use other tools like <i>grim</i>, <i>swaygrab</i>, or <i>gnome-screenshot</i> (which often has Wayland compatibility) or rely on Xwayland compatibility layers, which might not always provide optimal results. Its simplicity means it lacks advanced features like annotation, direct editing, or cloud integration, which are common in more comprehensive GUI screenshot applications.


title: FILENAME FORMATTING
content:
By default, <i>scrot</i> generates filenames based on the current date and time. Users can customize the filename using various format specifiers passed directly to the command as an argument. Common specifiers include:<br><i>%Y</i> (year), <i>%m</i> (month), <i>%d</i> (day), <i>%H</i> (hour), <i>%M</i> (minute), <i>%S</i> (second), <i>%F</i> (full date), <i>%T</i> (full time), <i>%s</i> (unix timestamp), <i>$n</i> (hostname), <i>$i</i> (image width), <i>$h</i> (image height), <i>$f</i> (image format). For example, <code>scrot '%Y-%m-%d-$wx$h.png'</code> would save a file like <code>2023-10-27-1920x1080.png</code>.


title: SCRIPTING AND AUTOMATION
content:
Due to its command-line nature, <i>scrot</i> is exceptionally well-suited for integration into shell scripts. This allows users to automate tasks like taking timed screenshots, capturing specific window states, or processing screenshots with other command-line tools (e.g., uploading to a server using <i>curl</i> after capture via the <b>-e</b> option). Its ability to be chained with other commands makes it a powerful component in more complex automated workflows.


title: HISTORY
content:
<i>scrot</i> emerged as a lightweight and efficient screen capture tool, particularly popular among users of minimalist window managers such as Openbox, Fluxbox, and i3wm. Its development was driven by the need for a simple command-line solution that integrated seamlessly into scripts and offered quick, unburdened screen capture without the overhead of larger graphical applications. It fills a niche for users who prioritize speed and simplicity, reflecting a common philosophy in the Linux ecosystem of providing small, single-purpose utilities that can be combined to achieve more complex tasks. While its core functionality has remained consistent, its enduring popularity underscores its effectiveness in the specific niche it serves.


title: PARAMETERS
content:
<b><i>&lt;PATTERN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The regular expression or literal string to search for within the input.<br><br><b><i>&lt;REPLACEMENT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The string that will replace all occurrences of the pattern. Can include capture groups from the pattern.<br><br><b><i>[FILES...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files that <i>sd</i> should process. If no files are specified, <i>sd</i> reads from standard input.<br><br><b><b>-s</b>, <b>--string-mode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat PATTERN and REPLACEMENT as literal strings instead of regular expressions.<br><br><b><b>-i</b>, <b>--in-place</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modify files directly in place. By default, this creates a backup of the original files (e.g., .bak).<br><br><b><b>-p</b>, <b>--preview</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a diff-like preview of changes without modifying files. This option implies <b>--in-place</b>.<br><br><b><b>-f</b> <i>&lt;flags&gt;</i>, <b>--flags</b> <i>&lt;flags&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply specific regular expression flags. Common flags include 'i' for case-insensitive matching, 'm' for multi-line mode, and 's' for dotall mode.<br><br><b><b>-n</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the find and replace operation and print the result to standard output, but do not write any changes to files.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for <i>sd</i> and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the current version of <i>sd</i> and exit.<br><br>


title: DESCRIPTION
content:
<i>sd</i> is a modern, intuitive, and extremely fast command-line tool for finding and replacing strings. Written in Rust, it offers a user-friendly alternative to traditional tools like <i>sed</i> for common text manipulation tasks. It supports powerful regular expressions for pattern matching and replacement, allowing for complex transformations. <i>sd</i> can process input from standard input or directly edit files, and includes features like case-insensitivity, global replacement, and an optional preview mode to review changes before they are applied. Its primary goal is to provide a highly performant and easy-to-use solution for everyday text transformations.


title: CAVEATS
content:
<i>sd</i> is not a standard utility included with most Linux distributions. It must be installed separately, typically via the Rust package manager <i>cargo</i> or from specific distribution repositories. Its regular expression syntax might differ slightly from <i>sed</i> or Perl due to using Rust's <i>regex</i> crate. When using <b>--in-place</b>, <i>sd</i> by default creates backup files with a .bak extension, which users might need to manage or remove manually.


title: PERFORMANCE
content:
One of <i>sd</i>'s key features is its exceptional speed. Leveraging Rust's performance capabilities, it often processes large files and complex patterns significantly faster than traditional stream editors like <i>sed</i>, making it ideal for large-scale text transformations.


title: REGEX ENGINE
content:
<i>sd</i> utilizes the powerful and highly optimized <i>regex</i> crate in Rust for its pattern matching. This engine supports a feature set similar to Perl-compatible regular expressions (PCRE) while offering robust performance and memory safety.


title: HISTORY
content:
<i>sd</i> was developed by Tatsuya Kawasaki (<i>chmln</i>) as a modern, fast, and user-friendly alternative to the traditional <i>sed</i> command. Its primary motivation was to provide a command-line utility for find-and-replace operations that is both highly performant (being written in Rust) and easier to use for common tasks, without sacrificing the power of regular expressions. It emerged as part of a trend towards creating faster, more intuitive CLI tools using modern programming languages.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b>-l, --list-dictionaries</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available dictionaries and exits.<br><br><b>-u, --utf8-output</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces output to be in UTF-8 encoding. By default, encoding is derived from locale settings.<br><br><b>-j, --utf8-input</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces input to be in UTF-8 encoding. By default, encoding is derived from locale settings.<br><br><b>-x, --exact-search</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs an exact word search, not fuzzy.<br><br><b>-n, --numbered-output</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints search results with numbers, useful especially in interactive mode.<br><br><b>-c, --color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables color output for search results, useful for readability.<br><br><b>-e, --example</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches with examples if the dictionary provides them (not universally supported by all dictionaries).<br><br><b>-s, --use-dict &lt;DICT_NAME&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses only dictionaries with the specified name(s). This option can be used multiple times to select several dictionaries.<br><br><b>-p, --data-path &lt;PATH&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the directory containing dictionary data files.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enters interactive mode, allowing continuous word lookups without re-running the command.<br><br><b>-a, --all-match</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for all matching words, not just the first found entry.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints debug information, primarily for developers.<br><br><b>--debug-search</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints detailed debug information specifically about the search process.<br><br>


title: DESCRIPTION
content:
<i><b>sdcv</b></i> is a free console dictionary client, based on the popular StarDict program. It enables users to quickly look up words and phrases directly from the command line, making it an ideal tool for developers, writers, and anyone who prefers a terminal-centric workflow.<br><br><i>sdcv</i> utilizes StarDict dictionary files (typically .ifo, .idx, and .dz files) and can manage multiple dictionaries simultaneously. Its key features include exact word search, fuzzy search for potential misspellings, and an interactive mode for continuous lookups. It also supports piping input and output, allowing for seamless integration with other command-line tools and scripts. <i>sdcv</i>'s lightweight nature combined with its powerful search capabilities makes it an efficient and indispensable utility for quick dictionary access in a command-line environment.


title: CAVEATS
content:
<i><b>sdcv</b></i> relies on StarDict dictionary files (typically .ifo, .idx, .dz). These dictionaries must be installed in a standard location (e.g., <i>/usr/share/stardict/dic</i> or <i>~/.stardict/dic</i>) or explicitly specified using the <i>-p</i> option. Without them, <i>sdcv</i> cannot perform any lookups. Its text-based interface means it lacks the graphical features of GUI dictionary applications.


title: DICTIONARY LOCATION
content:
By default, <i><b>sdcv</b></i> looks for StarDict dictionaries in common system-wide paths like <i>/usr/share/stardict/dic</i> and user-specific paths such as <i>~/.stardict/dic</i>. Ensure your downloaded .ifo, .idx, and .dz files for each dictionary are placed within a subdirectory under one of these locations, or specify a custom path using the <i>-p</i> option.


title: INTERACTIVE MODE USAGE
content:
To use <i><b>sdcv</b></i> in interactive mode, simply run <i>sdcv -i</i>. You will then be prompted to enter words continuously. Type your word and press Enter to see its definition. To exit interactive mode, press Ctrl+D or type 'q' followed by Enter.


title: PIPING INPUT
content:
<i><b>sdcv</b></i> can accept input from other commands via pipes. For example, to quickly look up a word found by another command, you can use: <i>echo "word_to_lookup" | sdcv</i>. This is particularly useful for scripting or integrating with other text processing tools.


title: HISTORY
content:
<i><b>sdcv</b></i> emerged as the command-line counterpart to the popular open-source StarDict dictionary application, which gained significant traction in the early 2000s for its robust multi-dictionary support and extensible format. While StarDict provided a graphical user interface, <i>sdcv</i> filled the need for a lightweight, terminal-based solution. This allowed users to integrate dictionary lookups into shell scripts, automated tasks, or directly from within text editors and command-line environments, extending the utility of StarDict's vast dictionary collection beyond the desktop GUI.


title: SYNOPSIS
content:
<b>sdiag</b> [<i>-a</i>] [<i>-d directory</i>] [<i>-n node_list</i> | <i>-N node_file</i>] [<i>-c case_id</i>] [<i>-s</i>] [<i>-f file_list</i>] [<i>-e expiration_days</i>] [<i>-q</i>] [<i>-v</i>] [<i>-V</i>]


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collects all available diagnostic data. This option gathers a more extensive set of information, which can be useful for complex issues but may produce a larger output file.<br><br><b>-d <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target directory where the collected diagnostic data will be stored. By default, it's typically <i>/var/mmfs/sdiag/</i>.<br><br><b>-n <I>node_list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of node names or IP addresses from which to collect diagnostic data.<br><br><b>-N <I>node_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file containing a list of node names, one per line, from which to collect diagnostic data.<br><br><b>-c <I>case_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Associates the collected data with a specific IBM problem management record (PMR) or case ID. This helps IBM support organize and track data efficiently.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the creation of a tarball. The collected files remain in their raw format in the specified output directory, allowing for direct inspection.<br><br><b>-f <I>file_list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of additional files or directories to include in the diagnostic collection.<br><br><b>-e <I>expiration_days</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets an expiration period in days for the collected diagnostic data. After this period, the data may be automatically cleaned up by the system.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command in quiet mode, suppressing most output to the console, useful for automated scripts.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command in verbose mode, providing more detailed output about the collection process, useful for monitoring progress.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>sdiag</b> command and exits.<br><br>


title: DESCRIPTION
content:
The <b>sdiag</b> command, part of <b>IBM Spectrum Scale</b> (formerly GPFS), is a critical utility designed to <i>collect comprehensive diagnostic information</i> from a cluster. Its primary purpose is to assist IBM support in troubleshooting and resolving issues related to the file system or its underlying infrastructure. When invoked, <b>sdiag</b> gathers a wide array of system-level and Spectrum Scale-specific data, including various logs (e.g., system logs, trace logs), configuration files, network configurations, kernel information, and the output of other relevant <i>mm</i> commands. This collected data is typically packaged into a compressed tarball, which can then be securely transmitted to IBM for analysis. The command is highly configurable, allowing users to specify target nodes, output directories, and the scope of data collection, making it an indispensable tool for maintaining the health and stability of IBM Spectrum Scale environments.


title: CAVEATS
content:
<B>sdiag is not a standard Linux command</B> and is exclusively available in environments running <I>IBM Spectrum Scale</I> (formerly GPFS). Its functionality and options are specific to this product. Executing <b>sdiag</b> can generate a <I>large volume of data</I>, potentially consuming significant disk space, especially when using the <i>-a</i> option. Data collection can also be resource-intensive on the affected nodes. Users should be mindful of <I>data privacy</I> as collected logs and configuration files may contain sensitive information. Always review the collected data before sharing it externally.


title: DATA TRANSFER TO IBM SUPPORT
content:
Once <b>sdiag</b> has collected data, the resulting tarball is typically uploaded to IBM support via secure methods such as the <I>Enhanced Customer Data Repository (ECuRep)</I> or FTP. The <i>-c</i> option is particularly useful here to associate the collected data directly with an open service request, ensuring it reaches the correct support case.


title: LOCAL DATA ANALYSIS
content:
While primarily intended for IBM support, the collected data can also be invaluable for local administrators. By using the <i>-s</i> option to prevent tarball creation, individual logs and configuration files can be directly accessed for immediate investigation of system behavior or potential issues without needing to unpack a large archive, aiding in proactive problem-solving.


title: HISTORY
content:
The <b>sdiag</b> command has been an integral part of <I>IBM's high-performance file system offering</I> since its days as <B>GPFS (General Parallel File System)</B>. It was developed to streamline the process of gathering diagnostic information from complex clustered environments, enabling IBM support to more efficiently troubleshoot customer issues. With the evolution of GPFS into IBM Spectrum Scale, <b>sdiag</b> has continued to be a core utility, adapted to new features and capabilities of the file system, remaining crucial for maintaining cluster health and facilitating support interactions.


title: SYNOPSIS
content:
<b>sdk</b> <I>command</I> [<I>candidate</I>] [<I>version</I>] [<I>options</I>]<br><br>Examples:<br><b>sdk</b> list java<br><b>sdk</b> install java 17.0.6-tem<br><b>sdk</b> use java 17.0.6-tem<br><b>sdk</b> default java 17.0.6-tem<br><b>sdk</b> current<br><b>sdk</b> version<br><b>sdk</b> update<br><b>sdk</b> selfupdate<br><b>sdk</b> help


title: PARAMETERS
content:
<b>list [candidate]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available SDKs or versions for a specific <I>candidate</I> (e.g., 'java', 'gradle').<br><br><b>install <candidate> [version]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specified <I>version</I> of a given <I>candidate</I>. If <I>version</I> is omitted, the latest stable version is installed.<br><br><b>uninstall <candidate> <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specific installed <I>version</I> of a <I>candidate</I>.<br><br><b>use <candidate> <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Temporarily sets the specified <I>version</I> of the <I>candidate</I> for the current shell session. This change is not persistent across new terminals.<br><br><b>default <candidate> <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permanently sets the specified <I>version</I> of the <I>candidate</I> as the default for all new shell sessions.<br><br><b>current [candidate]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the currently active SDKs or the specific version of a given <I>candidate</I> that is in use.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed <I>SDKMAN!</I> client version.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refreshes the local list of available SDKs and versions from the <I>SDKMAN!</I> remote server.<br><br><b>selfupdate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the <I>SDKMAN!</I> client itself to the latest available version.<br><br><b>help [command]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help or detailed usage information for a specific <I>command</I>.<br><br>


title: DESCRIPTION
content:
The <b>sdk</b> command, specifically referring to <I>SDKMAN!</I> (Software Development Kit Manager), is a powerful command-line tool used to install, manage, and switch between multiple versions of various Software Development Kits (SDKs) and tools on Unix-like operating systems. It is widely used by developers to handle different versions of Java, Groovy, Scala, Kotlin, Maven, Gradle, and other related technologies. <I>SDKMAN!</I> simplifies the process of setting up development environments, allowing users to easily switch SDK versions per project or terminal session, ensuring compatibility and reducing setup complexities. It downloads SDKs from official sources or mirrors, manages their installation directories, and integrates seamlessly with the user's shell environment.


title: CAVEATS
content:
The <b>sdk</b> command is not a standard, built-in Linux utility. It refers to <I>SDKMAN!</I>, which must be installed separately by the user. Its functionality relies heavily on network connectivity to download SDKs and updates. While versatile, it primarily focuses on JVM-based SDKs and related tools, though it supports a growing list of non-JVM candidates. Proper shell integration (sourcing the initialization script) is crucial for its PATH management and command availability.


title: SHELL INTEGRATION
content:
For <I>SDKMAN!</I> to function correctly, its initialization script must be sourced in the user's shell profile (e.g., <I>.bashrc</I>, <I>.zshrc</I>). This script modifies the PATH environment variable, enables command auto-completion, and sets up helper functions, allowing users to execute <b>sdk</b> commands directly and manage SDK versions seamlessly within their terminal sessions.


title: OFFLINE MODE
content:
Once an SDK version is installed, <I>SDKMAN!</I> can manage and switch to it even without an active internet connection. This allows developers to continue working on projects in environments with limited or no network access, provided the necessary SDKs have been pre-downloaded.


title: HISTORY
content:
<I>SDKMAN!</I> originated as GVM (Groovy enVironment Manager) in 2013, initially designed to manage Groovy versions. As its capabilities expanded to include other JVM languages and tools, it was rebranded to <I>SDKMAN!</I> in 2015 to better reflect its broader scope. Since then, it has evolved into a widely adopted tool for managing a diverse range of SDKs, constantly adding support for new candidates and improving its features.


title: SYNOPSIS
content:
<i>sdkmanager</i> [<i>--sdk_root=&lt;sdkRootPath&gt;</i>] [<i>options</i>] [<i>packages...</i>]<br><i>sdkmanager --list</i><br><i>sdkmanager --install &lt;package&gt;</i><br><i>sdkmanager --uninstall &lt;package&gt;</i><br><i>sdkmanager --update</i><br><i>sdkmanager --licenses</i>


title: PARAMETERS
content:
<b><i>--list</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all installed and available packages.<br><br><b><i>--install &lt;package_path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs specified packages. Package paths are typically semi-colon separated, e.g., "platforms;android-34" or "build-tools;34.0.0".<br><br><b><i>--uninstall &lt;package_path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstalls specified packages.<br><br><b><i>--update</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates all installed packages to their latest available versions.<br><br><b><i>--licenses</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows and allows interaction with Android SDK licenses. Accepting licenses is often required before installing new packages.<br><br><b><i>--sdk_root=&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the SDK installation. If not set, it defaults to the <i>ANDROID_HOME</i> environment variable or a default location based on the operating system.<br><br><b><i>--channel=&lt;channel_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the update channel for packages (0=Stable, 1=Beta, 2=Dev, 3=Canary). Default is Stable.<br><br><b><i>--verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output for more detailed information during execution.<br><br><b><i>--no_https</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the use of HTTP instead of HTTPS for package downloads. Use with caution due to security implications.<br><br><b><i>--include_obsolete</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes obsolete packages in the list output when used with <i>--list</i>.<br><br><b><i>--proxy={http|socks} --proxy_host=&lt;host&gt; --proxy_port=&lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures proxy settings for network connections.<br><br>


title: DESCRIPTION
content:
<i>sdkmanager</i> is a command-line tool provided with the Android SDK that allows developers to view, install, update, and uninstall various Android SDK packages. It is an indispensable utility for managing SDK components without a graphical user interface, making it ideal for automation, continuous integration (CI) environments, and server setups. This tool provides fine-grained control over SDK platforms, build tools, system images for emulators, documentation, and other essential components required for Android development. It superseded older command-line tools like <i>android update sdk</i>, offering a more streamlined and robust experience for SDK management.


title: CAVEATS
content:
Requires a Java Development Kit (JDK) to be installed and properly configured in your system's PATH. Downloads can be significantly large and time-consuming, requiring a stable internet connection. On Linux and macOS, ensure the <i>sdkmanager</i> script has execute permissions (<i>chmod +x</i>). It's crucial to accept the SDK licenses using <i>sdkmanager --licenses</i> before attempting to install most packages, otherwise, installations will fail.


title: COMMON USAGE EXAMPLES
content:
<b>List all available and installed packages:</b><br><i>sdkmanager --list</i><br><br><b>Install Android Platform 34 and Build-Tools 34.0.0:</b><br><i>sdkmanager "platforms;android-34" "build-tools;34.0.0"</i><br><i>(You will be prompted to accept licenses or run <i>sdkmanager --licenses</i> first.)</i><br><br><b>Update all installed packages:</b><br><i>sdkmanager --update</i>


title: LOCATION
content:
<i>sdkmanager</i> is typically found in the <i>cmdline-tools/latest/bin/</i> subdirectory within your Android SDK installation. For example, on Linux, this might be <i>$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager</i>.


title: HISTORY
content:
<i>sdkmanager</i> was introduced as part of Android SDK Tools version 25.3.0, released in late 2016. It was developed to replace and modernize the functionality previously handled by the deprecated <i>android</i> command-line tool, specifically its 'update sdk' features. This shift aimed to provide a more modular, robust, and scriptable interface for managing Android SDK components, better supporting automated build processes and continuous integration environments that rely on headless SDK installations.


title: PARAMETERS
content:
<b><b>-i</b>, <b>--bdaddr</b> <i><bdaddr></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local Bluetooth adapter's address to use for the operation. If not specified, the default adapter is used.<br><br><b><b>-l</b>, <b>--l2cap</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests L2CAP binding for the operation. This is relevant for services that require L2CAP communication.<br><br><b><b>-t</b>, <b>--rfcomm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests RFCOMM binding for the operation. This is relevant for services that require RFCOMM communication.<br><br><b><b>-x</b>, <b>--xml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the SDP records in XML format. Useful for programmatic parsing.<br><br><b><b>-P</b>, <b>--raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the raw SDP record data. This is typically used for debugging or advanced analysis.<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>search</b> <i><service></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for a specific Bluetooth service on remote devices. <i><service></i> can be a UUID (e.g., 0x1101 for SPP) or a well-known service name (e.g., <i>DUN</i>, <i>LAN</i>, <i>SP</i>, <i>HID</i>, <i>OPP</i>, etc.).<br><br><b><b>browse</b> [<i><dev></i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Browses and lists all available Bluetooth services on a specified remote device <i><dev></i>. If <i><dev></i> is omitted, it attempts to browse a discoverable device.<br><br><b><b>records</b> [<i><dev></i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all raw SDP records on a specified remote device <i><dev></i>. This provides more detailed information than 'browse'.<br><br><b><b>add</b> <i><service></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a local SDP record for a specified service. This makes the service discoverable by other Bluetooth devices connecting to the local machine. Requires root privileges.<br><br><b><b>del</b> <i><service></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a local SDP record for a specified service. This makes the service no longer discoverable. Requires root privileges.<br><br><b><b>get</b> <i><service></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the local SDP record for a specified service.<br><br><b><b>set</b> <i><service> <attr> <value></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific attribute <i><attr></i> with <i><value></i> for a local SDP record identified by <i><service></i>. This allows modification of existing service attributes. Requires root privileges.<br><br>


title: DESCRIPTION
content:
<i>sdptool</i> is a command-line utility from the BlueZ Bluetooth protocol stack for Linux. It provides functionalities to discover, browse, and manage Service Discovery Protocol (SDP) records on Bluetooth devices. Users can search for specific services (such as Dial-Up Networking, LAN Access, or Serial Port Profile) on remote devices, list all available services, and also add or remove local SDP records to advertise services offered by the local machine. It's an essential tool for developers and users who need to directly interact with Bluetooth service advertisements and discovery mechanisms.


title: CAVEATS
content:
Adding or deleting local SDP records typically requires root privileges.<br>A running Bluetooth daemon (<i>bluetoothd</i>) is necessary for <i>sdptool</i> to function correctly.<br>Service names (e.g., 'SP', 'DUN') are case-sensitive.<br>Some specific Bluetooth UUIDs might need to be provided as full UUIDs rather than short names if <i>sdptool</i> doesn't recognize the alias.


title: SERVICE UUIDS AND NAMES
content:
Bluetooth services are identified by Universally Unique Identifiers (UUIDs), which can be 16-bit, 32-bit, or 128-bit. <i>sdptool</i> often recognizes common 16-bit UUIDs by their short, well-known names (e.g., 'SP' for Serial Port Profile, 'DUN' for Dial-Up Networking Profile). For less common services, you might need to use the full UUID.


title: LOCAL VS. REMOTE OPERATIONS
content:
Commands like <i>search</i>, <i>browse</i>, and <i>records</i> are used to query services on remote Bluetooth devices.<br>Commands like <i>add</i>, <i>del</i>, <i>get</i>, and <i>set</i> are used to manage SDP records on the local Bluetooth adapter, advertising services that your machine provides.


title: HISTORY
content:
<i>sdptool</i> is an integral part of the BlueZ project, the official Bluetooth protocol stack for Linux. BlueZ has been under active development since the early 2000s, providing a comprehensive and robust framework for Bluetooth communication. <i>sdptool</i> emerged as a fundamental utility for interacting with the Service Discovery Protocol (SDP), which is crucial for how Bluetooth devices discover and advertise their capabilities. Its core functionality for SDP operations has remained largely consistent throughout its development.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays standard help options, including generic GTK+ options.<br><br><b>--help-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all help options, including specific GNOME/GTK+ options.<br><br><b>--help-gtk</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays GTK+ options specific to graphical applications.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the Seahorse application.<br><br><b>--display=<i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use for the graphical interface.<br><br>


title: DESCRIPTION
content:
Seahorse is the official GNOME application for managing encryption keys, passwords, and certificates. It provides a graphical interface for creating, importing, exporting, and managing various cryptographic keys and certificates.<br><br>It serves as a user-friendly frontend for complex underlying tools like GnuPG (for PGP keys) and OpenSSH (for SSH keys), and also manages X.509 certificates. Seahorse allows users to generate new key pairs, import existing keys, sign and encrypt files, verify signatures, and manage trusted keys and key servers. It is tightly integrated with the GNOME Keyring, providing a central place for cryptographic material.


title: CAVEATS
content:
Seahorse is primarily a graphical user interface (GUI) application. Its command-line options are very limited, mostly for launching the application or displaying version/help information. For detailed key management operations via the command line, users should refer to underlying tools like <b>gpg</b>, <b>ssh-keygen</b>, or <b>certtool</b>. Seahorse itself does not offer command-line functionality for key creation, import, or export.


title: INTEGRATION WITH GNOME KEYRING
content:
Seahorse serves as the primary graphical interface for managing the contents of the GNOME Keyring. The GNOME Keyring is a system service that securely stores sensitive information such as passwords, SSH keys, and GnuPG keys, providing a secure and centralized repository for cryptographic data.


title: KEY TYPES SUPPORTED
content:
Seahorse provides management capabilities for various types of cryptographic keys:<br><ul><li><b>PGP (GnuPG) Keys:</b> Used for email encryption, digital signatures, and secure communication.</li><li><b>SSH Keys:</b> Used for secure remote login to servers and version control systems.</li><li><b>X.509 Certificates:</b> Used for securing web communication (SSL/TLS), identity verification, and digital signatures in various applications.</li></ul>


title: HISTORY
content:
Seahorse has been a fundamental component of the GNOME desktop environment since its early stages, designed to simplify the complex task of managing cryptographic keys for general users. Its development is closely linked to the GNOME Keyring project, aiming to provide a seamless and secure experience for handling digital identities, passwords, and encryption keys within the desktop environment.


title: SYNOPSIS
content:
<b>searchsploit</b> [<i>OPTIONS</i>] [<i>TERMS</i>]<br><b>searchsploit</b> [<i>OPTIONS</i>] [<i>EDB-ID</i>|<i>CVE-ID</i>]<br><b>searchsploit</b> [<i>OPTIONS</i>] <b>--shellcodes</b><br><b>searchsploit</b> [<i>OPTIONS</i>] <b>--exploits</b><br><b>searchsploit</b> [<i>OPTIONS</i>] <b>--papers</b>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br><b><b>-u</b>, <b>--update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the local Exploit-DB copy (requires internet connection).<br><br><b><b>-c</b>, <b>--case</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a case-sensitive search.<br><br><b><b>-e</b>, <b>--exact</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs an exact match search for specified terms.<br><br><b><b>-s</b>, <b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a strict search, treating multiple terms as an AND operation.<br><br><b><b>-t</b>, <b>--title</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restricts the search to exploit titles only (default searches title and path).<br><br><b><b>-p</b>, <b>--path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the full path to the exploit file on the local system.<br><br><b><b>-m</b>, <b>--mirror</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies (mirrors) the selected exploit file to the current working directory.<br><br><b><b>-x</b>, <b>--examine</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the content of the selected exploit file to the console.<br><br><b><b>-w</b>, <b>--web</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the corresponding Exploit-DB URL for the found exploit.<br><br><b><b>-j</b>, <b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the search results in JSON format, useful for scripting.<br><br><b><b>--cve</b> [<i>CVE-ID</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for exploits by a specific Common Vulnerabilities and Exposures (CVE) ID.<br><br><b><b>--id</b> [<i>EDB-ID</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for exploits by a specific Exploit-DB ID.<br><br><b><b>--shellcodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available shellcodes in the database.<br><br><b><b>--exploits</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available exploits in the database.<br><br><b><b>--papers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available security papers and research documents in the database.<br><br>


title: DESCRIPTION
content:
<i>searchsploit</i> is a powerful command-line utility designed for searching the local Exploit-DB archive. It enables security professionals, penetration testers, and researchers to quickly locate exploits, shellcodes, and vulnerability research papers based on various keywords, CVE IDs, or EDB-IDs.<br><br>As an integral component of the Exploit-DB repository, maintained by Offensive Security, <i>searchsploit</i> provides offline access to a vast collection of public exploits. This capability is particularly invaluable in environments where internet connectivity is limited or unavailable. Users can filter results, display full paths to exploit files, view associated Exploit-DB web links, and even copy exploit code directly to their current working directory. The tool's effectiveness relies on maintaining an up-to-date local database, which can be refreshed regularly to ensure access to the latest publicly disclosed vulnerabilities and proof-of-concepts.


title: CAVEATS
content:
The effectiveness of <i>searchsploit</i> heavily relies on a current local Exploit-DB copy; regular updates are essential. It only searches the <i>local</i> database and does not perform live online lookups. Exploits found may be proofs-of-concept, outdated, or require modifications to function. It serves as a search utility, not an exploitation framework, meaning discovered exploits often need manual review, compilation, or integration with other tools.


title: UPDATING THE DATABASE
content:
To ensure <i>searchsploit</i> provides the most current information, its local database must be updated regularly. This can typically be done via the command <b>exploitdb --update</b> or, in Kali Linux, by reinstalling the package: <b>sudo apt update && sudo apt install --reinstall exploitdb</b>.


title: INTEGRATION WITH KALI LINUX
content:
<i>searchsploit</i> is a fundamental component of Kali Linux, pre-installed and readily available. This tight integration highlights its importance in the cybersecurity toolkit for quick access to vulnerability information directly from the command line.


title: HISTORY
content:
<i>searchsploit</i> was developed by Offensive Security, the team behind Kali Linux and the Exploit-DB project. Its creation addressed the need for offline, rapid access to the vast Exploit-DB archive, making it an indispensable tool for penetration testers working in diverse network environments. Since its introduction, it has become a standard, pre-installed utility in Kali Linux distributions, continuously evolving alongside the Exploit-DB to provide comprehensive vulnerability and exploit information.


title: DESCRIPTION
content:
The command 'secon' is not a standard or recognized utility in mainstream Linux distributions. It is highly probable that 'secon' is a typographical error. Users attempting to execute 'secon' will typically encounter a 'command not found' error message in their terminal.<br><br>While 'secon' resembles parts of names of SELinux (Security-Enhanced Linux) commands, 'secon' itself does not perform any defined operation. Common commands related to security contexts or SELinux policy management include <i>setcon</i>, which changes the security context of a process; <i>semanage</i> for managing SELinux policy; and <i>setenforce</i> for toggling SELinux enforcing mode. Without further context or custom aliases, 'secon' remains an undefined command.


title: CAVEATS
content:
Attempting to run 'secon' will invariably result in a 'command not found' error on standard Linux systems. There is no documented or standard functionality associated with this specific command name in common Linux environments. Any observed behavior under this name would be due to a custom alias, a user-defined function, or a misconfigured system path specific to a local setup, rather than a universal utility.


title: TYPOGRAPHICAL ERROR
content:
It is strongly advised to verify the correct spelling of the command you intend to use. Commands like <b>setcon</b> (for setting process security context), <b>semanage</b> (for SELinux policy management), or <b>setenforce</b> (for SELinux enforcing mode) are common utilities that share similar prefixes and might be the intended command.


title: HISTORY
content:
As 'secon' is not a recognized standard Linux command, it does not possess a documented history of development or usage within the Linux kernel or GNU core utilities projects. Its appearance typically signifies a user error or a specific, non-standard local configuration, rather than a historical utility.


title: SYNOPSIS
content:
secret-tool [OPTIONS] COMMAND [ARGUMENTS]<br><br>Common COMMANDs:<br>&nbsp;&nbsp;&nbsp;<b>store</b> [--label=LABEL] [--collection=COLLECTION] [--no-confirm] [--replace] ATTRIBUTE1 VALUE1 [ATTRIBUTE2 VALUE2 ...]<br>&nbsp;&nbsp;&nbsp;<b>lookup</b> [--collection=COLLECTION] ATTRIBUTE1 VALUE1 [ATTRIBUTE2 VALUE2 ...]<br>&nbsp;&nbsp;&nbsp;<b>clear</b> [--collection=COLLECTION] ATTRIBUTE1 VALUE1 [ATTRIBUTE2 VALUE2 ...]<br>&nbsp;&nbsp;&nbsp;<b>search</b> [--collection=COLLECTION] ATTRIBUTE1 VALUE1 [ATTRIBUTE2 VALUE2 ...]<br>&nbsp;&nbsp;&nbsp;<b>list</b> [--collection=COLLECTION]<br>&nbsp;&nbsp;&nbsp;<b>lock</b> [COLLECTION...]<br>&nbsp;&nbsp;&nbsp;<b>unlock</b> [COLLECTION...]<br>&nbsp;&nbsp;&nbsp;<b>version</b>


title: PARAMETERS
content:
<b>--label=<string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A descriptive name for the secret. Used when storing or as an identifier in searches.<br><br><b>--collection=<name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the collection (keyring) to operate on. Defaults to the 'login' collection if not specified.<br><br><b>--no-confirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents interactive confirmation prompts, making it suitable for non-interactive scripts.<br><br><b>--prompt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an interactive prompt for a password or label, even if standard input could otherwise be used.<br><br><b>--replace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with the 'store' command, replaces an existing secret if its attributes match the new one.<br><br><b>--session=<name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a specific D-Bus session for Secret Service communication, typically for debugging or advanced setups.<br><br><b>ATTRIBUTE VALUE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Key-value pairs (e.g., 'service' 'web', 'user' 'john') used to identify, describe, and search for secrets. At least one attribute pair is usually required when storing or looking up secrets.<br><br>


title: DESCRIPTION
content:
<b>secret-tool</b> is a command-line utility designed to interact with the Secret Service API, a standardized interface for securely storing and retrieving sensitive information such as passwords, API keys, and other credentials. It provides a robust, programmatic way to manage secrets typically handled by desktop keyring systems like <i>gnome-keyring</i> or <i>KDE Wallet</i>.<br><br>Users can perform various operations including storing new secrets, retrieving existing ones based on specific attributes, clearing sensitive data, or searching for secrets matching certain criteria. This tool is invaluable for scripts and automated processes that need to handle confidential data without exposing it directly in plain text. It encrypts secrets and often requires user authentication (e.g., a master password) to access the underlying keyring, ensuring data protection even in compromised environments. Its seamless integration with modern desktop environments makes it a powerful and secure solution for managing credentials across a wide range of applications.


title: CAVEATS
content:
<b>secret-tool</b> requires a running Secret Service API backend, such as <i>gnome-keyring-daemon</i> or <i>kwalletd</i>, to function correctly. Without a compatible backend, it will fail to connect and manage secrets.<br><br>Care must be taken when using <b>secret-tool</b> in shell scripts, as sensitive data printed to stdout (e.g., by <i>lookup</i>) might be exposed in shell history or logs if not handled securely. It's recommended to pipe output directly to other commands or variables that handle sensitive data securely.


title: KEY SUBCOMMANDS
content:
<b>secret-tool</b> operates through various subcommands, each performing a specific action on your secret keyring:<br><br>&nbsp;&nbsp;&nbsp;<b>store</b>: Used to add a new secret. It requires a label, attribute-value pairs for identification, and reads the secret value from standard input.<br>&nbsp;&nbsp;&nbsp;<b>lookup</b>: Retrieves and prints the value of a secret matching the specified attributes to standard output.<br>&nbsp;&nbsp;&nbsp;<b>clear</b>: Deletes secrets from the keyring that match the provided attribute-value pairs.<br>&nbsp;&nbsp;&nbsp;<b>search</b>: Finds and lists the labels of secrets that match the given attributes, without revealing their values.<br>&nbsp;&nbsp;&nbsp;<b>list</b>: Displays all items (labels and their attributes) within a specified collection, useful for an overview of stored secrets.<br>&nbsp;&nbsp;&nbsp;<b>lock</b>: Locks one or more specified collections, making their secrets inaccessible until unlocked, often requiring user authentication.<br>&nbsp;&nbsp;&nbsp;<b>unlock</b>: Unlocks one or more specified collections, allowing access to their secrets.<br>&nbsp;&nbsp;&nbsp;<b>version</b>: Prints the version information for the <b>secret-tool</b> utility.


title: SECRET ATTRIBUTES
content:
Secrets in <b>secret-tool</b> are not just identified by a label; they are primarily indexed by a set of arbitrary key-value string pairs known as <i>attributes</i>. For example, a secret might have attributes like 'service' 'gmail' and 'username' 'user@example.com'. These attributes enable flexible and powerful searching for secrets, allowing you to retrieve specific credentials based on multiple criteria rather than just a single name. When storing a secret, at least one attribute pair is typically required, and these pairs are crucial for future lookups and deletions.


title: HISTORY
content:
<b>secret-tool</b> is part of the <i>libsecret</i> library, which provides the client-side implementation of the Secret Service API. This API and its tools were developed primarily for the GNOME desktop environment to offer a secure and standardized way for applications to store and retrieve sensitive data. It evolved from earlier keyring management utilities, aiming for better integration and adherence to a cross-desktop standard. Its development focuses on providing robust cryptographic protection for stored secrets and seamless integration with user authentication mechanisms.


title: PARAMETERS
content:
<b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug logging for the command execution, useful for troubleshooting issues.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the command's result in a structured JSON format, ideal for scripting and automation.<br><br><b><b>--log-level</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum log level for output messages. Common values include <i>info</i>, <i>warn</i>, <i>error</i>, and <i>debug</i>.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed SecretHub CLI version and exits.<br><br><b><i>COMMAND_SPECIFIC_OPTIONS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Each <b>secrethub</b> <i>COMMAND</i> (e.g., <b>read</b>, <b>write</b>, <b>run</b>) has its own set of specific options that control its behavior. These are typically listed in the help output for each subcommand (e.g., `secrethub read --help`).<br><br>


title: DESCRIPTION
content:
<b>secrethub</b> is the command-line interface (CLI) for SecretHub, a cloud-based platform designed for centralized and secure management of application secrets. It allows developers and operations teams to store, retrieve, and manage sensitive data like API keys, database credentials, and certificates securely. The CLI provides commands to integrate secret management into development workflows, enabling actions such as reading secrets, writing new secrets, managing access controls, and injecting secrets directly into applications as environment variables or files. Its core purpose is to minimize the risk of exposing sensitive information by providing a secure, auditable, and version-controlled environment for secrets. Users authenticate to the SecretHub service, and all secret operations are encrypted and permission-controlled.


title: CAVEATS
content:
Using <b>secrethub</b> requires an active SecretHub account and proper authentication. Network connectivity to the SecretHub service is essential for most operations. Access to secrets is strictly controlled by permissions, meaning users can only interact with secrets they are explicitly authorized to access. The CLI stores configuration and authentication tokens locally, necessitating secure handling of the user's system to prevent unauthorized access to these credentials.


title: CORE SUBCOMMANDS
content:
The <b>secrethub</b> command operates primarily through subcommands, each designed for a specific task. Key subcommands include: <br><b>read</b>: Retrieves a secret from SecretHub. <br><b>write</b>: Stores a new secret or updates an existing one. <br><b>run</b>: Executes a command with secrets injected into the environment. <br><b>ls</b>: Lists secrets or directories within SecretHub. <br><b>acl</b>: Manages access control lists for secrets and paths. <br><b>login</b>: Authenticates the CLI with the SecretHub service.


title: SECRET PATHS
content:
Secrets in SecretHub are organized hierarchically using paths, similar to a file system (e.g., <i>secrethub://my-org/my-app/database/password</i>). These paths are crucial for uniquely identifying secrets and applying granular access controls and permissions.


title: AUTHENTICATION
content:
Users authenticate to the SecretHub service using various methods, including a SecretHub account with personal access tokens, or through integrations with cloud provider identity management systems (e.g., AWS IAM, Azure AD, GCP IAM). Once authenticated, session tokens are securely stored locally to maintain access.


title: HISTORY
content:
SecretHub originated as an independent company focused on providing a cloud-native secrets management platform. It was later acquired by HashiCorp in April 2021. Post-acquisition, SecretHub continued to operate as a distinct product within the HashiCorp portfolio, complementing HashiCorp Vault by offering a fully managed SaaS solution for secrets, particularly appealing to organizations seeking a cloud-first approach without managing the underlying infrastructure.


title: SYNOPSIS
content:
secretsdump.py [options] <I>target_specification</I><br><br><i>Where <I>target_specification</I> can be:</i><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>local</b> (for dumping credentials from the local system where secretsdump.py is executed)<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>[[DOMAIN\]USERNAME[:PASSWORD]@]<I>TARGET_IP_OR_HOSTNAME</I></b> (for remote target systems)


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message and exits.<br><br><b>-system <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the SYSTEM hive file for offline credential extraction.<br><br><b>-sam <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the SAM hive file for offline credential extraction.<br><br><b>-security <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the SECURITY hive file for offline credential extraction.<br><br><b>-ntds <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the NTDS.dit database file for offline Active Directory credential extraction.<br><br><b>-bootkey <KEY></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The System Boot Key (Syskey) to decrypt offline hive files.<br><br><b>-hashes LMHASH:NTHASH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;NTLM hash (LMHASH:NTHASH) for authentication instead of a password.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses Kerberos authentication instead of NTLM. Automatically requests a TGT and uses it.<br><br><b>-no-pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't ask for a password (useful when using -k or -hashes).<br><br><b>-just-dc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a DCSync operation to dump all domain user hashes from an Active Directory Domain Controller.<br><br><b>-just-dc-user <USER></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a DCSync operation for a specific user instead of all users.<br><br><b>-outputfile <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the dumped credentials to a specified output file.<br><br><b>-target-ip <IP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;IP address of the target machine, useful if a hostname is provided and DNS resolution is an issue.<br><br><b>-exec-method <METHOD></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the remote execution method (e.g., smbexec, wmiexec, atsvc) when dumping LSASS remotely.<br><br>


title: DESCRIPTION
content:
<i>secretsdump.py</i> is a powerful Python script, part of the <B>Impacket</B> toolkit, designed for extracting various types of credentials from Windows operating systems. It is widely used in penetration testing, red teaming, and forensic analysis to obtain password hashes (NTLM, LM), Kerberos keys, and other sensitive authentication material.<br><br>The tool can retrieve credentials from several sources:<br><ul><li><b>Local SAM/SYSTEM/SECURITY hives:</b> By parsing these registry files offline or remotely.</li><li><b>LSASS process memory:</b> Directly from the Live Session Security Authority Subsystem Service (LSASS) process, which stores credentials in memory. This often requires administrative privileges.</li><li><b>NTDS.dit:</b> The Active Directory database file on domain controllers, allowing for the extraction of all domain user hashes via techniques like DCSync.</li></ul><br>Its versatility makes it an indispensable tool for privilege escalation and lateral movement within Windows environments.


title: CAVEATS
content:
Using <B>secretsdump.py</B> often requires administrative or domain administrative privileges on the target system. Its activities, especially remote LSASS dumping or DCSync, can be detected by Endpoint Detection and Response (EDR) solutions, antivirus software, and Security Information and Event Management (SIEM) systems. It should only be used in authorized environments for legitimate security testing or forensic purposes, adhering strictly to ethical guidelines and legal regulations.


title: COMMON USAGE SCENARIOS
content:
<ul><li><b>Offline Dumping from Hives:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>secretsdump.py -sam /path/to/SAM -system /path/to/SYSTEM local</i></li><li><b>Dumping Active Directory Hashes via DCSync:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>secretsdump.py -just-dc DOMAIN/ADMIN_USER:PASSWORD@DOMAIN_CONTROLLER_IP</i></li><li><b>Remote LSASS Dumping with Administrative Credentials:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>secretsdump.py DOMAIN/ADMIN_USER:PASSWORD@TARGET_IP</i><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>secretsdump.py -hashes :NTHASH DOMAIN/ADMIN_USER@TARGET_IP</i></li></ul>


title: OUTPUT FORMAT
content:
The output of <B>secretsdump.py</B> typically follows a standardized format, usually resembling:<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>USERNAME:RID:LMHASH:NTHASH:::</i><br>For Kerberos keys from NTDS.dit, it might include:<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>USERNAME:RID:LMHASH:NTHASH:KrbTGT_Hash:Krb_AES128_Hash:Krb_AES256_Hash:::</i><br>This format is compatible with many password cracking tools like Hashcat or John the Ripper, allowing for offline brute-forcing or dictionary attacks on the extracted hashes.


title: HISTORY
content:
<B>secretsdump.py</B> is a key component of the <B>Impacket</B> library, an open-source collection of Python classes for working with network protocols. Impacket was originally developed by SecureAuth (later acquired by Core Security and then Fortra) with a focus on providing programmatic access to network protocols like SMB, MSRPC, and Kerberos. <B>secretsdump.py</B> emerged as one of its most powerful post-exploitation tools, leveraging these protocol implementations to achieve credential dumping functionality. It has been continuously updated to adapt to new Windows versions and security features, maintaining its relevance in the cybersecurity landscape.


title: SEE ALSO
content:
mimikatz, crackmapexec, impacket-psexec.py, impacket-getnpusers, impacket-getuserinfo, impacket-reg.py


title: SYNOPSIS
content:
local-php-security-checker [OPTIONS] <br><i>(Commonly invoked via `php local-php-security-checker.phar [OPTIONS]`)</i>


title: PARAMETERS
content:
<b>-f, --format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for the results (e.g., <b>text</b>, <b>json</b>, <b>yaml</b>, <b>html</b>, <b>checkstyle</b>, <b>sarif</b>). The default is <i>text</i>.<br><br><b>--dir=<dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the directory containing the <i>composer.lock</i> file to be checked. Defaults to the current working directory (<b>.</b>).<br><br><b>--lockfile=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directly specifies the path to the <i>composer.lock</i> file to analyze. This overrides the default directory check.<br><br><b>--no-dev</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the checker to skip auditing development (<i>dev</i>) dependencies. Only production dependencies will be checked.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the command to fail (exit with a non-zero status code) if the <i>composer.lock</i> file is not found in the specified path.<br><br><b>--allow-failure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the command to exit with a 0 status code even if vulnerabilities are found. Useful for non-blocking checks in CI/CD.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all command output except for critical errors. Useful for scripting.<br><br><b>-v|vv|vvv, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of messages. Use multiple 'v's for more detailed output (e.g., <b>-vvv</b> for debug information).<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the application's version information.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message with available options and usage.<br><br>


title: DESCRIPTION
content:
The <b>security-checker</b> tool, commonly referred to as `local-php-security-checker`, is not a native Linux command or a core system utility. Instead, it is a specialized PHP application designed to identify known security vulnerabilities within a PHP project's Composer dependencies. It operates by analyzing the project's `composer.lock` file, which lists all direct and transitive dependencies, and comparing them against a regularly updated public security advisory database, such as the one maintained by SensioLabs or GitHub Advisories.<br><br>This command is primarily used by PHP developers and DevOps engineers to ensure that the libraries and frameworks their applications rely on are not exposed to known exploits. It plays a critical role in continuous integration and continuous deployment (CI/CD) pipelines, where it can automatically flag vulnerable packages before code is deployed to production. Locally, developers use it to proactively address security issues during the development phase. While it runs on Linux environments, its scope is strictly limited to PHP dependency security, offering a vital layer of protection for web applications and other PHP-based services.


title: CAVEATS
content:
The `local-php-security-checker` is <i>not</i> a standard, native Linux command; it is a PHP application. Therefore, it requires a PHP runtime installed on the Linux system to function. Its scope is strictly limited to identifying vulnerabilities within <i>PHP Composer dependencies</i> and does not perform system-wide security audits or check for other types of software vulnerabilities (e.g., operating system, kernel, or other programming language dependencies). It relies on external, public security advisory databases, meaning it will only detect known vulnerabilities that have been disclosed and added to these databases, and it requires internet access for database updates.


title: INSTALLATION
content:
The `local-php-security-checker` is typically installed by downloading its PHAR (PHP Archive) file from its GitHub releases page. Once downloaded, it can be executed directly using `php local-php-security-checker.phar`. For easier access, it is common practice to rename the PHAR file to `local-php-security-checker` and move it to a directory included in the system's PATH (e.g., <i>/usr/local/bin</i>), making it directly executable as `local-php-security-checker`.


title: EXIT CODES
content:
The command provides meaningful exit codes to indicate the result of the scan, which is crucial for automation in scripts and CI/CD pipelines:<br><ul><li><b>0</b>: No vulnerabilities were found, or the ` --allow-failure` option was used.</li><li><b>1</b>: One or more vulnerabilities were found in the dependencies.</li><li><b>2</b>: An error occurred during the execution of the command (e.g., invalid arguments, file not found, network issues).</li></ul>


title: HISTORY
content:
The concept of a security checker for PHP dependencies originated with SensioLabs, the creators of the Symfony framework, who offered a hosted service and later a command-line tool. The `local-php-security-checker` emerged as a standalone, lightweight tool distributed as a PHAR (PHP Archive) file, allowing developers to perform checks locally without relying on external services or full framework installations. It gained popularity for its simplicity and efficiency, becoming a de-facto standard for integrating dependency vulnerability checks into PHP development workflows and CI/CD pipelines.


title: SYNOPSIS
content:
<b>sed</b> [<i>OPTION</i>]... {<i>SCRIPT</i>} [<i>INPUT_FILE</i>]...<br><b>sed</b> [<i>OPTION</i>]... -e <i>SCRIPT</i>... -f <i>SCRIPT_FILE</i>... [<i>INPUT_FILE</i>]...


title: PARAMETERS
content:
<b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress automatic printing of the pattern space. Only lines explicitly requested (e.g., with the 'p' command) are printed.<br><br><b><b>-e <i>script</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>script</i> to the commands to be executed. Useful for specifying multiple editing commands directly on the command line.<br><br><b><b>-f <i>script-file</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add the contents of <i>script-file</i> to the commands to be executed. Allows complex <b>sed</b> scripts to be stored and reused from a file.<br><br><b><b>-i[<i>SUFFIX</i>]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edit files in place. If <i>SUFFIX</i> is provided, a backup of the original file is created with that suffix (e.g., '.bak'). Use with caution as it modifies the original file directly.<br><br><b><b>-E</b>, <b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use extended regular expressions (EREs) instead of basic regular expressions (BREs). EREs offer more powerful pattern matching features, like '+' for one or more occurrences and '?' for zero or one.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unbuffered processing. Data is flushed more frequently, which can be useful in pipelines where output is needed immediately.<br><br><b><b>--posix</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable all GNU extensions and use POSIX-compliant behavior, which can be useful for ensuring script portability across different <b>sed</b> implementations.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<b>sed</b> (stream editor) is a powerful, non-interactive command-line utility that performs text transformations on an input stream (typically a file or output from another command). It reads text line by line into a 'pattern space', applies a sequence of editing commands (defined in a 'sed script') to each line, and then outputs the modified line to standard output. <b>sed</b> is exceptionally versatile due to its robust support for regular expressions, enabling complex pattern matching and substitutions.<br><br>Common applications include search and replace operations, deleting or inserting lines, reformatting data, and extracting specific content. Unlike interactive text editors, <b>sed</b> processes data programmatically, making it an indispensable tool for scripting, automating repetitive text manipulation tasks, and pipeline processing in Unix-like environments. By default, it operates on a copy of the input, leaving the original file unchanged unless explicit in-place editing options are used.


title: CAVEATS
content:
<b>sed</b> by default does not modify files in place; it prints results to standard output. The <b>-i</b> option is required for in-place editing, and caution should be exercised as it directly alters the file. Regular expression syntax can vary slightly between different <b>sed</b> implementations (e.g., GNU <b>sed</b> vs. BSD <b>sed</b>), particularly regarding extended regular expressions and certain escape sequences, which might lead to portability issues. While efficient for line-by-line processing, excessive use of hold space or very large pattern spaces for certain operations can consume significant memory.


title: COMMON COMMANDS AND SCRIPTING
content:
<b>sed</b> operates by applying commands to lines matching an address (a line number or a regular expression). If no address is given, the command is applied to all lines.<br><br>Key commands include:<br><i><b>s/<i>pattern</i>/<i>replacement</i>/[<i>flags</i>]</b></i>: <br>Substitute <i>replacement</i> for the first occurrence of <i>pattern</i> on the line. Common flags: <b>g</b> (global, all occurrences), <b>i</b> (case-insensitive), <b>p</b> (print pattern space if a substitution was made), <b>w <i>file</i></b> (write to <i>file</i>).<br><i><b>d</b></i>: <br>Delete the current line from the pattern space; prevents it from being printed.<br><i><b>p</b></i>: <br>Print the current line in the pattern space. Often used with <b>-n</b> to selectively print lines.<br><i><b>a\<i>text</i></b></i>: <br>Append <i>text</i> after the current line.<br><i><b>i\<i>text</i></b></i>: <br>Insert <i>text</i> before the current line.<br><i><b>c\<i>text</i></b></i>: <br>Change (replace) the current line with <i>text</i>.<br><br>Addresses can be single (e.g., `<b>/<i>pattern</i>/d</b>` to delete lines matching <i>pattern</i>) or ranges (e.g., `<b><i>start</i>,<i>end</i>p</b>` to print lines from <i>start</i> to <i>end</i>).


title: HISTORY
content:
<b>sed</b> was developed by Lee E. McMahon of Bell Labs in 1973-1974 as one of the very early Unix tools. It emerged from the need for a non-interactive editor that could process text streams efficiently, particularly for automating tasks that were cumbersome with line editors like <b>ed</b>. Its design was influenced by <b>ed</b>'s command set but adapted for stream processing. <b>sed</b> predates <b>awk</b> and <b>Perl</b>, filling a crucial gap for programmable text manipulation. Over the decades, it has remained a staple in the Unix toolkit, with GNU <b>sed</b> being the most prevalent implementation on Linux systems, incorporating various extensions and improvements over the original AT&T Unix version.


title: SYNOPSIS
content:
<b>see</b> [<i>options</i>] [<i>file ...</i>]<br>or<br><b>xli</b> [<i>options</i>] [<i>file ...</i>]


title: PARAMETERS
content:
<b>-display <display></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the X server display to use for image output.<br><br><b>-geometry <geometry></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial position and size of the image display window (e.g., <i>800x600+100+50</i>).<br><br><b>-fit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shrink the image to fit within the display window if it's larger than the window, preserving aspect ratio.<br><br><b>-fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the image in fullscreen mode, attempting to fill the entire screen.<br><br><b>-gamma <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply gamma correction to the image. A value of 1.0 is default; values greater than 1.0 brighten, less than 1.0 darken.<br><br><b>-rotate <angle></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rotate the image by a specified angle (90, 180, or 270 degrees clockwise).<br><br><b>-zoom <factor></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zoom the image by a specified factor (e.g., <i>2</i> for double size, <i>0.5</i> for half size).<br><br><b>-background <color></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the background color of the window behind the image (e.g., <i>black</i>, <i>#RRGGBB</i>).<br><br><b>-fork</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detach the command from the controlling terminal and run it in the background.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information for <b>xli</b> and exit.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a summary of command-line options and exit.<br><br>


title: DESCRIPTION
content:
The <b>see</b> command, often a symbolic link or alias for <b>xli</b> (X Load Image), is a venerable utility designed for displaying various image formats on an X Window System display. It offers core functionalities such as loading images from files, resizing them to fit specific window geometries or fullscreen, rotating by set angles, and applying basic gamma correction. While it lacks advanced image editing capabilities, its strength lies in its simplicity and direct integration with the X environment, making it ideal for quick, no-frills image viewing. It provides support for a range of popular image formats including <I>GIF</I>, <I>JPEG</I>, <I>PNG</I>, <I>TIFF</I>, <I>XBM</I>, and <I>XPM</I>, ensuring compatibility with many image types encountered in Unix-like systems. Its primary purpose is to efficiently render image data into an X display window, either interactively or through scripting.


title: CAVEATS
content:
The <b>see</b> command is primarily dependent on the X Window System. It is an older utility and may not be installed by default on modern Linux distributions, which often favor more contemporary image viewers like <I>eog</I> or <I>feh</I>. While functional for basic viewing, it lacks advanced features found in modern image manipulation software. Its usage implies an active graphical X session.


title: SUPPORTED IMAGE FORMATS
content:
The <b>see</b> command (via <b>xli</b>) supports a variety of image formats including <I>GIF</I>, <I>JPEG</I>, <I>PNG</I>, <I>TIFF</I>, <I>XBM</I> (X BitMap), <I>XPM</I> (X PixMap), <I>PBM/PGM/PPM</I> (Netpbm formats), and others. This makes it versatile for displaying a wide range of legacy and modern image files within the X environment.


title: HISTORY
content:
The <b>see</b> command's lineage traces back to early X Window System utilities, specifically as a common symbolic link or alias for <b>xli</b> (X Load Image). <b>xli</b> itself evolved from <I>xloadimage</I>, which was one of the first image display programs for X. It became a staple in X installations during the late 1980s and 1990s, serving as a simple and effective tool for image viewing before the advent of comprehensive desktop environments and their integrated viewers. While still available in some repositories, its prominence has decreased with the rise of more feature-rich alternatives.


title: SYNOPSIS
content:
<I>select</I> <I>name</I> <I>in</I> <I>word</I> ... <I>;</I> <I>do</I> <I>commands</I> <I>;</I> <I>done</I><br><br>Alternatively, if 'in word ...' is omitted, it defaults to positional parameters:<br><I>select</I> <I>name</I> <I>;</I> <I>do</I> <I>commands</I> <I>;</I> <I>done</I>


title: PARAMETERS
content:
<b><I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A variable name that will store the selected item's <B>value</B> (the string) within each iteration of the loop.<br><br><b><I>in word ...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A list of words or strings that will be displayed as numbered menu options. If omitted, the shell's positional parameters (<i>$@</i>) are used as the list of choices.<br><br><b><I>do commands ; done</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block of shell commands that will be executed each time the user makes a selection. This block typically processes the <i>name</i> variable (the selected item) and the <i>REPLY</i> variable (the user's entered number).<br><br>


title: DESCRIPTION
content:
The <b>select</b> construct is a powerful keyword in shells like <i>bash</i> and <i>ksh</i>, designed for creating interactive numbered menus within shell scripts. Unlike typical Linux commands, <b>select</b> is not an executable program but a fundamental part of the shell's scripting capabilities. It presents a list of choices to the user, each automatically numbered. The user enters the number corresponding to their desired option, and <b>select</b> then executes a block of commands. This mechanism simplifies user interaction by providing a structured way to gather input, making scripts more user-friendly and robust than relying solely on arbitrary <i>read</i> commands. The loop continues to prompt for input until explicitly exited or interrupted, ensuring a valid selection is typically made.


title: CAVEATS
content:
The <b>select</b> construct is a shell built-in/keyword, not a standalone executable. <br>The loop continues indefinitely until a <i>break</i>, <i>return</i>, or <i>exit</i> command is encountered within the <i>do...done</i> block, or the script is interrupted (e.g., Ctrl+C). <br>The user's numeric input is stored in the <i>REPLY</i> shell variable, while the selected <B>string</B> from the list is assigned to the loop's <i>name</i> variable. <br>Error handling for invalid numeric input (e.g., out-of-range numbers, non-numeric input) must be explicitly managed within the <i>do...done</i> block.


title: REPLY VARIABLE
content:
After a user makes a selection, the numeric input entered by the user (e.g., '1', '2', '3') is stored in the special shell variable <B>REPLY</B>. This is distinct from the <i>name</i> variable of the <b>select</b> loop, which holds the <B>string value</B> of the selected item.


title: LOOP TERMINATION
content:
To exit a <b>select</b> loop, you must explicitly use a control statement like <B>break</B> within the <i>do...done</i> block, typically after processing a valid selection or if the user chooses an 'Exit' option. Without a <i>break</i>, the menu will continuously re-prompt for input after each action.


title: DEFAULT LIST (POSITIONAL PARAMETERS)
content:
If the <B>in word ...</B> part is omitted from the <b>select</b> statement, the shell automatically uses the script's positional parameters (<i>$1</i>, <i>$2</i>, etc., represented as <i>$@</i>) as the list of choices for the menu. This is useful for creating menus based on command-line arguments.


title: HISTORY
content:
The <b>select</b> construct originated in the <B>KornShell (ksh)</B> and was later adopted by the <B>GNU Bash</B> shell, becoming a standard feature for interactive shell scripting. Its inclusion provided a more structured and robust method for creating user menus compared to previous ad-hoc combinations of <i>echo</i> and <i>read</i> commands, significantly enhancing the interactivity and user-friendliness of shell scripts across various Unix-like systems.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief usage message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the command and exits.<br><br>


title: DESCRIPTION
content:
The <b>select-default-ispell</b> command is a utility primarily found on Debian-based Linux distributions, designed to allow users or system administrators to select the default spell-checking program invoked when the <b>ispell</b> command is run. In the Debian ecosystem, this functionality is commonly managed through the <b>update-alternatives</b> mechanism, which handles situations where multiple programs provide the same core functionality (e.g., <b>ispell</b> can be provided by the original <b>ispell</b> program, <b>aspell</b>, or <b>hunspell</b>).<br><br>While <b>ispell</b> itself is an older spell checker, this command ensures that applications configured to use <b>ispell</b> will utilize the user's preferred underlying engine and dictionary. Running the command usually presents an interactive menu from which the desired alternative can be chosen. Although the command might still exist for backward compatibility, the modern and more general approach to managing such defaults is typically via the <b>update-alternatives --config <I>link_name</I></b> command, such as <b>update-alternatives --config ispell</b>.


title: CAVEATS
content:
This command is largely specific to Debian-based distributions. Its functionality is often integrated into, or superseded by, the more general <b>update-alternatives</b> system. Users are increasingly advised to use <b>update-alternatives --config ispell</b> directly for more flexible control. The <b>ispell</b> program itself is older, with <b>aspell</b> and <b>hunspell</b> being more commonly used modern alternatives for spell-checking. This command primarily sets the <i>default <b>ispell</b> alias</i>, not necessarily the system-wide spell checker for all applications.


title: INTERACTIVE SELECTION
content:
When run without arguments, <br><b>select-default-ispell</b> typically presents an interactive numbered list of available spell checker alternatives (e.g., aspell, hunspell) configured as 'ispell'. Users can then input the number corresponding to their desired default choice.


title: UNDERLYING MECHANISM
content:
This command largely acts as a specialized front-end to the Debian <br><b>update-alternatives</b> system. It manipulates the symbolic links managed by <br><b>update-alternatives</b> for the 'ispell' alternative group, ensuring that the selected program is the one executed when 'ispell' is invoked.


title: HISTORY
content:
The <b>select-default-ispell</b> command emerged as part of the Debian project's efforts to manage system-wide defaults for applications where multiple implementations exist. It aimed to provide a user-friendly way to choose the preferred <b>ispell</b> dictionary or backend. Over time, as the <b>update-alternatives</b> system became more robust and ubiquitous across Debian and its derivatives, specific helper scripts like <b>select-default-ispell</b> have become less central. While still present in some older systems or for backward compatibility, its role has largely been subsumed by direct interaction with <b>update-alternatives</b>, making it a historical artifact representing an earlier approach to default selection.


title: SYNOPSIS
content:
<i><br>select-default-iwrap [<b>-p</b> &lt;<i>prompt</i>&gt;] [<b>-d</b> &lt;<i>default_value</i>&gt;] &lt;<i>item1</i>&gt; [&lt;<i>item2</i>&gt; ...]<br></i><br>This synopsis illustrates a common way such a function might be invoked within a Bash script, providing a custom prompt, an optional default selection, and a list of choices. Actual function implementations may vary in their arguments and behavior.


title: PARAMETERS
content:
<b><b>-p</b> <<i>prompt</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies the introductory message displayed to the user before presenting the choices. For example, 'Please choose an option:'.<br><br><b><b>-d</b> <<i>default_value</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Defines the value that will be returned if the user presses Enter without typing a selection. This value should typically correspond to one of the provided items.<br><br><b><<i>item1</i>> [<<i>item2</i>> ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The list of options from which the user can choose. Each item will be displayed with a corresponding number, allowing the user to select by entering the number.<br><br>


title: DESCRIPTION
content:
The term "select-default-iwrap" does not refer to a standalone Linux command with a dedicated man page, but rather to a common and robust shell scripting pattern. It is typically implemented as a Bash function designed to enhance the built-in Bash <code>select</code> command. This pattern aims to provide a more user-friendly and fault-tolerant interactive menu experience.<br><br>Key features commonly integrated into a "select-default-iwrap" implementation include:<br><ul><li>Offering a default choice if the user simply presses Enter, making interactions quicker.</li><li>Performing input validation to ensure the user's selection is within the valid range of options.</li><li>Reprompting the user until valid input is received, preventing script errors from bad input.</li></ul>This pattern abstracts away the complexities of manual input handling and error checking, making script interaction reliable and intuitive.


title: CAVEATS
content:
It is crucial to understand that "select-default-iwrap" is a conceptual scripting pattern, not a pre-installed executable command like <code>ls</code> or <code>grep</code>. Its implementation details can vary significantly across different scripts or developers. It relies heavily on the Bash shell's <code>select</code> built-in and other Bash-specific features, meaning it is primarily applicable in Bash scripting environments and may not be portable to other shells without modifications. Ensure that the default value, if provided, accurately corresponds to an expected item for proper behavior.


title: TYPICAL IMPLEMENTATION LOGIC
content:
A common implementation of a <code>select-default-iwrap</code> function involves an outer loop that continues until valid input is received. Inside this loop, the <code>select</code> built-in command is used to display the numbered options. The shell variable <code>PS3</code> is often set to customize the prompt displayed by <code>select</code> (e.g., 'Make your choice #? '). After the user enters input, the <code>REPLY</code> variable holds the entered string. The script then checks if <code>REPLY</code> is empty (indicating the default should be used) or if it's a valid number corresponding to an existing option. Error messages are displayed for invalid input, and the loop reiterates, prompting the user again.


title: EXAMPLE USAGE (CONCEPTUAL)
content:
Although not a standalone command, a typical use of a function implementing this pattern in a Bash script would look similar to this:<br><br><code>#!/bin/bash<br><br># Assume 'select-default-iwrap' function is defined here or sourced from a library.<br>#<br># Example function definition (simplified):<br># select-default-iwrap() {<br>#   local prompt="${1:-'Select an option'}"<br>#   local default_val="$2"<br>#   shift 2<br>#   local options=("$@")<br>#   # ... implementation logic with 'select' and validation ...<br>#   # return selected value<br># }<br><br>echo "Configuring application..."<br><br>CHOICE=$(select-default-iwrap -p "Choose an action" -d "View" "Edit" "View" "Delete" "Exit")<br><br>echo "<br>You chose: <b>$CHOICE</b>"<br><br>case "$CHOICE" in<br>  "Edit") echo "Opening editor...";;<br>  "View") echo "Displaying data...";;<br>  "Delete") echo "Deleting records...";;<br>  "Exit") echo "Exiting...";;<br>  *) echo "Invalid choice or default action.";;<br>esac</code><br><br>This example assumes a function named <code>select-default-iwrap</code> is defined and returns the chosen value, which is then assigned to the <code>CHOICE</code> variable for further script logic.


title: DESCRIPTION
content:
The <b>select-default-wordlist</b> command is a utility provided by the <i>wordlist-tool</i> package, primarily found on Debian and Ubuntu-based Linux distributions. Its main purpose is to simplify the management and selection of the default system-wide wordlist. This wordlist is used by various applications, including spell checkers (like those integrated into web browsers or word processors), password cracking tools, and other utilities that require a standard dictionary or word set.<br><br>The command acts as a convenient front-end to the powerful <i>update-alternatives</i> system. Instead of manually configuring symbolic links, <b>select-default-wordlist</b> allows administrators and users to easily choose which installed wordlist (e.g., a small, common list or a large, comprehensive one) should be designated as the system's default, ensuring consistency across applications that rely on the 'wordlist' alternative.


title: CAVEATS
content:
The <b>select-default-wordlist</b> command is specific to Debian and Ubuntu-based Linux distributions and is part of the <i>wordlist-tool</i> package. It is essentially a wrapper script that invokes <i>update-alternatives --config wordlist</i>, meaning its functionality and interactive behavior are entirely dependent on the <i>update-alternatives</i> command. It does not offer non-interactive selection methods directly; for programmatic changes, one should use <i>update-alternatives --set wordlist /path/to/wordlist</i>. As such, it takes no direct command-line parameters or options itself.


title: HOW IT WORKS
content:
When you execute <b>select-default-wordlist</b>, it internally runs the command <i>update-alternatives --config wordlist</i>. This command then presents an interactive menu showing all available wordlists installed on your system that are registered with the 'wordlist' alternative group. You can then select your preferred default by entering its corresponding number. This selection updates the system-wide symbolic link, typically <i>/etc/alternatives/wordlist</i>, to point to the chosen wordlist file (e.g., <i>/usr/share/dict/cracklib-small</i>).


title: COMMON WORDLISTS
content:
Common wordlists available on Debian/Ubuntu systems include: <br><i>cracklib-small</i>: A relatively small and commonly used wordlist. <br><i>debian-wordlist</i>: A more comprehensive list maintained by the Debian project. <br>Other specialized wordlists might be installed by specific packages.


title: HISTORY
content:
The <b>select-default-wordlist</b> command emerged as part of the <i>wordlist-tool</i> package in Debian-based systems. Its development was driven by the need to standardize and simplify the process of managing various installed wordlists across the system. By leveraging Debian's powerful <i>alternatives</i> system, it provides a consistent interface for users and administrators to choose their preferred default wordlist without manually manipulating symbolic links, thus enhancing usability and maintainability for dictionary-reliant applications.


title: DESCRIPTION
content:
<b>select-editor</b> is a user-friendly utility designed for Debian-based systems to simplify the process of choosing the default command-line text editor. It interacts with the <b>update-alternatives</b> system, specifically managing the 'editor' alternative group. When executed, it presents an interactive, numbered list of all available and registered text editors (e.g., <i>nano</i>, <i>vim</i>, <i>emacs</i>). The user simply selects their preferred editor by entering its corresponding number. This action updates the system's <i>/usr/bin/editor</i> symbolic link to point to the chosen application, making it the default for programs that invoke 'editor' or fall back to it when environment variables like <i>EDITOR</i> or <i>VISUAL</i> are not explicitly set.


title: CAVEATS
content:
This utility is primarily found on Debian and Ubuntu distributions and their derivatives; it is not standard on all Linux distributions. It relies on text editors being properly registered as 'editor' alternatives within the <b>update-alternatives</b> system. User choices made through <b>select-editor</b> can be overridden by explicitly setting the <i>EDITOR</i> or <i>VISUAL</i> environment variables in the shell's configuration files (e.g., <i>~/.bashrc</i>, <i>~/.zshrc</i>).


title: INTERACTIVE USAGE
content:
When you run <b>select-editor</b>, it operates interactively. It displays a list of numbered options, each representing an available text editor on your system. You are prompted to enter the number corresponding to your desired editor, and upon confirmation, this selection is applied immediately.


title: CONFIGURATION AND ENVIRONMENT VARIABLES
content:
The selection made by <b>select-editor</b> is typically stored on a per-user basis, often in the <i>~/.selected_editor</i> file. This file then guides the <b>update-alternatives</b> system for that user. While <b>select-editor</b> manages the <i>/usr/bin/editor</i> symlink, it does not directly modify the <i>EDITOR</i> or <i>VISUAL</i> environment variables. Many applications prioritize these environment variables, so for consistent behavior, users may still wish to explicitly set them in their shell's startup scripts (e.g., <i>export EDITOR=vim</i>).


title: HISTORY
content:
<b>select-editor</b> emerged as a user-friendly frontend to the more complex <b>update-alternatives</b> command, specifically for managing the default text editor. Its development is rooted in the Debian project's philosophy of providing intuitive configuration tools. It simplifies what would otherwise require direct interaction with the <b>update-alternatives</b> command's <i>--config</i> option for the 'editor' group, making the process accessible to a wider range of users.


title: SYNOPSIS
content:
<b>semanage</b> [<I>options</I>] { <b>fcontext</b> | <b>port</b> | <b>boolean</b> | <b>user</b> | <b>login</b> | <b>interface</b> | <b>node</b> | <b>permissive</b> | <b>dontaudit</b> } { <b>-a</b> | <b>-d</b> | <b>-m</b> | <b>-l</b> } [<I>specific-options</I>] [<I>arguments</I>]<br><br><b>semanage</b> [<I>options</I>] { <b>fcontext</b> } { <b>-E</b> | <b>--export</b> | <b>-i</b> | <b>--import</b> } [<I>filename</I>]<br><br><b>semanage</b> { <b>-h</b> | <b>--help</b> | <b>-V</b> | <b>--version</b> }<br><br><i>Common Object Types:</i><br><i><b>fcontext</b>: Manage file contexts (e.g., directories, files, symlinks).</i><br><i><b>port</b>: Manage network port contexts.</i><br><i><b>boolean</b>: Manage SELinux booleans.</i><br><i><b>user</b>: Manage SELinux user mappings.</i><br><i><b>login</b>: Manage SELinux user login mappings.</i><br><i><b>interface</b>: Manage network interface contexts.</i><br><br><i>Common Commands/Actions:</i><br><i><b>-a</b>, <b>--add</b>: Add a record.</i><br><i><b>-d</b>, <b>--delete</b>: Delete a record.</i><br><i><b>-m</b>, <b>--modify</b>: Modify an existing record.</i><br><i><b>-l</b>, <b>--list</b>: List records.</i><br><i><b>-E</b>, <b>--export</b>: Export current customizations (e.g., for fcontext rules).</i><br><i><b>-i</b>, <b>--import</b>: Import customizations from a file (e.g., for fcontext rules).</i>


title: PARAMETERS
content:
<b><b>-S SELEVEL</b>, <b>--store SELEVEL</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the policy store to operate on. Common values include <i>local</i> (default, for customizations) or <i>module</i>.<br><br><b><b>-N</b>, <b>--noreload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not reload the SELinux policy after making changes. This is useful for batch operations where a single reload at the end is desired.<br><br><b><b>-C</b>, <b>--customization</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate only on the local customization files, ignoring the base policy. Generally used with <i>-l</i>, <i>-a</i>, <i>-d</i>, <i>-m</i>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<b>semanage</b> is a crucial command-line utility for administering SELinux policy configurations. It provides a high-level interface to manage various SELinux objects and their associated rules, ensuring that changes persist across system reboots. Unlike commands like <b>chcon</b> or <b>setsebool</b> which apply temporary context changes or immediate boolean settings, <b>semanage</b> modifies the underlying SELinux policy store. This makes it the primary tool for making permanent adjustments to how SELinux labels files, ports, network interfaces, and other system resources.<br><br>Administrators use <b>semanage</b> to define custom file contexts (e.g., for new directories or applications), open specific network ports for services, manage SELinux booleans, define SELinux user mappings, and control network interface labeling. It interacts directly with the SELinux policy loaded into the kernel, by default reloading the policy after a change to ensure immediate enforcement. Its comprehensive capabilities simplify the complex task of tailoring SELinux security policies to specific system requirements while maintaining system security and integrity.


title: CAVEATS
content:
<b>semanage</b> requires root privileges to execute. Incorrect use can lead to serious security vulnerabilities or make the system unbootable/unstable if critical contexts are mislabeled. Changes made by <b>semanage</b> are persistent and take effect immediately (unless <i>-N</i> is used) by reloading the SELinux policy, which can briefly impact system performance. It does not directly modify the kernel's active policy; instead, it modifies the policy store, and then tells the kernel to reload the policy from that store. Care must be taken when managing file contexts to ensure regular <b>restorecon</b> operations or system reboots properly apply the new contexts.


title: POLICY RELOAD AND PERSISTENCE
content:
Changes made with <b>semanage</b> are by default loaded into the kernel immediately (unless the <i>-N</i> option is used) and are written to persistent configuration files. This ensures that the new SELinux rules are enforced right away and will remain active after system reboots. For file contexts, while <b>semanage fcontext</b> defines the <i>rules</i> for labeling, actual relabeling of files requires running <b>restorecon</b> or a full system relabel.


title: INTERACTION WITH RESTORECON
content:
When <b>semanage fcontext</b> is used to add or modify file context rules, these rules are applied when files are created or relabeled. To apply new or modified file context rules to existing files, the <b>restorecon</b> command (or <b>fixfiles</b>) must be executed. <b>restorecon</b> uses the rules defined by <b>semanage fcontext</b> to correctly set the SELinux context on files and directories.


title: HISTORY
content:
<b>semanage</b> emerged as part of the SELinux ecosystem to address the need for a standardized, high-level tool to manage persistent SELinux policy configurations. Early SELinux management often involved direct manipulation of policy source files, compiling, and loading, or using more specific, lower-level commands that lacked a unified interface for persistent changes. <b>semanage</b> was developed to abstract this complexity, providing a consistent command-line interface for managing various SELinux objects like file contexts, ports, and booleans. Its introduction significantly simplified the administration of custom SELinux policies, making it more accessible for system administrators to tailor SELinux behavior without deep policy language expertise. It continues to be a core utility in modern SELinux-enabled Linux distributions.


title: SYNOPSIS
content:
<b>semanage boolean</b> { <b>-l</b> | <b>-L</b> | <b>-m</b> [ <b>-P</b> ] { <b>--on</b> | <b>--off</b> } <i>&lt;boolean_name&gt;</i> | <b>-m</b> [ <b>-P</b> ] <i>&lt;boolean_name&gt;</i>={on|off} | <b>--query</b> <i>&lt;boolean_name&gt;</i> }


title: PARAMETERS
content:
<b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all SELinux booleans and their current runtime state (on/off).<br><br><b><b>-L</b>, <b>--list-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all SELinux booleans, their current runtime state, and their default persistent state (on/off).<br><br><b><b>-m</b>, <b>--modify</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies the state or default state of a specified SELinux boolean. Requires a boolean name and a state (--on, --off, or =on/off).<br><br><b><b>--on</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-m</b> to set the boolean's state to <i>on</i> (true). Affects the current policy if not combined with <b>-P</b>.<br><br><b><b>--off</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-m</b> to set the boolean's state to <i>off</i> (false). Affects the current policy if not combined with <b>-P</b>.<br><br><b><b>-P</b>, <b>--persistent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the boolean state change persistent across system reboots. Without this option, changes are only temporary for the current session.<br><br><b><b>--query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current runtime state of a specific SELinux boolean without modifying it.<br><br><b><i>boolean_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the SELinux boolean to operate on. This is required for modify and query operations.<br><br>


title: DESCRIPTION
content:
The <b>semanage boolean</b> command is a subcommand of the <b>semanage</b> utility, designed to manage <br>SELinux policy booleans. Booleans are essentially on/off switches embedded within the SELinux policy that allow administrators to modify the policy's behavior without needing to reload or recompile the entire policy. This provides great flexibility for adapting SELinux to specific system configurations or application requirements. <br><br>This command facilitates common tasks such as listing available booleans, querying their current state, and enabling or disabling them. Changes can be applied temporarily to the running kernel policy or made persistent across system reboots. It serves as a more user-friendly interface compared to the lower-level <b>setsebool</b> command, simplifying complex SELinux administration tasks. Properly utilizing booleans is crucial for fine-tuning SELinux security without resorting to disabling it entirely.


title: CAVEATS
content:
Using <b>semanage boolean</b> requires root privileges. <br>Changes made without the <i>-P</i> (<i>--persistent</i>) option are only effective until the next system reboot. <br>Improperly setting booleans can lead to unexpected application behavior, security vulnerabilities, or even system instability. Always understand the implications of a boolean before modifying it.


title: RUNTIME VS. PERSISTENT CHANGES
content:
When modifying a boolean, it's crucial to understand the difference between runtime and persistent changes. By default, <b>semanage boolean -m</b> only affects the currently loaded SELinux policy in the kernel. To make the change survive a system reboot, the <i>-P</i> or <i>--persistent</i> option must be used. This writes the new state into the SELinux policy configuration files, which are loaded during boot.


title: UNDERSTANDING BOOLEAN NAMING
content:
SELinux boolean names often follow a descriptive pattern, frequently starting with 'allow_' (e.g., <i>allow_httpd_anon_write</i>) or describing a specific feature or context (e.g., <i>semanage_enable_account_auth</i>). Reviewing the full list with <b>semanage boolean -L</b> and their descriptions (if available, often via `seinfo -b <boolean_name>`) is recommended to understand their purpose.


title: HISTORY
content:
The <b>semanage</b> utility, of which <b>boolean</b> is a subcommand, was developed as part of the broader SELinux project to provide a higher-level, more intuitive interface for managing SELinux policy components. Prior to <b>semanage</b>, administrators often had to use more granular and complex tools or direct file manipulations. <b>semanage</b> aimed to simplify tasks like managing file contexts, port contexts, and boolean states, abstracting away some of the underlying complexities and promoting best practices for SELinux administration. Its evolution parallels the increasing adoption and maturity of SELinux in enterprise Linux distributions.


title: SYNOPSIS
content:
<b>semanage fcontext -a | -d | -m</b> [<i>options</i>] <i>file_regexp</i><br><b>semanage fcontext -l</b> [<i>options</i>]<br><b>semanage fcontext -D | -E</b>


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a new file context mapping rule.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete an existing file context mapping rule.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modify an existing file context mapping rule.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all active file context mapping rules.<br><br><b>-f <file_type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the file type for the context. Common types include 'a' (all files), 'd' (directories), 'f' (regular files), 'l' (symbolic links), etc. Use -- -f 'type' to avoid conflicts with other options.<br><br><b>-t <context_type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the SELinux type component of the context (e.g., 'httpd_sys_content_t').<br><br><b>-r <context_role></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the SELinux role component of the context.<br><br><b>-u <context_user></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the SELinux user component of the context.<br><br><b><file_regexp></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The regular expression describing the file path(s) to which the context mapping applies (e.g., '/var/www(/.*)?').<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>-l</i>, lists file context mappings from the policy file, not the active policy. Does not apply changes directly.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>-l</i>, prevents numeric UID/GID resolution to names.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>-l</i>, lists only local customizations (user-added rules), excluding default policy rules.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete all local file context customizations added by the administrator.<br><br><b>-E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reset all file contexts to their default policy values, effectively removing all local customizations and applying the base policy.<br><br>


title: DESCRIPTION
content:
<i>semanage-fcontext</i> is a subcommand of <i>semanage</i> used to manage the mapping of file paths to SELinux contexts. It allows administrators to add, modify, or delete rules that define what SELinux context a file or directory should have based on its path. These rules are stored in the SELinux policy and are used by <i>restorecon</i> (or <i>restorecon -R</i>) to apply the correct contexts to files on the filesystem. This is crucial for maintaining proper security boundaries in SELinux-enabled systems. When a new application is installed or custom directories are created, <i>semanage-fcontext</i> is often used to ensure files within those locations receive the appropriate security labels, thus preventing "permission denied" errors related to SELinux. Without correct file contexts, applications might fail to operate or expose security vulnerabilities.


title: CAVEATS
content:
Changes made with <i>semanage fcontext -a/-d/-m</i> are stored in the local policy store but typically require <i>semanage apply</i> or <i>semanage commit</i> to be activated in the running policy. After activation, <i>restorecon -R</i> must be run on affected paths to apply the new contexts to files on disk.<br>Incorrect regular expressions or contexts can lead to SELinux denials or reduce security.<br>The <i>file_regexp</i> is a regular expression, so special characters like '.', '*', '?', '+', '(', ')', '[', ']', '|', '^', '$' must be escaped if literal interpretation is needed.


title: LOCAL VS. POLICY RULES
content:
<i>semanage fcontext</i> manages rules in the local SELinux policy store (e.g., <i>/etc/selinux/targeted/modules/active/file_contexts.local</i>), which override or supplement the base policy rules (<i>file_contexts</i>).


title: APPLYING CHANGES
content:
After adding/modifying rules with <i>semanage fcontext</i>, run <i>semanage apply</i> to commit the changes to the active policy, then <i>restorecon -Rv /path/to/files</i> to relabel files on the filesystem.


title: REGULAR EXPRESSIONS
content:
Understanding regular expressions is critical for effective use of the <i>file_regexp</i> argument. Incorrect regex can lead to unintended labeling or failure to label desired files, potentially causing SELinux denials.


title: HISTORY
content:
<i>semanage</i> and its subcommands, including <i>fcontext</i>, are part of the <i>policycoreutils</i> package, essential for managing SELinux. SELinux itself was initially developed by the NSA and integrated into the Linux kernel around 2000. <i>semanage</i> was developed as a more user-friendly way to manage persistent SELinux policy customizations, replacing direct interaction with policy source files or low-level tools for common tasks. The <i>fcontext</i> subcommand specifically addresses the critical need to manage file labeling rules persistently, which is a common administrative task in SELinux environments. Its evolution has focused on simplifying the syntax and providing clearer separation between default policy and local customizations.


title: SYNOPSIS
content:
<b>semanage permissive -l</b><br><b>semanage permissive -a</b> <i>type_name</i><br><b>semanage permissive -d</b> <i>type_name</i>


title: PARAMETERS
content:
<b>-a, --add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds the specified SELinux <i>type_name</i> to the list of permissive domains. This change is persistent across reboots.<br><br><b>-d, --delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the specified SELinux <i>type_name</i> from the list of permissive domains. This re-enables SELinux enforcement for that domain. This change is persistent across reboots.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently configured SELinux permissive domains.<br><br><b><i>type_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the SELinux type (domain) to be added or deleted. This is typically the name of a process domain, e.g., <i>httpd_t</i> or <i>sshd_t</i>.<br><br>


title: DESCRIPTION
content:
The <b>semanage-permissive</b> command is a crucial subcommand of the broader <b>semanage</b> utility, which is used for managing SELinux policies on a Linux system. Specifically, <b>semanage-permissive</b> allows system administrators to add, delete, or list SELinux types (domains) that are configured to operate in a "permissive" mode. When a domain is set to permissive, SELinux policy rules related to that specific domain are not enforced. Instead of blocking actions that would normally be denied by the policy, SELinux will merely log these potential denials to the system's audit log (typically <i>/var/log/audit/audit.log</i> or via the systemd journal).<br><br>This functionality is invaluable during the development and troubleshooting of new applications or custom SELinux policies. It enables developers to identify and analyze all policy violations without causing the application to malfunction or crash due to SELinux enforcement. After identifying the necessary policy adjustments by reviewing the audit logs, administrators can then refine their SELinux rules. Once a policy is deemed correct and stable, the domain can be removed from the permissive list, restoring full SELinux enforcement for that service or application.<br><br>It's important to understand that while permissive mode is excellent for debugging, it inherently reduces the security posture for the specific domains involved, as malicious activities within a permissive domain will not be actively blocked by SELinux. Therefore, it is generally recommended to use <b>semanage-permissive</b> as a temporary measure and to revert domains to enforcing mode as soon as possible after debugging is complete.


title: CAVEATS
content:
<b>Reduced Security Posture:</b> While a domain is permissive, SELinux will not enforce its policy for that domain, meaning potential security threats or policy violations within that domain will not be blocked, only logged.<br><br><b>Debugging Tool, Not a Permanent Solution:</b> <b>semanage-permissive</b> is primarily designed for troubleshooting and policy development. Leaving domains permanently permissive undermines the security benefits of SELinux and is generally not recommended for production environments.<br><br><b>Requires Administrative Privileges:</b> This command modifies core SELinux policy and requires root privileges or equivalent permissions to execute successfully.


title: PERSISTENCE
content:
Unlike some other SELinux changes (e.g., <i>setenforce 0</i> for global permissive mode), modifications made using <b>semanage-permissive</b> are written to the SELinux policy store and persist across system reboots. This means you do not need to re-apply the permissive setting after a system restart.


title: VERIFYING PERMISSIVE DOMAINS
content:
To check which domains are currently set to permissive, you can use the command <b>semanage permissive -l</b>. Additionally, you can review the system's audit logs (e.g., with <b>ausearch -m AVC -ts today -i</b>) for denial messages from the domain in question; if they appear but the action wasn't blocked, the domain is likely permissive or the policy allows it.


title: HISTORY
content:
The <b>semanage</b> utility, of which <b>semanage-permissive</b> is a subcommand, emerged as part of the broader effort to simplify SELinux policy management for system administrators. Developed by the National Security Agency (NSA) in collaboration with various open-source communities, SELinux aimed to provide mandatory access control (MAC) capabilities to Linux. Early SELinux management often involved complex direct policy modifications. <b>semanage</b> was introduced to provide a higher-level, more user-friendly interface to manage persistent policy components like file contexts, port contexts, boolean settings, and permissive domains. Its integration into major distributions like Red Hat Enterprise Linux (RHEL) and Fedora significantly increased its adoption and usage among system administrators for easier debugging and deployment of SELinux-hardened systems.


title: SYNOPSIS
content:
<b><br>Adding/Modifying/Deleting:</b><br>semanage port { -a | --add | -d | --delete | -m | --modify } -t <i>TYPE</i> -p { <i>tcp</i> | <i>udp</i> | <i>sctp</i> | <i>dccp</i> } <i>PORT_OR_RANGE</i><br><br><b>Listing:</b><br>semanage port -l | --list [-t <i>TYPE</i>] [-p { <i>tcp</i> | <i>udp</i> | <i>sctp</i> | <i>dccp</i> }]


title: PARAMETERS
content:
<b><b>-a, --add</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new port definition to the SELinux policy. This maps a specific port or range to an SELinux type.<br><br><b><b>-d, --delete</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes an existing port definition from the SELinux policy. This removes a previously defined port-to-type mapping.<br><br><b><b>-m, --modify</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies an existing port definition. Typically used to change the SELinux type associated with a port or range without deleting and re-adding.<br><br><b><b>-l, --list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently defined SELinux port type mappings. Can be filtered by type or protocol.<br><br><b><b>-t <i>TYPE</i>, --type=<i>TYPE</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the SELinux type to be associated with the port(s). This is a mandatory option for add, delete, and modify operations.<br><br><b><b>-p <i>PROTOCOL</i>, --proto=<i>PROTOCOL</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network protocol for the port definition. Valid options are <i>tcp</i>, <i>udp</i>, <i>sctp</i>, or <i>dccp</i>. This is a mandatory option.<br><br><b><b><i>PORT_OR_RANGE</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific port number (e.g., <i>80</i>) or a range of ports (e.g., <i>1024-2048</i>) to be managed. This is required for add, delete, and modify operations.<br><br>


title: DESCRIPTION
content:
The <b>semanage-port</b> command, a subcommand of <b>semanage</b>, is used to manage SELinux port type definitions. SELinux (Security-Enhanced Linux) is a mandatory access control (MAC) system that restricts processes and files based on security labels, enhancing system security beyond traditional Unix permissions.<br><br>For a network service to successfully bind to a specific port, SELinux requires that port to have an appropriate SELinux type label. For example, the standard HTTP port 80 is typically labeled with <i>http_port_t</i>. If a web server attempts to listen on port 8080, and 8080 is not assigned the <i>http_port_t</i> type, SELinux will deny the binding, even if traditional file permissions allow it. The <b>semanage-port</b> command enables administrators to add, delete, modify, or list these port-to-type mappings.<br><br>Changes made with <b>semanage-port</b> are persistent. They are written to the SELinux policy store and survive system reboots, ensuring that custom port configurations are maintained. This tool is crucial for integrating custom applications or running standard services on non-standard ports within an SELinux-enforced environment, preventing permission denied errors and ensuring proper system operation while maintaining a strong security posture.


title: CAVEATS
content:
Incorrectly adding or modifying port definitions can lead to services failing to start or being inaccessible due to SELinux denials. Always ensure the correct SELinux type is used for the service. After making changes, it's advisable to verify them using <b>semanage port -l</b>. If services fail, check <i>/var/log/audit/audit.log</i> for AVC denials and use tools like <b>sealert</b> for analysis.


title: PERSISTENCE OF CHANGES
content:
Unlike temporary changes made with commands like <b>chcon</b> for file contexts, modifications made with <b>semanage port</b> are stored persistently in the SELinux policy store. This means the changes will survive system reboots and apply automatically.


title: DEBUGGING DENIALS
content:
If a service fails to bind to a port after SELinux is enforced, it's highly probable that SELinux is denying the action. The <i>/var/log/audit/audit.log</i> file will contain AVC (Access Vector Cache) messages detailing the denial. Tools like <b>sealert -a /var/log/audit/audit.log</b> can interpret these logs and suggest remedies, often including the necessary <b>semanage port</b> command.


title: HISTORY
content:
The <b>semanage</b> utility, including its <b>port</b> subcommand, was developed as part of the broader SELinux project to provide a consistent and powerful interface for managing SELinux policy components. It largely superseded older, less comprehensive tools like <b>seport</b>, providing a more robust and integrated way to configure persistent SELinux policies, including network port types. Its development is intertwined with the evolution of SELinux itself, becoming a core component of SELinux administration on modern Linux distributions.


title: SYNOPSIS
content:
<b>semver</b> <i>[version | version1 version2 | -i <type> [options]]</i><br><b>semver</b> <i>-r <range> <version></i><br><b>semver</b> <i>--help | --version</i>


title: PARAMETERS
content:
<b><i><version_string></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When called with a single argument, it validates the string and prints the normalized SemVer version if valid. Returns a non-zero exit code if invalid.<br><br><b><i><version1></i> <i><version2></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares two semantic versions. Returns 0 if equal, 1 if <i>version1</i> > <i>version2</i>, -1 if <i>version1</i> < <i>version2</i> (exit code often reflects this comparison).<br><br><b><b>-i</b> | <b>--increment</b> <i><type></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increments the current version by the specified <i>type</i> (e.g., <b>major</b>, <b>minor</b>, <b>patch</b>, <b>premajor</b>, <b>preminor</b>, <b>prepatch</b>, <b>prerelease</b>). Often used with an optional base version.<br><br><b><b>-r</b> | <b>--range</b> <i><range></i> <i><version></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the specified <i>version</i> satisfies the given SemVer <i>range</i> (e.g., '^1.0.0', '~1.2.3'). Returns 0 if it satisfies, non-zero otherwise.<br><br><b><b>--preid</b> <i><identifier></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--increment prerelease</b> or similar operations to specify a prerelease identifier (e.g., 'alpha', 'beta', 'rc').<br><br><b><b>--coerce</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to convert a non-SemVer string into a valid SemVer string if possible (e.g., '1.2' becomes '1.2.0').<br><br><b><b>--loose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables loose parsing, allowing some non-strict SemVer formats (e.g., leading 'v' or extra spaces).<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's help message and available options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version of the <b>semver</b> utility itself.<br><br>


title: DESCRIPTION
content:
The <b>semver</b> command-line utility provides tools for working with Semantic Versioning (SemVer) specifications, a widely adopted versioning scheme for software. SemVer defines a MAJOR.MINOR.PATCH format, where increments to each part signify different levels of API compatibility and feature changes.<br><br>While not a core Linux utility, <b>semver</b> tools are commonly found in development environments, often as part of language ecosystems (like Node.js or Python) or as standalone utilities. Its primary purpose is to automate and validate version number manipulation, ensuring adherence to the SemVer specification. This includes tasks such as comparing two versions, validating if a string is a valid SemVer, parsing version components, incrementing versions (major, minor, patch, or prerelease), and checking if a version satisfies a given range.<br><br><b>semver</b> is invaluable in continuous integration/continuous deployment (CI/CD) pipelines, release management workflows, and package management systems to maintain consistent and predictable software versioning.


title: CAVEATS
content:
The <b>semver</b> command is not a standard, pre-installed utility on most Linux distributions. It typically needs to be installed separately, often as part of a development ecosystem (e.g., Node.js's <b>npm</b> package, Python's <b>pip</b> package, or a standalone binary/script).<br><br>Due to multiple independent implementations, the exact syntax, available subcommands, and specific options may vary significantly between different <b>semver</b> tools. Users should consult the documentation for the specific <b>semver</b> utility they are using.


title: THE SEMANTIC VERSIONING SPECIFICATION
content:
The SemVer specification describes version numbers in the format <b>MAJOR.MINOR.PATCH</b>, optionally with pre-release labels (e.g., <b>-alpha.1</b>) and build metadata (e.g., <b>+build123</b>). It strictly dictates how each segment should be incremented:<br><b>MAJOR</b> version increments for incompatible API changes.<br><b>MINOR</b> version increments for adding backward-compatible functionality.<br><b>PATCH</b> version increments for backward-compatible bug fixes.<br>This consistency helps developers understand the impact of upgrading dependencies and ensures predictable behavior.


title: HISTORY
content:
The concept of Semantic Versioning (SemVer) itself was formalized by <i>Tom Preston-Werner</i>, co-founder of GitHub, around 2011. Its aim was to provide a simple set of rules and requirements that dictate how version numbers are assigned and incremented, based on the types of changes made (backward-compatible bug fixes, backward-compatible new features, or breaking changes).<br><br>As SemVer gained widespread adoption in the software development community, particularly with the rise of package managers like <b>npm</b> and <b>Composer</b>, the need for automated tools to validate, parse, and manipulate these version strings became evident. This led to the creation of various <b>semver</b> command-line utilities and libraries across different programming languages and platforms, each implementing the SemVer specification to aid in consistent release management and dependency resolution.


title: SYNOPSIS
content:
<b>sendmail</b> [<i>flags</i>] [<i>address ...</i>]<br><b>sendmail</b> -bd [<i>flags</i>]<br><b>sendmail</b> -bi<br><b>sendmail</b> -bp<br><b>sendmail</b> -bt<br><b>sendmail</b> -bv <i>address ...</i><br><b>sendmail</b> -q [<i>interval</i>]


title: PARAMETERS
content:
<b><b>-bd</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run as a daemon, waiting for incoming mail connections.<br><br><b><b>-bi</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initialize the aliases database (run <b>newaliases</b>).<br><br><b><b>-bp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the contents of the mail queue.<br><br><b><b>-bt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in address test mode, allowing interactive testing of address parsing and rewrite rules.<br><br><b><b>-bv</b> <i>address ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verify that an address is valid, but do not attempt to deliver it.<br><br><b><b>-q</b> [<i>interval</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process the queue. If an <i>interval</i> is given (e.g., <b>30m</b>), run as a queue processing daemon, waking up every <i>interval</i> to process the queue.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read message for recipients from the <b>To:</b>, <b>Cc:</b>, and <b>Bcc:</b> headers.<br><br><b><b>-i</b> or <b>-oi</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore dots on a line by themselves in incoming messages. This is generally recommended.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Go into verbose mode. Display the delivery steps.<br><br><b><b>-o</b><i>Xvalue</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set option <i>X</i> to <i>value</i>. Many internal options can be configured this way.<br><br><b><b>-f</b> <i>sender</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the sender (envelope-from) address. Useful for automated scripts.<br><br>


title: DESCRIPTION
content:
<b>sendmail</b> is a venerable and powerful Mail Transfer Agent (MTA) widely used on Unix-like systems for routing and delivering email. It functions as a core component of the email infrastructure, handling the complex process of sending and receiving messages between different mail servers and local users. Known for its extensive configurability and adherence to email standards, <b>sendmail</b> can manage various aspects of mail flow, including resolving recipient addresses, queuing messages, and applying various processing rules. While still widely deployed, its complexity and steep learning curve have led to the rise of more user-friendly alternatives like Postfix and Exim. However, understanding <b>sendmail</b> remains fundamental for anyone managing legacy systems or complex email environments.


title: CAVEATS
content:
<b>sendmail</b> is notoriously complex to configure, primarily due to its reliance on the <i>sendmail.cf</i> configuration file, which uses a cryptic and powerful macro-based language. This complexity can lead to misconfigurations that expose security vulnerabilities or cause mail delivery issues. Historically, <b>sendmail</b> has had a reputation for security flaws, though most critical issues have been patched over time. Debugging mail flow issues with <b>sendmail</b> can be challenging due to its intricate internal workings and extensive logging. Modern alternatives like Postfix and Exim are often preferred for their simpler configuration and enhanced security posture, making <b>sendmail</b> less common in new deployments.


title: CONFIGURATION FILES
content:
The primary configuration file for <b>sendmail</b> is <i>/etc/mail/sendmail.cf</i> (or often just <i>/etc/sendmail.cf</i>), which is generated from a more human-readable <i>.mc</i> (m4 configuration) file. Other important files include <i>/etc/mail/aliases</i> (for local mail redirection) and the mail queue directory (e.g., <i>/var/spool/mqueue</i>).


title: EMAIL FLOW
content:
When a message is submitted to <b>sendmail</b> (either by a local user, an application, or another mail server), it goes through a series of steps: address parsing and rewriting, rule-set processing, queueing, and finally, delivery (either local or remote). <b>sendmail</b> uses its extensive set of rules in <i>sendmail.cf</i> to determine how to handle each message.


title: HISTORY
content:
<b>sendmail</b> was originally written by <i>Eric Allman</i> at the <i>University of California, Berkeley</i>, in the early 1980s as part of the BSD operating system. It quickly became the dominant Mail Transfer Agent (MTA) in the Unix world and was instrumental in the early growth of the internet's email infrastructure. Its design was revolutionary for its time, providing robust and flexible mail routing capabilities. For decades, it was the de-facto standard for email servers. While still widely used, its development has slowed, and its market share has declined with the rise of newer MTAs that offer simpler configuration and often better performance for common use cases.


title: PARAMETERS
content:
<b>URL...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more Uniform Resource Locators (URLs) to open in the web browser. These are mandatory arguments.<br><br><b>[OPTIONS]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments that are passed directly to the chosen web browser. <i>sensible-browser</i> itself does not interpret these options; their behavior depends on the specific browser launched.<br><br>


title: DESCRIPTION
content:
<i>sensible-browser</i> is a utility that opens specified URLs using the system's preferred graphical web browser. It acts as a wrapper, abstracting away the specifics of which browser is installed or configured. The command attempts to determine the most appropriate browser to launch, prioritizing the <i>BROWSER</i> environment variable if set. If <i>BROWSER</i> contains a colon-separated list, <i>sensible-browser</i> tries each browser in sequence until one successfully opens. In modern Linux distributions, it often relies on <i>xdg-open</i> for determining the default application, providing a robust mechanism for launching URLs. This ensures a consistent user experience across different desktop environments and configurations, allowing users to simply open a URL without needing to know the exact browser command.


title: CAVEATS
content:
The behavior of <i>sensible-browser</i> is heavily dependent on the system's configuration and the <i>BROWSER</i> environment variable. If no suitable browser is found or configured according to system defaults or the <i>BROWSER</i> variable, the command might fail or open a very basic text-based browser if available as a fallback. <i>sensible-browser</i> does not provide options for configuring the browser itself; it only launches it with the given URLs and passthrough options.


title: ENVIRONMENT VARIABLES
content:
The <I>BROWSER</I> environment variable plays a crucial role in determining which browser <i>sensible-browser</i> will use. If set, it overrides system defaults. This variable can contain a single browser executable (e.g., <i>firefox</i>) or a colon-separated list of browser commands, which are tried in order of appearance until one successfully launches (e.g., <i>export BROWSER=chromium:firefox:lynx</i>).


title: HISTORY
content:
<i>sensible-browser</i> is part of the <i>sensible-utils</i> package, primarily found in Debian-based Linux distributions. This set of utilities aims to provide a common, 'sensible' interface for performing common tasks (like opening a browser, editor, or pager) without requiring the user to know the exact command for their preferred application. Its development has focused on robust fallback mechanisms and integration with desktop environment standards, such as those provided by <i>xdg-utils</i>, to ensure wide compatibility and ease of use.


title: PARAMETERS
content:
<b>[<I>FILE</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more file paths to be opened by the selected editor.<br><br><b>[<I>OPTIONS</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;These represent options that will be passed directly to the chosen underlying editor program (e.g., <i>-R</i> for read-only mode in <i>vi</i>). <b>sensible-editor</b> itself has very few direct options beyond file arguments and the <i>--</i> separator.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops processing of options, treating subsequent arguments as filenames. Useful if a filename begins with a hyphen.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<b>sensible-editor</b> is a utility that attempts to launch the user's preferred text editor program. It's part of the <i>sensible-utils</i> package, designed to provide a consistent and "sensible" way to invoke common applications like editors, pagers, or web browsers, regardless of the specific desktop environment or distribution configuration.<br><br>The command determines which editor to launch by checking, in order: the <b>VISUAL</b> environment variable, then the <b>EDITOR</b> environment variable. If neither is set, it consults the system's <b>update-alternatives</b> configuration for <i>editor</i>. As a last resort, it falls back to a predefined list of common editors (e.g., <i>nano</i>, <i>vi</i>, <i>emacs</i>). All arguments passed to <b>sensible-editor</b> are then forwarded directly to the chosen editor, making it seamless to open files or perform other editor-specific actions. This ensures scripts and applications can reliably open an editor without hardcoding a specific one.


title: CAVEATS
content:
The actual editor launched depends heavily on environment variables (<b>VISUAL</b>, <b>EDITOR</b>) and system-wide alternatives (<b>update-alternatives</b>). If these are not configured as expected, <b>sensible-editor</b> might launch a different editor than the user prefers.<br>The fallback list of editors is predefined; if none of them are installed or accessible, <b>sensible-editor</b> may fail to launch any editor.<br>Since <b>sensible-editor</b> passes all arguments directly, it does not validate or interpret options intended for the underlying editor, which could lead to errors if invalid options are provided.


title: EDITOR SELECTION LOGIC
content:
<b>sensible-editor</b> determines the editor to use by checking the following, in order:<br>1. The value of the <b>VISUAL</b> environment variable.<br>2. The value of the <b>EDITOR</b> environment variable.<br>3. The program configured as the system-wide default for <i>editor</i> via <b>update-alternatives</b> (e.g., <i>/usr/bin/editor</i>).<br>4. A predefined list of common editors (e.g., <i>nano</i>, <i>vi</i>, <i>emacs</i>), using the first one found in the system's <b>PATH</b>.


title: HISTORY
content:
<b>sensible-editor</b> is part of the <i>sensible-utils</i> package, which originated in Debian-based Linux distributions. Its development aimed to address the challenge of providing a consistent and user-friendly way to invoke common applications like text editors, web browsers, and pagers across diverse Unix-like environments. Before <i>sensible-utils</i>, applications often hardcoded editor paths (e.g., <i>/usr/bin/vi</i>) or relied solely on basic environment variables, leading to inconsistencies. <b>sensible-editor</b> leverages environment variables and the <b>update-alternatives</b> system to offer a more robust and customizable solution, making it easier for scripts and users to reliably open their preferred editor.


title: SYNOPSIS
content:
<B>sensors</B> [<I>options</I>] [<I>chip-name</I>]<br>where <I>options</I> include:<br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-A</B>, <B>--no-adapter</B><br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-D</B>, <B>--debug</B><br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-f</B>, <B>--fahrenheit</B><br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-c</B>, <B>--celsius</B><br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-u</B>, <B>--units</B> {<I>fahrenheit</I> | <I>celsius</I> | <I>raw</I>}<br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-j</B>, <B>--json</B><br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-s</B>, <B>--silent</B><br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-h</B>, <B>--help</B><br>&nbsp;&nbsp;&nbsp;&nbsp; <B>-v</B>, <B>--version</B><br>And <I>chip-name</I> specifies a particular sensor chip (e.g., <I>coretemp-isa-0000</I>).


title: PARAMETERS
content:
<b><B>-A</B>, <B>--no-adapter</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the adapter name for each chip, providing a more concise output.<br><br><b><B>-D</B>, <B>--debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output verbose debugging information, useful for troubleshooting sensor detection issues.<br><br><b><B>-f</B>, <B>--fahrenheit</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display temperatures in Fahrenheit instead of the default Celsius.<br><br><b><B>-c</B>, <B>--celsius</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display temperatures in Celsius (this is the default behavior).<br><br><b><B>-u</B>, <B>--units</B> {<I>fahrenheit</I> | <I>celsius</I> | <I>raw</I>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the temperature units for output, overriding <B>-f</B>/<B>-c</B>. 'raw' provides direct numerical values from the sensor.<br><br><b><B>-j</B>, <B>--json</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output sensor data in JSON format, which is highly useful for scripting and integration with other tools.<br><br><b><B>-s</B>, <B>--silent</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the output of chip and adapter names, providing a more compact output suitable for scripting.<br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><B>-v</B>, <B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the program version and exit.<br><br><b><I>chip-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restrict output to a specific sensor chip, identified by its name (e.g., <I>coretemp-isa-0000</I> or <I>nouveau-pci-0100</I>).<br><br>


title: DESCRIPTION
content:
The <B>sensors</B> command is a crucial utility from the <I>lm-sensors</I> package, designed to display real-time readings from various hardware sensors within a Linux system. It provides vital information such as CPU core temperatures, GPU temperatures, motherboard voltages, fan speeds, and sometimes even power consumption or humidity, depending on the available hardware and configured sensors.<br><br>This command leverages the Linux kernel's sensor drivers (e.g., <I>coretemp</I> for Intel CPUs, <I>k10temp</I> for AMD CPUs, <I>nct6775</I> for Super I/O chips, etc.) to access raw sensor data. Before <B>sensors</B> can display meaningful output, the <I>lm-sensors</I> package must be installed, and typically, the <B>sensors-detect</B> utility needs to be run to identify and configure the necessary kernel modules for your specific hardware. Monitoring these readings is essential for maintaining system health, preventing overheating, diagnosing potential hardware issues, and optimizing system performance by ensuring components operate within safe thermal limits. It's an invaluable tool for system administrators, enthusiasts, and anyone concerned about the internal well-being of their machine.


title: CAVEATS
content:
<B>sensors</B> relies heavily on the underlying <I>lm-sensors</I> framework. It requires the <I>lm-sensors</I> package to be installed and the <B>sensors-detect</B> utility to have been run successfully to identify and load the appropriate kernel modules for your specific hardware. Without proper module loading (e.g., <I>coretemp</I> for Intel CPUs, <I>k10temp</I> for AMD, <I>nct6775</I> for Super I/O chips), <B>sensors</B> may report no data or incomplete data. Not all hardware components are supported by <I>lm-sensors</I>, and some readings might be missing or inaccurate depending on the sensor chip and its configuration. Additionally, access to certain sensor data might require root privileges or specific user permissions.


title: GETTING STARTED
content:
To use <B>sensors</B>, you typically need to install the <I>lm-sensors</I> package (e.g., <B>sudo apt install lm-sensors</B> on Debian/Ubuntu, or <B>sudo dnf install lm_sensors</B> on Fedora). After installation, run <B>sudo sensors-detect</B> and answer 'yes' to detect and load the necessary kernel modules for your hardware. You may need to reboot or load modules manually for changes to take effect.


title: INTERPRETING OUTPUT
content:
The output of <B>sensors</B> typically shows chip names, specific sensor labels (e.g., <I>Package id</I>, <I>Core 0</I>), current readings, and sometimes low/high/critical limits. Temperatures often have 'high' and 'crit' thresholds, indicating when a component is reaching unsafe operating temperatures. Voltages might show 'in' for input, 'Vcore' for CPU voltage, etc. Fan speeds are usually in RPM (Revolutions Per Minute).


title: COMMON USE CASES
content:
<B>sensors</B> is widely used for real-time system health monitoring, especially for checking CPU and GPU temperatures to prevent overheating during heavy loads. It's frequently combined with other commands like <B>watch(1)</B> (<I>watch -n 1 sensors</I>) for continuous monitoring or piped to <B>grep(1)</B> for specific readings (<I>sensors | grep 'Core'</I>). Its <B>-j</B> option for JSON output makes it ideal for scripting and integration with other monitoring tools.


title: HISTORY
content:
The <B>sensors</B> command is part of the broader <I>lm-sensors</I> (Linux Monitoring Sensors) project, which originated in the late 1990s. Its primary goal was to provide a standardized, user-space interface for accessing and interpreting data from various hardware monitoring chips (such as those found on motherboards, CPUs, and GPUs). Before <I>lm-sensors</I>, obtaining such data often required vendor-specific tools or direct, complex access to hardware registers. The project evolved significantly, abstracting hardware details through kernel modules, making it easier for users and applications to monitor system health. <I>lm-sensors</I> became a critical component for thermal management, performance monitoring, and debugging hardware issues in Linux systems, with its development driven by a dedicated community.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>-o <FILE>, --output=<FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write output to the specified file instead of stdout. If <i>FILE</i> is '-', output is written to stdout.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite existing output file without prompting.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt before writing any output file, and before converting unsupported sections.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the conversion process.<br><br><b>-s, --stdout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write converted configuration to standard output. This is the default if no output file is specified and <b>-o</b> is not used.<br><br><b>-n, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run. Do not write any files, but show what would be done.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all non-error output during conversion.<br><br><b>-c <FILE>, --config=<FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified configuration file as input. If omitted, <b>/etc/sensors.conf</b> is used.<br><br>


title: DESCRIPTION
content:
The <b>sensors-conf-convert</b> command is a utility provided by the <b>lm-sensors</b> package. Its primary function is to assist users in migrating their existing <b>sensors.conf</b> configuration files, which are used by older versions of <i>libsensors</i> (typically <i>libsensors2</i>), to the new <b>sensors3.conf</b> format compatible with <i>libsensors3</i> and later. This conversion is crucial because <i>libsensors3</i> introduced a new configuration file syntax and structure. The tool attempts to automatically translate the module and chip-specific configurations, aliases, and feature definitions.<br><br>It is an essential tool for users upgrading their <b>lm-sensors</b> installation to ensure continued proper hardware monitoring without manual re-creation of the configuration. It is highly recommended to use the dry-run or interactive modes first and always back up original configuration files before performing any conversion.


title: CAVEATS
content:
The conversion process is not always perfect, especially for complex or highly customized configurations. Users should always review the converted file carefully.<br><br>It is highly recommended to use the <b>--dry-run</b> option first to preview changes and to always back up the original <b>sensors.conf</b> file before performing any actual conversion. Some old features or custom rules might not have a direct equivalent in the new <b>sensors3.conf</b> format and may require manual adjustment. The tool might prompt for user interaction in <b>--interactive</b> mode for sections it cannot confidently convert automatically.


title: DEFAULT INPUT FILE
content:
If no input file is specified using the <b>-c</b> or <b>--config</b> option, <b>sensors-conf-convert</b> will default to processing <b>/etc/sensors.conf</b>. This is the standard location for the <i>lm-sensors</i> configuration file on most Linux distributions.


title: OUTPUT LOCATION
content:
By default, the converted configuration is printed to standard output (<b>stdout</b>). To write it to a file, use the <b>-o</b> or <b>--output</b> option. A common practice is to redirect the output to <b>/etc/sensors3.conf</b> after careful review, for example: <b>sudo sensors-conf-convert -o /etc/sensors3.conf</b>.


title: HISTORY
content:
The <b>sensors-conf-convert</b> utility was introduced as part of the <b>lm-sensors</b> project's transition to <i>libsensors3</i>. This transition brought significant changes to the library's internal architecture, including a revised configuration file format. The old <b>sensors.conf</b> file, primarily used with <i>libsensors2</i>, was replaced by <b>sensors3.conf</b>. This command was developed to ease the migration burden for users by automating the translation of existing configurations, ensuring backward compatibility and a smoother upgrade path for hardware monitoring setups.


title: PARAMETERS
content:
<b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><B>-v</B>, <B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the program version and exits.<br><br><b><B>--auto</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in a less interactive mode, answering 'yes' to most common questions, but still prompting for risky probes.<br><br><b><B>--full-auto</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in a fully non-interactive mode, answering 'yes' to all questions, including potentially risky probes. <I>Use with caution in automated scripts.</I><br><br><b><B>--quiet</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all standard output, only displaying error messages.<br><br><b><B>--force</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides certain warnings, such as not being run as root. <I>Not recommended for general use.</I><br><br>


title: DESCRIPTION
content:
<I>sensors-detect</I> is an interactive command-line utility designed to probe your system for hardware monitoring chips supported by the <I>lm-sensors</I> package.<br><br>It systematically scans various system buses, including I2C/SMBus, ISA, and others, to identify embedded sensor devices capable of reporting vital system statistics such as CPU temperature, fan speeds, and voltage levels. During its operation, it asks a series of questions to guide the detection process, prompting the user for confirmation before probing potentially sensitive areas.<br><br>Upon successful detection, <I>sensors-detect</I> recommends which kernel modules need to be loaded to enable access to these sensors. It often offers to generate a configuration file (e.g., within <B>/etc/modules-load.d/</B> or <B>/etc/modprobe.d/</B>) to ensure these modules are loaded automatically at boot time, making the sensor data available for tools like <I>sensors(1)</I>.


title: CAVEATS
content:
Running <I>sensors-detect</I> generally requires <B>root privileges</B> for probing hardware and configuring kernel modules. While designed to be safe, some probes involve writing to hardware registers and, in rare cases, could potentially cause system instability or require a reboot if incorrect modules are loaded. Always review the suggested changes before confirming them. The detected modules might need to be loaded manually using <B>modprobe</B> or require a system reboot to become active.


title: INTERACTIVE NATURE
content:
The command typically runs interactively, prompting the user with 'yes/no' questions about probing different bus types (e.g., I2C/SMBus, ISA, ACPI) and specific chip addresses. This interactive design allows users to control the depth of the scan and avoid potentially risky or time-consuming probes.


title: KERNEL MODULE MANAGEMENT
content:
After identifying suitable sensor chips, <I>sensors-detect</I> suggests the corresponding kernel modules (e.g., <I>nct6775</I>, <I>coretemp</I>, <I>it87</I>). It usually offers to add these modules to the system's module loading configuration (e.g., <B>/etc/modules-load.d/*.conf</B> or <B>/etc/modprobe.d/*.conf</B>) to ensure they are loaded automatically on subsequent boots. Users can then load them immediately using <B>sudo modprobe <I>module_name</I></B>.


title: HISTORY
content:
<I>sensors-detect</I> is a core utility of the <B>lm-sensors</B> project, which has been under continuous development for decades. Its evolution parallels the increasing complexity and diversity of hardware monitoring chips and the Linux kernel's module system. Initially, it was a manual process to identify and load modules; <I>sensors-detect</I> automated this often intricate task, making hardware monitoring accessible to a broader user base.


title: SYNOPSIS
content:
<b>seq</b> [<i>OPTION</i>]... <i>LAST</i><br><b>seq</b> [<i>OPTION</i>]... <i>FIRST LAST</i><br><b>seq</b> [<i>OPTION</i>]... <i>FIRST INCREMENT LAST</i><br><br>Prints a sequence of numbers from <i>FIRST</i> to <i>LAST</i>, with an increment of <i>INCREMENT</i>. If <i>INCREMENT</i> is omitted, it defaults to 1. If <i>FIRST</i> is omitted, it defaults to 1. If <i>FIRST</i> is greater than <i>LAST</i>, the sequence counts downwards if <i>INCREMENT</i> is negative; otherwise, it produces no output.


title: PARAMETERS
content:
<b>-f, --format=FORMAT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a printf-style <i>FORMAT</i> for outputting numbers (e.g., %.2f for two decimal places).<br><br><b>-s, --separator=STRING</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>STRING</i> to separate numbers (default is a newline character).<br><br><b>-t, --terminator=STRING</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>STRING</i> to terminate the sequence (default is a newline character).<br><br><b>-w, --equal-width</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pad numbers with leading zeros to ensure all numbers have the same width.<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;Display version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>seq</b> command is a command-line utility in Unix-like operating systems that prints a sequence of numbers, one per line by default, to standard output. It's a highly versatile tool, frequently employed in shell scripting to generate numerical iterations for loops, create sequentially named files, or manage numerical ranges for various operations. Users can specify a starting number, an ending number, and an optional increment (step value). The numbers generated can be integers or floating-point values. <b>seq</b> also offers options to customize the output format, such as padding numbers with leading zeros to ensure equal width, or defining custom separators and terminators. Its simplicity and robust functionality make it an indispensable tool for automating tasks that involve numerical progression.


title: CAVEATS
content:
<b>seq</b> uses floating-point arithmetic for its calculations, which can sometimes lead to precision issues with certain decimal values. For operations requiring arbitrary-precision arithmetic, tools like <b>bc(1)</b> might be more suitable. Its output can also be locale-dependent, affecting the decimal point character. While it can generate large sequences, memory constraints could become a factor for extremely long lists.


title: USAGE EXAMPLES
content:
Generate numbers from 1 to 5:<br><code>seq 5</code><br><br>Generate numbers from 5 to 10:<br><code>seq 5 10</code><br><br>Generate numbers from 10 down to 1 with a step of 2:<br><code>seq 10 -2 1</code><br><br>Generate numbers with a custom separator:<br><code>seq -s ',' 1 3</code> (outputs 1,2,3)<br><br>Generate numbers with equal width:<br><code>seq -w 9 11</code> (outputs 09, 10, 11)


title: ARGUMENT INTERPRETATION
content:
The interpretation of numerical arguments (<i>FIRST</i>, <i>INCREMENT</i>, <i>LAST</i>) depends on the number of arguments provided:<br><ul><li>If only one argument is provided, it is taken as <i>LAST</i>.</li><li>If two arguments are provided, they are taken as <i>FIRST</i> and <i>LAST</i>.</li><li>If three arguments are provided, they are taken as <i>FIRST</i>, <i>INCREMENT</i>, and <i>LAST</i> respectively.</li></ul>


title: HISTORY
content:
The <b>seq</b> command is a standard utility included in the GNU Core Utilities, a collection of fundamental tools found in Unix-like operating systems, especially Linux distributions. It was developed as a convenient way to generate numerical sequences directly from the command line, often replacing more verbose shell loop constructs or custom scripts for simple numerical progressions. Its design focuses on simplicity and efficiency for common iteration tasks.


title: PARAMETERS
content:
<b><b>init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new Sequelize project structure, creating default configuration files, models, migrations, and seeders directories.<br><br><b><b>db:migrate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs all pending migrations that have not yet been applied to the database, bringing the schema up to date.<br><br><b><b>db:migrate:undo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undoes the last applied migration, rolling back the database schema change.<br><br><b><b>db:migrate:undo:all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undoes all applied migrations, effectively resetting the database schema to its initial state.<br><br><b><b>db:seed</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs all pending seeders, populating the database with initial or sample data.<br><br><b><b>db:seed:undo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undoes the last applied seeder.<br><br><b><b>model:generate --name=<I>name</I> --attributes=<I>attrs</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new model file and an associated migration file. <I>name</I> is the model's name (e.g., User), and <I>attrs</I> define its attributes (e.g., firstName:string,lastName:string,age:integer).<br><br><b><b>migration:generate --name=<I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new empty migration file with the specified <I>name</I> (e.g., add-user-column).<br><br><b><b>seed:generate --name=<I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new empty seeder file with the specified <I>name</I> (e.g., initial-users-seeder).<br><br><b><b>--help, -h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the main command or a specific subcommand.<br><br><b><b>--version, -v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed version of the Sequelize CLI.<br><br><b><b>--env, -e <I>environment</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the database environment (e.g., development, test, production) to use from the configuration file. Defaults to 'development'.<br><br><b><b>--config, -c <I>path</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Sequelize configuration file (e.g., 'config/config.json').<br><br><b><b>--migrations-path, -i <I>path</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the directory containing migration files (default: 'migrations').<br><br><b><b>--models-path, -m <I>path</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the directory containing model files (default: 'models').<br><br><b><b>--seeders-path, -s <I>path</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the directory containing seeder files (default: 'seeders').<br><br>


title: DESCRIPTION
content:
The <b>sequelize</b> command-line interface (CLI) is a powerful tool designed to manage and interact with database schemas and data when using the <I>Sequelize ORM</I> for Node.js. It simplifies common database operations such as creating and running migrations, generating models and seeders, and initializing new Sequelize projects. <br><br>Unlike traditional Linux commands, <b>sequelize</b> is not a core operating system utility but a JavaScript package installed via <I>npm</I> or <I>yarn</I> within a Node.js development environment. It acts as an orchestrator for managing your application's database state, allowing developers to define database schema changes in a version-controlled manner and apply them across different environments consistently. Its primary use cases revolve around database setup, evolution, and data seeding for development, testing, and production workflows.


title: CAVEATS
content:
The <b>sequelize</b> command is not a native Linux utility. It requires <I>Node.js</I> and a package manager like <I>npm</I> or <I>yarn</I> to be installed. It is typically run within a Node.js project directory that has <I>sequelize-cli</I> listed as a dependency. Its functionality depends on the project's configuration files (e.g., <I>config/config.json</I>) and the specific version of Sequelize ORM being used.


title: USAGE WITH NPX
content:
Since <b>sequelize-cli</b> is often installed as a local project dependency, it's common practice to invoke it using <I>npx</I> (Node Package Execute), for example: <I>npx sequelize db:migrate</I>. This ensures that the version of the CLI installed in the current project's <I>node_modules</I> is used, avoiding global installation conflicts.


title: CONFIGURATION FILES
content:
The behavior of the <b>sequelize</b> command is heavily reliant on configuration files, typically located in a <I>config/</I> directory. The primary file is <I>config.json</I> (or <I>config.js</I>), which defines database connection details for different environments (development, test, production). Other settings like paths to models, migrations, and seeders can also be configured here or overridden via command-line options.


title: HISTORY
content:
Sequelize itself, a promise-based Node.js ORM for Postgres, MySQL, SQL Server, SQLite and MariaDB, was first released in 2010. The <I>sequelize-cli</I> emerged as a separate package to provide a robust command-line interface, simplifying common development tasks like database migrations and model scaffolding. This separation allowed the ORM and its CLI to evolve independently, catering to different aspects of database management in Node.js applications.


title: SYNOPSIS
content:
<b>serialver</b> [ <i>options</i> ] <i>classnames</i><br><i>classnames</i>: One or more fully qualified Java class names (e.g., <code>java.lang.String</code>).


title: PARAMETERS
content:
<b><code>-classpath <i>path</i></code> or <code>-cp <i>path</i></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path where <b>serialver</b> should look for class files. This path can contain directories and JAR archives, separated by the platform-specific path separator (e.g., <code>:</code> on Linux, <code>;</code> on Windows).<br><br><b><code>-show</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a simple graphical user interface (GUI) that allows the user to enter a fully qualified class name and view its <i>serialVersionUID</i>. This option might behave differently or be omitted in headless environments or recent JDK versions.<br><br><b><code>-J<i>flag</i></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes the specified <i>flag</i> directly to the underlying Java Virtual Machine (JVM) that runs <b>serialver</b>. For example, <code>-J-Xmx512m</code> would set the maximum heap size for the JVM.<br><br>


title: DESCRIPTION
content:
<b>serialver</b> is a command-line utility provided with the Java Development Kit (JDK) that returns the <i>serialVersionUID</i> for one or more Java classes. This ID is crucial for Java's object serialization mechanism. When a Java object is serialized (converted into a byte stream for storage or transmission), it carries this unique identifier. Upon deserialization (reconstruction of the object from the byte stream), the <i>serialVersionUID</i> of the serialized object is compared with the <i>serialVersionUID</i> of the class definition currently available in the Java Virtual Machine (JVM). If these IDs do not match, an <i>InvalidClassException</i> is thrown, indicating a version mismatch.<br><br>Developers use <b>serialver</b> to determine the default <i>serialVersionUID</i> generated by the Java compiler. This allows them to explicitly declare this ID in their class definition (e.g., <code>private static final long serialVersionUID = 12345L;</code>) to ensure backward and forward compatibility for serialized objects, especially when class definitions might evolve slightly without breaking serialization compatibility.


title: CAVEATS
content:
<b>serialver</b> is a Java utility and requires a Java Development Kit (JDK) installation to be available in the system's PATH. It is primarily used for Java class files and is not a general-purpose Linux command. The <code>-show</code> GUI option may not function as expected in headless server environments or may be simplified to a modal dialog in newer JDK versions. Its output is specifically for Java's object serialization mechanism.


title: IMPORTANCE OF <I>SERIALVERSIONUID</I>
content:
The <i>serialVersionUID</i> is a version control mechanism for a serialized class. If a class definition changes in a way that is incompatible with previous versions (e.g., changing non-static, non-transient fields), the <i>serialVersionUID</i> should ideally be updated. If <i>serialVersionUID</i> is not explicitly declared in a <i>Serializable</i> class, the Java compiler automatically generates one based on the class's structure. This auto-generated ID can change even for minor, source-compatible changes (like adding a comment or changing method implementation), which can lead to <i>InvalidClassException</i> when deserializing older objects. Explicitly declaring <i>serialVersionUID</i> (e.g., using the ID provided by <b>serialver</b>) ensures that old serialized objects can still be deserialized successfully by a new version of the class, as long as the changes are compatible (e.g., adding new fields or methods without changing existing ones).


title: HISTORY
content:
The <b>serialver</b> utility has been an integral part of the Java Development Kit (JDK) since its early versions, specifically introduced around JDK 1.2. Its purpose emerged with the increasing importance of Java's object serialization API for persistent storage and inter-process communication of Java objects. As Java applications evolved and required version compatibility for serialized data, <b>serialver</b> provided developers with a standardized way to inspect and manage <i>serialVersionUIDs</i>, which became critical for maintaining data integrity across different versions of a class.


title: SYNOPSIS
content:
<b>serve</b> [<i>path</i>] [<i>options</i>]<br><b>serve</b> -l &lt;<i>port</i>&gt; [<i>options</i>]<br><b>serve</b> -s [<i>options</i>]


title: PARAMETERS
content:
<b>[<i>path</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The directory to serve. Defaults to the current working directory (<b>.</b>).<br><br><b>-l, --listen &lt;<i>port</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port on which the server should listen. Defaults to <b>3000</b> or an available port.<br><br><b>-p, --port &lt;<i>port</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>--listen</b>.<br><br><b>-s, --single</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables single-page application (SPA) mode. All non-existent paths will be redirected to <b>index.html</b>.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing more verbose output for troubleshooting.<br><br><b>-c, --config &lt;<i>file</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom configuration file (e.g., <b>serve.json</b>) instead of the default.<br><br><b>-C, --cors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Cross-Origin Resource Sharing (CORS) for all routes, allowing requests from different origins.<br><br><b>-o, --open</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically opens the server URL in your default web browser upon startup.<br><br><b>-n, --no-clipboard</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents copying the server URL to the system clipboard.<br><br><b>-S, --no-etag</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables ETag support, which is used for client-side caching.<br><br><b>-H, --no-compression</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables Gzip and Brotli compression for served files.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and available options for the command.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version number of the <i>serve</i> utility.<br><br>


title: DESCRIPTION
content:
<i>serve</i> is a powerful, zero-configuration command-line HTTP server designed for quickly serving static files, single-page applications (SPAs), and directory listings. Developed by Vercel, it's widely adopted in the Node.js ecosystem for local development, testing build outputs, or sharing files over a network.<br><br>It automatically handles common web server features such as Gzip/Brotli compression, ETag caching, and clean URL redirects (e.g., serving <i>index.html</i> for directory requests). Its simplicity makes it ideal for front-end development with frameworks like React, Vue, or Angular, providing an instant web server without complex setup. <i>serve</i> requires Node.js and is typically installed globally via npm or yarn.


title: CAVEATS
content:
<i>serve</i> is not a standard, built-in Linux command; it must be installed separately via Node.js's package manager (npm or yarn). It is primarily designed for development and simple static file hosting, and while robust, it's generally not recommended for high-traffic, production-grade deployments without a proper reverse proxy (like Nginx) in front of it.


title: INSTALLATION
content:
<i>serve</i> is typically installed globally on your system using npm or yarn:<br><b>npm install -g serve</b><br>or<br><b>yarn global add serve</b><br>This makes the <i>serve</i> command available for use in any directory.


title: CONFIGURATION FILE
content:
For more advanced or persistent configurations, <i>serve</i> supports a <b>serve.json</b> file. Placed in the root of your served directory, this file allows you to define custom rewrites, redirects, headers, environment variables, and more, providing fine-grained control over how assets are served without needing complex command-line arguments every time.


title: HISTORY
content:
<i>serve</i> was originally created by Vercel (formerly Zeit) as part of their ecosystem for deploying web applications, with a focus on static sites and serverless functions. It quickly gained popularity for its 'zero-config' approach and efficiency in providing a local development server. Its ongoing development ensures support for modern web features and performance improvements, cementing its role as a go-to tool for web developers.


title: PARAMETERS
content:
<b>create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new serverless service, often from a template.<br><br><b>deploy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deploys the service to the configured cloud provider.<br><br><b>invoke</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes a deployed function, optionally with test data.<br><br><b>logs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches logs for a specific function.<br><br><b>remove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the deployed service and its resources from the cloud.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about the deployed service.<br><br><b>package</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Packages the service into a deployable artifact without actually deploying it.<br><br><b>plugin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Serverless Framework plugins (install, uninstall, etc.).<br><br><b>print</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the compiled <i>serverless.yml</i>, useful for debugging.<br><br><b>--stage &lt;stageName&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the deployment stage (e.g., <i>dev</i>, <i>prod</i>).<br><br><b>--region &lt;regionName&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the cloud region (e.g., <i>us-east-1</i>).<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows verbose output for more detailed information.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or specific subcommand.<br><br>


title: DESCRIPTION
content:
The <i>serverless</i> command-line interface (CLI) is the primary tool for interacting with the Serverless Framework. This framework enables developers to build, deploy, and manage serverless applications on various cloud providers like AWS Lambda, Google Cloud Functions, Azure Functions, and others. It abstracts away complex infrastructure configurations, allowing developers to focus solely on their application code.<br><br>The CLI provides commands for scaffolding new projects, deploying functions and resources, invoking functions, viewing logs, managing stages, and removing deployed services, significantly streamlining the serverless development workflow. It integrates with cloud provider APIs to automate the provisioning and management of compute, database, and API gateway resources.


title: CAVEATS
content:
<b>Not a standard Linux utility</b>: The <i>serverless</i> command is part of the Serverless Framework, which must be installed globally via npm (Node Package Manager). It is not pre-installed on Linux distributions.<br><b>Requires Node.js</b>: The framework is built on Node.js, so a Node.js runtime environment must be present on the system.<br><b>Cloud Provider Accounts</b>: Requires valid credentials and configurations for cloud providers (e.g., AWS, GCP, Azure) to deploy and manage resources.<br><b>Configuration File</b>: Relies heavily on a <i>serverless.yml</i> configuration file within the service directory to define functions, events, and resources.


title: SERVERLESS.YML
content:
This is the core configuration file for any Serverless Framework service. It defines functions, events that trigger them, cloud resources, plugins, and deployment settings. Understanding its structure and syntax is fundamental to effectively using the <i>serverless</i> command and framework.


title: PLUGINS
content:
The Serverless Framework's functionality can be extended significantly through a rich ecosystem of plugins. These are npm packages that add new commands, modify existing behavior, or integrate with other tools (e.g., <i>serverless-offline</i> for local development, <i>serverless-webpack</i> for bundling code).


title: HISTORY
content:
The Serverless Framework was launched in 2015 (originally as JAWS) by Austen Collins, coinciding with the rapid rise of serverless computing paradigms, particularly AWS Lambda. It quickly gained traction as a pivotal tool for simplifying the deployment and management of serverless applications, abstracting away much of the underlying infrastructure complexity. Its open-source nature and extensibility through a vibrant plugin ecosystem have fostered its widespread adoption and continuous development within the cloud-native community. The framework significantly contributed to popularizing the 'serverless' architectural style.


title: SEE ALSO
content:
aws(1) - AWS Command Line Interface, gcloud(1) - Google Cloud SDK gcloud tool, az(1) - Azure CLI, npm(1) - Node Package Manager


title: SYNOPSIS
content:
<b>service</b> <I>script</I> <I>command</I><br><b>service</b> --status-all<br><b>service</b> <I>script</I> --full-restart


title: PARAMETERS
content:
<b><I>script</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the service's init script, e.g., <I>apache2</I> or <I>sshd</I>.<br><br><b><I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The action to perform on the service, typically one of <I>start</I>, <I>stop</I>, <I>restart</I>, <I>status</I>, <I>reload</I>, or <I>force-reload</I>.<br><br><b>--status-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the status of all available System V init services.<br><br><b>--full-restart</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a complete restart of the service, often equivalent to stopping and then starting.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and usage information for the command.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>service</b> command.<br><br>


title: DESCRIPTION
content:
The <b>service</b> command provides a standardized interface for interacting with System V init scripts located in <I>/etc/init.d/</I>.<br>It allows users to start, stop, restart, or check the status of services managed by these scripts. Prior to <I>systemd</I>, <b>service</b> was the primary method for controlling daemon processes on many Linux distributions (like Red Hat, Fedora, and Debian-based systems). It abstracts away the need to manually navigate to <I>/etc/init.d/</I> and execute scripts directly, offering a cleaner and more user-friendly syntax.<br>While still available on most modern Linux distributions, its functionality is often a wrapper around <I>systemctl</I> for compatibility, as <I>systemd</I> has become the default init system.


title: CAVEATS
content:
The <b>service</b> command is primarily designed for System V init systems.<br>On modern Linux distributions that use <I>systemd</I> (such as CentOS 7+, Ubuntu 15.04+, Debian 8+), <b>service</b> acts largely as a compatibility layer. Commands issued via <b>service</b> are often translated and executed by <I>systemctl</I> internally. This means that while <b>service</b> still works, <I>systemctl</I> is the native and more powerful way to manage services on these systems. Its capabilities for complex service management (like dependency handling, cgroup management) are limited compared to <I>systemctl</I>.


title: COMPATIBILITY LAYER
content:
On <I>systemd</I> powered systems, the <b>service</b> command typically calls the appropriate <I>systemctl</I> command behind the scenes. For instance, <I>service sshd start</I> often translates internally to <I>systemctl start sshd</I>. This ensures backward compatibility for older scripts and user habits.


title: SERVICE STATUS OUTPUT
content:
The output of <I>service --status-all</I> can vary. Services managed by <I>systemd</I> might show their status using <I>systemd</I>'s conventions, while truly <I>init.d</I> managed services might show a <I>[ + ]</I> for running, <I>[ - ]</I> for stopped, or <I>[ ? ]</I> for unknown status.


title: HISTORY
content:
The <b>service</b> command emerged as a simplification tool for administering services managed by System V init scripts. Before <b>service</b>, users often had to manually execute scripts like <I>/etc/init.d/apache2 start</I>.<br><b>service</b> provided a cleaner, more standardized interface, improving usability. It was widely adopted across various Linux distributions. With the advent of alternative init systems like <I>Upstart</I> and especially <I>systemd</I> in the 2010s, the direct role of <b>service</b> diminished. While still included for backward compatibility, its significance is largely overshadowed by <I>systemctl</I> on contemporary systems.


title: PARAMETERS
content:
<b><I>None</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Not applicable: <code>sess_id.1s</code> is not a standard Linux command and therefore has no defined parameters.</I><br><br>


title: DESCRIPTION
content:
<code>sess_id.1s</code> does not correspond to a standard, universally recognized Linux command or utility. The <code>.1s</code> suffix is particularly unusual for a manual page section; standard sections are <code>.1</code> (user commands), <code>.2</code> (system calls), <code>.3</code> (library functions), etc. It is highly probable that this is either a typo, a reference to a custom script or file specific to a particular system, or a misunderstanding of how Linux commands and manual pages are named. Standard Linux distributions do not include a command with this name.<br><br>While 'session ID' is a fundamental concept in operating systems (identifying process groups or login sessions), there isn't a direct <code>sess_id</code> command to retrieve it in this exact format. Information about session IDs is typically obtained through commands like <code>ps</code> (e.g., <code>ps -j</code> to see the <code>SID</code> column) or by examining process environment variables.


title: CAVEATS
content:
The name <code>sess_id.1s</code> is not found in standard Linux command sets or manual pages. Any utility or script named <code>sess_id</code> would be custom-made or part of a specific application's internal structure. Users looking for information about session IDs should refer to system calls like <code>getsid(2)</code> or existing utilities that expose this information, such as the <code>ps</code> command.<br><br>Do not expect <code>sess_id.1s</code> to work on a generic Linux system.


title: UNDERSTANDING SESSION IDS IN LINUX
content:
In Linux, a <I>session ID</I> (SID, sometimes referred to as the <I>session leader</I> process ID) is a unique identifier for a collection of process groups. Typically, a login shell initiates a new session, and all processes spawned from that shell (unless they explicitly detach) will belong to the same session. The session leader is the process that creates the session.<br><br>Session IDs are crucial for job control and for managing processes related to a terminal. For example, when a terminal closes, the session leader often receives a <code>SIGHUP</code> signal, which can then be propagated to other processes in the session.<br><br>While there's no single <code>sess_id</code> command, the <code>ps</code> command with the <B>-j</B> (job format) or <B>s</B> (session format) option can display the <code>SID</code> column, showing the session ID for each process. For example, <code>ps -j</code> will list processes along with their PIDs, PPIDs, PGIDs (process group IDs), and SIDs.


title: PARAMETERS
content:
<b>[<i>package_names</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more names of packages to install. These are typically proprietary software components or codecs (e.g., <code>flashplugin-installer</code>, <code>ubuntu-restricted-extras</code>).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information. (<i>Note: May not be explicitly documented for all versions as it's often an internal utility.</i>)<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the utility. (<i>Note: May not be explicitly documented for all versions as it's often an internal utility.</i>)<br><br>


title: DESCRIPTION
content:
<b>session-installer</b> is a utility primarily used in Ubuntu and its derivatives to facilitate the installation of proprietary software, multimedia codecs, and drivers that cannot be shipped by default due to licensing restrictions. It typically assists in setting up components like MP3 audio decoding, Microsoft TrueType fonts, Adobe Flash Player, and proprietary graphics drivers (e.g., NVIDIA, AMD).<br><br>Rather than being a general package manager, it often acts as an interactive wrapper or a backend component for tools like the "Restricted Formats Installer" or when installing meta-packages such as <i>ubuntu-restricted-extras</i>. It guides the user through license agreements and dependency resolution for these specific, often essential, non-free components, leveraging underlying package management tools like APT. Its purpose is to simplify the post-installation setup for common multimedia and hardware needs, often invoked automatically after a fresh installation or system upgrade.


title: CAVEATS
content:
This command is primarily specific to Ubuntu and Debian-based distributions. It requires an active internet connection to download the necessary packages. It deals with non-free or proprietary software, often necessitating user acceptance of End User License Agreements (EULAs) during the installation process. It is not intended as a general-purpose package management tool like <code>apt</code>.


title: USAGE CONTEXT
content:
<b>session-installer</b> is often invoked automatically by desktop environments, graphical tools like the Software Center (or its successors), or post-installation scripts (e.g., after installing <i>ubuntu-restricted-extras</i>). Users typically do not run it directly from the command line for general package management, but rather interact with a higher-level tool that calls <b>session-installer</b> as a backend.


title: LICENSE ACCEPTANCE
content:
A core function of <b>session-installer</b> is to present and manage the user's acceptance of End User License Agreements (EULAs) for the proprietary software it installs. This interactive step ensures compliance with licensing terms before installation proceeds.


title: HISTORY
content:
The <b>session-installer</b> utility emerged as part of Ubuntu's broader effort to enhance user-friendliness and simplify the post-installation setup of common multimedia codecs and proprietary drivers. It abstracts the complexities of direct <code>apt</code> calls and EULA acceptance, integrating seamlessly with graphical installers and meta-packages like <i>ubuntu-restricted-extras</i>. Its development aligns with Ubuntu's philosophy of providing a complete out-of-the-box experience, despite licensing challenges for certain software components.


title: SYNOPSIS
content:
<i><b>session-migration</b></i> is typically invoked internally by <b>systemd</b> services (e.g., <i>systemd-logind.service</i>) or login managers at user login/logout, rather than directly by users from the command line. It does not possess a standard user-facing command-line synopsis with explicit options or arguments.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;As an internal system component, <b>session-migration</b> typically does not accept direct user-defined command-line parameters. Its behavior is dictated by system configuration and the context in which <i>systemd-logind</i> operates.<br><br>


title: DESCRIPTION
content:
The <b>session-migration</b> component, often implemented as a script or service within the <b>systemd</b> ecosystem, is crucial for managing and migrating user sessions on Linux systems. Its primary role is to ensure a smooth transition and proper registration of user sessions with <i>systemd-logind</i>, especially during system upgrades or when moving from older session management systems (like <i>ConsoleKit</i>) to <i>logind</i>.<br><br>It handles the complexities of session lifecycle, associating a user's login with a specific control group (cgroup) and ensuring correct permissions for devices, power management, and other system resources. This is vital for modern desktop environments to function correctly, allowing features like suspending the system, managing display settings, and accessing hardware devices securely. Unlike many standard Linux commands, <b>session-migration</b> is typically invoked internally by <b>systemd</b> services (e.g., <i>systemd-logind.service</i>) or by display managers (e.g., GDM, LightDM) at login, rather than being a command-line utility directly executed by end-users. Its operation is largely transparent to the user, acting as a behind-the-scenes orchestrator for session integrity.


title: CAVEATS
content:
<b>session-migration</b> is an internal system component and should <i>not</i> be manually executed by users. Improper invocation could lead to broken user sessions, incorrect cgroup assignments, or issues with device access and power management. Its exact implementation details may vary slightly across different Linux distributions and <b>systemd</b> versions.


title: ROLE IN USER SESSIONS
content:
This utility is vital for the correct functioning of modern desktop environments by ensuring that each user session is properly registered with <i>systemd-logind</i>. This registration enables critical functionalities such as: <br><i><b>• Device Permissions:</b></i> Granting the logged-in user proper access to devices (e.g., sound cards, graphics cards).<br><i><b>• Power Management:</b></i> Allowing the user to initiate actions like suspend, hibernate, or shutdown.<br><i><b>• Session Tracking:</b></i> Keeping track of active user sessions, which is crucial for multi-user systems and for enforcing resource limits via cgroups.


title: HISTORY
content:
The concept behind <b>session-migration</b> evolved with the adoption of <b>systemd</b> and its <i>logind</i> component as the primary session manager in many Linux distributions. Prior to <i>logind</i>, session management was often handled by systems like <i>ConsoleKit</i>. As distributions transitioned to <i>systemd</i>, a mechanism was needed to ensure backward compatibility and a smooth migration path for existing sessions, as well as to properly integrate new sessions with <i>logind's</i> cgroup-based session tracking, device management, and power management capabilities. This component addresses that need, ensuring modern desktop environments and services correctly interact with the system's session infrastructure.


title: SYNOPSIS
content:
<b>aa-audit</b> [OPTIONS] <i>&lt;profile_name&gt;</i><br><b>aa-audit</b> [OPTIONS] --file <i>&lt;profile_file&gt;</i>


title: PARAMETERS
content:
<b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output for the command, providing more verbose information about its operations.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the operation. If the specified profile is not currently loaded into the kernel, it will attempt to load it in audit mode.<br><br><b>--file <i>&lt;profile_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an AppArmor profile by its file path instead of its name in the kernel. The profile from the specified file will be loaded into audit mode.<br><br><b>--reload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads the profile after changing its mode. This ensures the mode change takes effect immediately if the profile was already loaded in the kernel.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the <b>aa-audit</b> command and exits.<br><br>


title: DESCRIPTION
content:
The <b>aa-audit</b> command is a utility provided by AppArmor, a Linux security module that allows an administrator to restrict programs' capabilities with per-program profiles. When a profile is in <i>audit mode</i> (also known as <i>complain mode</i>), AppArmor does not enforce the rules defined within that profile. Instead, it permits all operations that would normally be denied by the profile and logs a message for each violation. This mode is particularly useful during the development and testing phases of AppArmor profiles, as it allows administrators to identify and fine-tune profile rules without blocking legitimate application behavior. After a profile has been properly audited and refined, it can then be put into <i>enforce mode</i> using <b>aa-enforce</b>.


title: CAVEATS
content:
<b>aa-audit</b> requires root privileges to execute.<br>When a profile is in audit mode, it does <i>not</i> block any operations; it only logs violations.<br>For the mode change to take effect on a currently running profile, it must be reloaded, which can be done using the <code>--reload</code> option or automatically if loading a profile from a file that wasn't already loaded.


title: SYNONYM WITH AA-COMPLAIN
content:
The <b>aa-audit</b> command is functionally a synonym for <b>aa-complain</b>. Both commands achieve the same result: setting an AppArmor profile into a mode where violations are logged but not prevented. While either can be used, <b>aa-audit</b> explicitly states the intent to audit, which might be preferred for clarity in some contexts.


title: CHECKING PROFILE STATUS
content:
To verify the current mode of an AppArmor profile, you can inspect the contents of the <code>/sys/kernel/security/apparmor/profiles</code> file. A profile name followed by <i>(enforce)</i> indicates enforce mode, while <i>(complain)</i> or <i>(audit)</i> indicates audit/complain mode.


title: HISTORY
content:
AppArmor, and consequently its associated utilities like <b>aa-audit</b>, originated from Immunix and was later acquired by Novell. It was integrated into the Linux kernel mainline in version 2.6.36. <b>aa-audit</b> is a fundamental part of the AppArmor toolkit, providing administrators with the means to safely test and develop security policies without immediately impacting application functionality. Its role has been consistent since AppArmor's widespread adoption, serving as a critical step in the profile lifecycle before enforcement.


title: SEE ALSO
content:
aa-enforce(8), aa-complain(8), aa-disable(8), aa-remove(8), aa-genprof(8), aa-logprof(8), apparmor_parser(8)


title: TLDR
content:
<b>Set a profile to audit mode</b>`sudo aa-audit [profile_name]`<br><b>Set multiple profiles to audit mode</b>`sudo aa-audit [profile1 profile2 ...]`<br><b>Set a profile to audit mode from a specific directory</b>`sudo aa-audit [[-d|--dir]] /[path/to/profiles] [profile_name]`<br><b>Force audit mode even if already applied</b>`sudo aa-audit --force [profile_name]`<br><b>Set a profile to audit mode without reloading it</b>`sudo aa-audit --no-reload [profile_name]`<br><b>Remove audit mode for a profile</b>`sudo aa-audit [[-r|--remove]] [profile_name]`<br><b>Display help</b>`aa-audit [[-h|--help]]`


title: SYNOPSIS
content:
<b>crond</b> [<i>OPTIONS</i>]<br><br><i>Note: <b>crond</b> is typically started automatically as a system service at boot time and not usually invoked directly by users.</i>


title: PARAMETERS
content:
<b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>crond</b> in the foreground, preventing it from detaching from the controlling terminal. This is primarily useful for debugging purposes, allowing output to be seen directly on the console.<br><br><b><b>-x</b> <i>flags</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates debugging output. The <i>flags</i> argument is a comma-separated list of debug categories (e.g., <I>proc</I>, <I>pars</I>, <I>load</I>, <I>sch</I>, <I>test</I>, <I>misc</I>, <I>ext</I>, <I>full</I>) or a bitmask, which vary by <b>crond</b> implementation. This provides verbose information about internal operations to standard error.<br><br><b><b>-c</b> <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where user crontab files are stored. The default location is typically <I>/var/spool/cron</I>. This option is rarely used outside of testing or specialized configurations.<br><br>


title: DESCRIPTION
content:
The <b>crond</b> command refers to the <I>cron daemon</I>, a background process on Unix-like operating systems responsible for executing commands or scripts automatically at specified intervals.<br><br>It continuously monitors configuration files, primarily user-specific crontabs located in <I>/var/spool/cron/</I> and system-wide crontabs such as <I>/etc/crontab</I> and files within <I>/etc/cron.d/</I>, as well as scripts placed in directories like <I>/etc/cron.hourly</I>, <I>/etc/cron.daily</I>, <I>/etc/cron.weekly</I>, and <I>/etc/cron.monthly</I>.<br><br>Every minute, <b>crond</b> wakes up to check if any scheduled tasks are due for execution. When a task is run, its standard output and standard error are typically mailed to the user who owns the crontab (or a specified <I>MAILTO</I> address). <b>crond</b> is crucial for automating routine system maintenance, backups, log rotation, and other time-based administrative or user tasks, ensuring systems remain efficient and well-managed.


title: CAVEATS
content:
<b>crond</b> must be running for scheduled tasks to execute. Its status can usually be checked via <I>systemctl status cron</I> or <I>systemctl status cronie</I>.<br><br>Cron jobs execute with a minimal environment. It is often necessary to explicitly set <I>PATH</I> and other environment variables within the crontab entry or the script it executes.<br><br>Timezone considerations: <b>crond</b> operates based on the system's local time by default. Explicitly setting the <I>TZ</I> variable in a crontab can override this for specific jobs.<br><br>All output (stdout and stderr) from a cron job is typically emailed to the user who owns the crontab or the address specified by the <I>MAILTO</I> variable. If not handled, this output might be lost.<br><br>Ensure crontab files have correct permissions (e.g., 600 for user crontabs, owned by root) to prevent security vulnerabilities.


title: CRONTAB FILE FORMAT
content:
Each line in a crontab file typically consists of six fields, separated by spaces or tabs:<br><i>minute hour day_of_month month day_of_week command</i><br><br>Fields:<br><b>Minute</b> (0-59)<br><b>Hour</b> (0-23)<br><b>Day of Month</b> (1-31)<br><b>Month</b> (1-12 or Jan-Dec)<br><b>Day of Week</b> (0-7 or Sun-Sat, where both 0 and 7 are Sunday)<br><b>Command</b> to be executed<br><br>Wildcards (<i>*</i>) represent "every" unit. Ranges (<i>1-5</i>), lists (<i>1,3,5</i>), and step values (<i>*/5</i>) are also supported.<br><br>Additionally, some special strings exist for convenience: <i>@reboot</i>, <i>@yearly</i>, <i>@annually</i>, <i>@monthly</i>, <i>@weekly</i>, <i>@daily</i>, <i>@hourly</i>, and <i>@midnight</i>.


title: SYSTEM-WIDE VS. USER-SPECIFIC CRONTABS
content:
<b>crond</b> manages two primary types of crontab files:<br><br><b>User-specific Crontabs</b>: Managed by individual users via the <I>crontab -e</I> command. These files are typically stored in <I>/var/spool/cron/&lt;username&gt;</I>. Each user has their own crontab, and commands are executed with their permissions.<br><br><b>System-wide Crontabs</b>: Found in <I>/etc/crontab</I> and files within the <I>/etc/cron.d/</I> directory. These are typically managed by the system administrator or package installations. Unlike user crontabs, entries in these files often include an additional field specifying the user under whom the command should run. Additionally, scripts placed in <I>/etc/cron.hourly</I>, <I>/etc/cron.daily</I>, <I>/etc/cron.weekly</I>, and <I>/etc/cron.monthly</I> are also executed by <b>crond</b>, usually via entries in <I>/etc/crontab</I> itself.


title: HISTORY
content:
The concept of <b>cron</b>, short for "chronos" (Greek for time), dates back to early versions of Unix in the late 1970s. The daemon component, <b>crond</b>, evolved significantly over time. Paul Vixie's <I>Vixie-cron</I> in the late 1980s became a widely adopted standard, introducing features like per-user crontabs and robust logging that were missing in earlier implementations.<br><br>Modern Linux distributions often use <I>cronie</I>, a fork of <I>Vixie-cron</I> that aims for improved security, performance, and compatibility. <b>crond</b> remains a fundamental utility for system automation, demonstrating the enduring need for reliable, time-based job scheduling in Unix-like operating systems.


title: SEE ALSO
content:
<b>crontab(1)</b>: Manage user-specific cron tables., <b>cron(8)</b>: General manual page often referring to the cron system., <b>anacron(8)</b>: Execute commands periodically on systems that are not always running., <b>at(1)</b>: Schedule commands to run once at a specific time., <b>batch(1)</b>: Execute commands when system load permits., <b>systemctl(1)</b>: Control and query the systemd system and service manager (used for managing the cron service).


title: TLDR
content:
<b>Start daemon in the background and check for scheduled commands</b>`crond`<br><b>Start daemon in the foreground and check for scheduled commands</b>`crond -n`<br><b>Send job output from the daemon to the [s]ystem log</b>`crond -s`<br><b>Override default limitations and accept custom crontables</b>`crond -p`<br><b>Inherit crontab file path from environment settings</b>`crond -P`


title: SYNOPSIS
content:
<b>aa-mergeprof</b> [<i>options</i>] {<i>profile_file</i> ... | <b>-i</b> <i>input_file</i> ... <b>-o</b> <i>output_file</i>}


title: PARAMETERS
content:
<b><b>-i</b> <i>&lt;input_file&gt;</i>, <b>--input=</b><i>&lt;input_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an input profile file or a directory containing profiles to be merged. This option can be used multiple times.<br><br><b><b>-o</b> <i>&lt;output_file&gt;</i>, <b>--output=</b><i>&lt;output_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file where the consolidated profile will be written. Required when using <b>-i</b>.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing verbose internal processing information useful for troubleshooting.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, displaying more details about the merge process and actions taken.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the overwrite of the output file if it already exists, without prompting for confirmation.<br><br><b><b>--skip-validate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the validation step of the merged profile, which is normally performed to ensure syntactic correctness.<br><br><b><b>--policy-dir=</b><i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the AppArmor policy directory. Useful for finding includes or context.<br><br><b><b>--profile-name=</b><i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a specific name to the resulting merged profile, overriding any inferred names.<br><br><b><b>--rules-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the command to merge only the rules from input profiles, ignoring declarations or other profile elements.<br><br><b><b>--append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends the merged content to an existing output profile instead of overwriting it.<br><br><b><b>--prepend</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prepends the merged content to an existing output profile instead of overwriting it.<br><br><b><b>--diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a diff-like output, highlighting the changes made during the merge process between input and output.<br><br>


title: DESCRIPTION
content:
The <b>aa-mergeprof</b> command is a utility within the AppArmor security framework designed to combine several AppArmor profiles or profile fragments into a single, consolidated policy file. This tool is invaluable for administrators who manage complex security environments, allowing them to unify modular policies or integrate rules from different sources that apply to the same executable. By intelligently merging rules and declarations, <b>aa-mergeprof</b> helps resolve potential conflicts and streamlines the process of creating and deploying comprehensive AppArmor security policies. It takes one or more input profiles and writes the combined result to a specified output file, simplifying profile management and maintenance.


title: CAVEATS
content:
Incorrectly merging AppArmor profiles can lead to unintended security policy weaknesses, potential rule conflicts, or even break application functionality. Users should have a solid understanding of AppArmor profile syntax and the implications of combining rules. Always test merged profiles thoroughly in a non-production environment before deployment. Manual review of complex merges might be necessary to ensure desired security posture.


title: HISTORY
content:
<b>aa-mergeprof</b> is an integral part of the AppArmor security framework, which originated from Novell/SUSE. Its development stems from the need for robust policy management, especially as AppArmor profiles can become complex and modular. The command was introduced to facilitate the consolidation and maintenance of these profiles, making it easier for administrators to manage and deploy security policies across various applications and system components effectively over time.


title: TLDR
content:
<b>Merge one or more profile files into the default profile directory</b>`sudo aa-mergeprof [file1 file2 ...]`<br><b>Merge profile files into a specific directory</b>`sudo aa-mergeprof [[-d|--dir]] /[path/to/profiles] [file1 file2 ...]`<br><b>Display help</b>`aa-mergeprof [[-h|--help]]`


title: PARAMETERS
content:
<b><b>-r</b>, <b>--recurse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate profiles for child processes spawned by the target application.<br><br><b><b>-d</b> <i>&lt;directory&gt;</i>, <b>--dir=</b><i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where profiles are searched for or where new profiles will be stored.<br><br><b><b>-f</b> <i>&lt;file&gt;</i>, <b>--file=</b><i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process a specific input log file instead of the system's default audit logs.<br><br><b><b>-p</b> <i>&lt;PID&gt;</i>, <b>--profile=</b><i>&lt;PID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiate profiling for a currently running process, identified by its Process ID (PID).<br><br><b><b>-o</b> <i>&lt;output_file&gt;</i>, <b>--output=</b><i>&lt;output_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the generated or updated AppArmor profile to a specified output file.<br><br><b><b>-i</b> <i>&lt;input_file&gt;</i>, <b>--input=</b><i>&lt;input_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific audit log file as input for analysis, bypassing the live system logs.<br><br><b><b>-k</b>, <b>--keep</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When generating a profile, keep any existing profile rules and add new ones, rather than starting from scratch.<br><br><b><b>-U</b>, <b>--update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update an existing AppArmor profile with new rules based on observed behavior, instead of creating a new one.<br><br><b><b>-N</b> <i>&lt;name&gt;</i>, <b>--name=</b><i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assign a specific name to the new profile being generated.<br><br><b><b>-V</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce more detailed and verbose output during the execution process, aiding in debugging.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a concise help message detailing command usage and available options, then exit.<br><br>


title: DESCRIPTION
content:
<i>aa-genprof</i> is a fundamental utility within the AppArmor security framework, meticulously crafted to streamline the creation and refinement of AppArmor security profiles. Instead of the arduous task of manually writing complex rules, <i>aa-genprof</i> intelligently observes an application's behavior as it runs, typically while the application is under AppArmor's <i>complain</i> or <i>audit</i> mode. It diligently analyzes the audit logs emitted by the kernel, pinpoints actions that would be denied by a strict confinement profile, and then interactively prompts the user to either permit or deny these specific actions. This iterative and guided process facilitates the construction of a robust, tailored security profile that rigorously confines an application to only the resources it legitimately requires, thereby significantly minimizing its potential attack surface. It stands as an indispensable tool for securing newly deployed applications or enhancing the security posture of existing ones.


title: CAVEATS
content:
<b>aa-genprof</b> requires root privileges to operate effectively as it interacts directly with the kernel and system-wide AppArmor profiles.<br>For optimal results, the target application should be run in AppArmor's <i>complain</i> or <i>audit</i> mode during the profiling session. The quality of the generated profile is directly proportional to how thoroughly the application's functionalities are exercised during this observation period. It's advisable to run the profiling in a controlled, clean environment to prevent unrelated system activities from influencing the profile generation process.


title: INTERACTIVE PROFILING PROCESS
content:
<b>aa-genprof</b> typically orchestrates an interactive session. It may first guide the user to place the target application into <i>complain</i> mode, then instruct them to thoroughly run the application, exercising all its functionalities. Subsequently, it analyzes the generated audit logs. For each observed action that would otherwise be unconfined, it presents the user with various options (e.g., 'allow read', 'allow write', 'deny', 'generalize path'), enabling a step-by-step construction or refinement of the profile.


title: THOROUGH APPLICATION EXERCISING
content:
The efficacy and completeness of the AppArmor profile produced by <b>aa-genprof</b> are critically dependent on how comprehensively the application's features and workflows are utilized during the profiling phase. All common use cases, edge cases, and even error conditions should be triggered to ensure that every necessary file, network, or capability access permission is accurately captured and included in the profile.


title: HISTORY
content:
AppArmor, originally developed by Immunix and later acquired by Novell, was open-sourced and became a key security feature within SUSE Linux. It was subsequently integrated into the Linux kernel mainline starting with version 2.6.36. <b>aa-genprof</b> has been a cornerstone utility of AppArmor from its early days, designed to mitigate the complexity of profile creation—often considered the most challenging aspect of implementing a Mandatory Access Control (MAC) system. Its interactive approach has always been central to its design, aiming to make robust security profile generation accessible to a broader range of users.


title: TLDR
content:
<b>Start generating a profile for a program</b>`sudo aa-genprof [program_path]`<br><b>Specify a custom directory for profiles</b>`sudo aa-genprof [[-d|--dir]] /[path/to/profiles] [program_path]`<br><b>Specify a custom logfile for profiling</b>`sudo aa-genprof [[-f|--file]] /[path/to/logfile] [program_path]`<br><b>Display help</b>`aa-genprof [[-h|--help]]`


title: PARAMETERS
content:
<b><code>--help</code>, <code>-h</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b><code>--input &lt;file&gt;</code>, <code>-i &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file to read audit messages from. If not specified, <code><b>aa-decode</b></code> reads from standard input (stdin).<br><br><b><code>--output &lt;file&gt;</code>, <code>-o &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file to write decoded messages to. If not specified, output is written to standard output (stdout).<br><br><b><code>--debug</code>, <code>-d</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing more detailed internal information for troubleshooting.<br><br><b><code>--verbose</code>, <code>-v</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output messages.<br><br><b><code>--json</code>, <code>-j</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the decoded messages in JSON format, which can be useful for programmatic parsing.<br><br>


title: DESCRIPTION
content:
<code><b>aa-decode</b></code> is a utility from the AppArmor suite designed to interpret and humanize compressed or encoded AppArmor audit messages found in system logs (e.g., syslog or auditd logs). These messages are often condensed to conserve space and make log analysis challenging directly. By piping log content to <code><b>aa-decode</b></code> or specifying a log file, users can translate cryptic audit entries into a readable format, revealing details about AppArmor policy violations, denials, or other security events. This command is crucial for system administrators and security analysts to understand and debug AppArmor behavior, aiding in security incident response and policy refinement.


title: CAVEATS
content:
<code><b>aa-decode</b></code> specifically decodes AppArmor's internal compressed/encoded audit messages. It will not decode general syslog entries or auditd records that are not AppArmor-specific. Its utility is limited to environments where AppArmor is actively used and generating such messages. The exact format of the input audit messages is critical for successful decoding.


title: USAGE EXAMPLE
content:
To decode AppArmor messages from <code>dmesg</code> output:<br><code>dmesg | grep 'apparmor' | aa-decode</code><br><br>To decode from a specific log file:<br><code>aa-decode -i /var/log/audit/audit.log</code>


title: INPUT FORMAT
content:
<code><b>aa-decode</b></code> expects input messages that contain the AppArmor specific encoding, typically found within audit records logged by the kernel. These often start with <code>AUDIT_APPARMOR_...</code> and contain a field like <code>apparmor="ENCODED_DATA"</code>.


title: HISTORY
content:
<code><b>aa-decode</b></code> is an integral part of the AppArmor security framework, which was initially developed by Immunix and later acquired by Novell (now SUSE). Its primary role has remained consistent: to provide human-readable interpretations of AppArmor's concise audit log entries, aiding in system monitoring and policy refinement.


title: TLDR
content:
<b>Decode a hex string</b>`aa-decode [hexstring]`<br><b>Decode a log file</b>`sudo aa-decode [logfile]`<br><b>Decode logs from stdin (e.g., redirected file)</b>`sudo aa-decode - < [logfile]`<br><b>Display help</b>`aa-decode [[-h|--help]]`


title: PARAMETERS
content:
<b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates profiles without prompting for user confirmation, overwriting existing profiles if necessary.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a simulated run, showing what actions would be taken without actually making any changes to the system.<br><br><b>--no-discover-packages</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the tool from attempting to discover new browser installations through package managers.<br><br><b>--no-confirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes actions without requiring interactive user confirmation (similar to --force, depending on version).<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output, useful for troubleshooting issues.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <i>aa-update-browser</i> utility and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message detailing command usage and available options, then exits.<br><br>


title: DESCRIPTION
content:
<i>aa-update-browser</i> is a utility included with the <i>apparmor-profiles</i> package, designed to enhance system security. Its primary function is to automatically detect installed web browsers, such as Firefox, Chromium, Google Chrome, Opera, Brave, and Vivaldi, on a Linux system. Once detected, it generates or updates their corresponding AppArmor security profiles. These profiles are crucial for confining browser processes, thereby enhancing system security by limiting what the browser can do and access. The command typically requires root privileges to modify system-level security configurations and can operate either interactively (prompting for confirmation) or non-interactively when used with specific options like <i>--force</i>. It plays a vital role in maintaining up-to-date and effective AppArmor confinement for sensitive applications like web browsers, which are frequently targeted in security exploits.


title: CAVEATS
content:
<ul><li>This command typically requires root privileges (e.g., via <b>sudo</b>) to modify AppArmor profiles, which are system-wide security configurations.</li><li>While <i>aa-update-browser</i> generates sensible default profiles, users might need to manually fine-tune these profiles (e.g., using <b>aa-logprof</b> or editing the profile directly) for specific browser extensions or unique use cases to avoid unexpected denials.</li><li>Using options like <i>--force</i> or <i>--no-confirm</i> can overwrite custom profile modifications without warning, so caution is advised when using these in automated scripts.</li></ul>


title: PURPOSE OF APPARMOR PROFILES FOR BROWSERS
content:
AppArmor profiles define what system resources (e.g., files, network access, system capabilities) a program is permitted to access. For web browsers, applying a restrictive AppArmor profile significantly reduces the potential damage from vulnerabilities. Even if an exploit compromises the browser, the AppArmor confinement can prevent the malicious code from accessing sensitive user data outside the browser's designated directories or from performing unauthorized system modifications.


title: INTERACTIVE VS. NON-INTERACTIVE USE
content:
By default, <i>aa-update-browser</i> may operate interactively, prompting the user for confirmation before making changes. This design choice helps prevent unintended modifications. For scripting or automated environments, the <i>--force</i> or <i>--no-confirm</i> options are used to bypass these interactive prompts, allowing the command to run without user intervention.


title: HISTORY
content:
The <i>aa-update-browser</i> utility is part of the <i>apparmor-profiles</i> package, which extends the AppArmor mandatory access control system. Its development reflects the ongoing effort to automate and simplify the application of robust security profiles for commonly used, high-risk applications like web browsers. As browser functionalities and potential attack vectors evolve, tools like <i>aa-update-browser</i> have become crucial for automatically keeping their security profiles up-to-date, thereby providing a dynamic defense against new threats and vulnerabilities without requiring extensive manual configuration from users.


title: TLDR
content:
<b>[l]ist available browser abstraction profiles</b>`sudo aa-update-browser -l`<br><b>Show what changes would be made to a profile without applying them ([d]ry-run)</b>`sudo aa-update-browser -d [path/to/profile]`<br><b>[u]pdate a profile with specific abstractions</b>`sudo aa-update-browser -u [abstraction1,abstraction2,...] [path/to/profile]`<br><b>Remove all abstractions from a profile</b>`sudo aa-update-browser -u '' [path/to/profile]`<br><b>Display help</b>`aa-update-browser -h`


title: TLDR
content:
<b>Add a physical volume to an existing volume group</b>`sudo vgextend [vg1] [/dev/sda1]`<br><b>Add multiple physical volumes to an existing volume group</b>`sudo vgextend [vg1] [/dev/sda1 /dev/sda2 ...]`


title: SYNOPSIS
content:
aa-logprof [<b>-d</b> <i>&lt;directory&gt;</i>] [<b>-f</b> <i>&lt;file&gt;</i>] [<b>-p</b> <i>&lt;profile&gt;</i>] [<b>-n</b>] [<b>--dry-run</b>] [<b>--verbose</b>] [<i>...other_options...</i>]


title: PARAMETERS
content:
<b>-d <directory>, --dir <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory containing <I>AppArmor</I> profiles to scan for updates.<br><br><b>-f <file>, --file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative log file to parse instead of the default system logs (e.g., syslog or auditd logs).<br><br><b>-p <profile>, --profile <profile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes only a specific <I>AppArmor</I> profile, ignoring denials from other profiles.<br><br><b>-n, --no-confirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in non-interactive mode, automatically applying suggested changes without user confirmation. <B>Use with extreme caution</B> as it can lead to overly permissive profiles.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the proposed changes to profiles without actually writing them to disk. Useful for reviewing potential modifications.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, providing more detailed information during the parsing and profiling process.<br><br><b>-a, --append</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends new rules to existing profile rules, rather than attempting to replace or modify them directly.<br><br><b>-r, --replace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replaces existing rules in profiles with the new, suggested rules. This is the default behavior if neither -a nor -r is specified explicitly.<br><br><b>--skip-new-rules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <I>aa-logprof</I> from prompting to add new rules based on logged denials.<br><br><b>--skip-old-rules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <I>aa-logprof</I> from prompting to remove old, unused rules from profiles.<br><br><b>--skip-network</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips prompts for network-related rules, focusing only on file and capability denials.<br><br><b>--skip-mount</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips prompts for mount-related rules, focusing on other types of denials.<br><br><b>--ignore-changes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not automatically save changes at the end of the session. Changes must be explicitly saved if desired.<br><br><b>--write-rules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <I>aa-logprof</I> to write out any pending changes to the profile immediately, even if <B>--ignore-changes</B> is specified. This is often used in conjunction with <B>--no-confirm</B> for automated profile updates.<br><br>


title: DESCRIPTION
content:
aa-logprof is a crucial interactive utility within the <I>AppArmor</I> security framework. Its primary function is to analyze system logs, specifically looking for denial messages generated by <I>AppArmor</I> profiles that are in "complain" or "enforce" mode. When a program attempts an action not explicitly permitted by its <I>AppArmor</I> profile, <I>AppArmor</I> logs a denial. <br><br> <I>aa-logprof</I> parses these logs and presents the user with a series of choices for each detected denial. For instance, if a program tries to access a file that is currently disallowed, <I>aa-logprof</I> will highlight this event and prompt the user to permit the access, deny it, or generalize the rule to cover similar future accesses. This interactive process allows system administrators to incrementally build and refine robust <I>AppArmor</I> profiles tailored to the specific behavior of applications, moving them from a complaining (logging) state to an enforcing (blocking) state with minimal disruption. It significantly simplifies the profile generation and maintenance process, enabling a granular security posture for Linux systems.


title: CAVEATS
content:
The effective use of <I>aa-logprof</I> requires root privileges as it modifies system-level <I>AppArmor</I> profiles. The interactive nature means it can be time-consuming for profiles with many denial events. Users must carefully review each suggested change; blindly accepting recommendations, especially with the <B>--no-confirm</B> option, can lead to overly permissive profiles that compromise security. It relies on the system's logging mechanism; ensuring logs are properly configured and retained is essential for accurate profiling. Furthermore, <I>aa-logprof</I> may not capture all possible execution paths of a complex application, requiring ongoing monitoring and refinement.


title: INTERACTIVE MODE AND WORKFLOW
content:
<I>aa-logprof</I> is predominantly used in an interactive mode. After execution, it presents a series of prompts for each unhandled denial or suggested rule change. Users are given options like 'Allow', 'Deny', 'Glob' (generalize rule), 'Halt' (stop processing), and 'Save'. This iterative process allows for precise tuning of <I>AppArmor</I> profiles. The typical workflow involves running the application, provoking denied actions, and then running <I>aa-logprof</I> to add the necessary rules, repeating until the profile is complete.


title: PROFILE LOCATION
content:
<I>AppArmor</I> profiles are typically stored in the <B>/etc/apparmor.d/</B> directory. <I>aa-logprof</I> will automatically look for profiles in this location unless an alternative directory is specified using the <B>-d</B> or <B>--dir</B> option. The modified profiles need to be reloaded into the kernel for the changes to take effect, which <I>aa-logprof</I> often prompts for or performs automatically upon saving.


title: HISTORY
content:
<I>aa-logprof</I> is an integral component of the <I>AppArmor</I> security framework, which originated at Immunix and was later acquired by Novell (now SUSE). Developed to simplify the process of creating and maintaining <I>AppArmor</I> profiles, it automates the tedious task of manually parsing log files for access violations. Its design allows administrators to interactively refine security policies based on observed application behavior, making it a cornerstone for transitioning applications from an unconfined state to a securely sandboxed environment. Over time, it has evolved with the <I>AppArmor</I> project, adapting to new kernel features and user feedback to provide a more robust and user-friendly profiling experience.


title: TLDR
content:
<b>Interactively review and update profiles based on system logs</b>`sudo aa-logprof`<br><b>Use a specific directory for AppArmor profiles</b>`sudo aa-logprof [[-d|--dir]] /[path/to/profiles]`<br><b>Use a specific log file instead of the default</b>`sudo aa-logprof [[-f|--file]] /[path/to/logfile]`<br><b>Ignore all log entries before the specified mark</b>`sudo aa-logprof [[-m|--logmark]] "[log_marker_text]"`<br><b>Display help</b>`aa-logprof [[-h|--help]]`


title: PARAMETERS
content:
<b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output, providing more verbose information about the command's execution and internal operations. Useful for troubleshooting.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message that summarizes the command's usage and available options, then exits.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output. This may include more details about each listed process or the scanning process itself.<br><br><b>-s, --skip-kernel-threads</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes kernel threads from the list of unconfined processes. Kernel threads are generally not managed by user-space AppArmor profiles and can clutter the output.<br><br>


title: DESCRIPTION
content:
The <b>aa-unconfined</b> command is a utility provided by the AppArmor security framework. Its primary purpose is to identify and list all currently running processes that are <i>not</i> confined by an AppArmor security profile. In a system where AppArmor is enabled, processes are ideally constrained by profiles that define what resources they can access and what actions they can perform. When a process is listed by <b>aa-unconfined</b>, it means it is running without such restrictions, either because no profile exists for its executable, or it has explicitly transitioned to an unconfined state. <br><br>This tool is invaluable for security auditing and ensuring that critical applications are running under appropriate AppArmor policies. It helps administrators identify potential gaps in their security posture, allowing them to create or refine profiles for unconfined applications, thereby reducing the system's attack surface. While an unconfined process isn't necessarily malicious, it represents a potential vector if compromised, as it has full system access.


title: CAVEATS
content:
The <b>aa-unconfined</b> command requires the AppArmor kernel module to be loaded and active for it to function correctly. Its output only indicates processes not confined by AppArmor profiles; it does not imply that these processes are inherently malicious or vulnerable. They simply lack the mandatory access control restrictions that AppArmor provides. On systems with many processes, the output can be extensive, requiring piping to other tools like <I>grep</I> or <I>less</I> for easier analysis.


title: UNDERSTANDING UNCONFINED PROCESSES
content:
A process can be listed as unconfined for several reasons: <br>1. <B>No Profile Exists:</B> The most common reason is that there is no AppArmor profile loaded for the executable being run by the process. <br>2. <B>Explicit Unconfined Transition:</B> An existing profile might contain a rule that explicitly allows a process to transition to an unconfined state, for example, if a specific helper application is not meant to be restricted by AppArmor. <br>3. <B>Kernel Threads:</B> By default (without <i>-s</i>), kernel threads might be listed as unconfined, as they operate outside the scope of user-space AppArmor policies.


title: HISTORY
content:
AppArmor, originally developed by Immunix, was later acquired by Novell and subsequently open-sourced. It emerged as an alternative to SELinux, aiming for a simpler, path-based security policy model. AppArmor was integrated into SUSE Linux Enterprise and gained significant adoption with its inclusion in Ubuntu. The <b>aa-unconfined</b> utility, along with other <b>aa-*</b> tools, was developed as part of the AppArmor suite to provide administrators with the necessary tools for monitoring, managing, and auditing their AppArmor policies and system security posture effectively.


title: TLDR
content:
<b>List unconfined processes using the ss command (default)</b>`sudo aa-unconfined`<br><b>Use netstat instead of ss to detect open network sockets</b>`sudo aa-unconfined --with-netstat`<br><b>Show all processes from /proc with TCP/UDP ports and no AppArmor profiles (more detailed)</b>`sudo aa-unconfined --paranoid`<br><b>Display help</b>`aa-unconfined [[-h|--help]]`


title: PARAMETERS
content:
<b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays verbose output, showing more details about files being processed.<br><br><b><b>-y</b>, <b>--yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically answers "yes" to all prompts, performing cleanup non-interactively. Use with extreme caution as it can lead to unintended deletions.<br><br><b><b>-d</b> <i>&lt;path&gt;</i>, <b>--dir</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative directory path to clean instead of the default <i>/etc/apparmor.d/</i>.<br><br><b><b>-r</b>, <b>--report</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run. Reports which files <i>would</i> be removed without actually deleting them. Highly recommended for testing before actual cleanup.<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>aa-cleanprof</i> is a utility designed to help system administrators manage AppArmor profiles by identifying and removing unused, outdated, or redundant profile files. These files are typically found in <i>/etc/apparmor.d/</i> and its associated cache directory. The tool is particularly valuable after software uninstallations, as it helps clean up leftover AppArmor configurations that are no longer needed, preventing clutter and potential conflicts from stale security rules.<br><br>By default, <i>aa-cleanprof</i> operates interactively, prompting the user for confirmation before deleting each file, which serves as a crucial safety measure against accidental removals. It can also be run in a non-interactive mode for automated scripts, though this requires careful use. It helps maintain a clean and efficient AppArmor security environment by ensuring that only relevant profiles are present on the system.


title: CAVEATS
content:
Using the <b>-y</b> (non-interactive) option without first performing a dry run (<b>-r</b>) or careful manual verification can lead to the unintended deletion of active or custom AppArmor profiles.<br><br><i>aa-cleanprof</i> typically requires root privileges to operate effectively, as it modifies system configuration files within directories like <i>/etc/apparmor.d/</i>.<br><br>It primarily removes profiles that do not correspond to currently installed packages. Custom profiles created manually may also be flagged if their origin isn't clearly discernible by the tool.


title: INTERACTIVE MODE
content:
By default, <i>aa-cleanprof</i> runs in an interactive mode, requiring user confirmation for each profile file it proposes to delete. This interactive behavior is a critical safety feature to prevent accidental or unwanted removals.


title: ROOT PRIVILEGES
content:
Due to its operation on system-wide configuration files and directories, <i>aa-cleanprof</i> must be executed with root privileges (e.g., using <b>sudo</b>) to function correctly and apply changes.


title: HISTORY
content:
AppArmor, originally developed by Immunix and later acquired by Novell (now SUSE), became part of the Linux kernel mainline in version 2.6.36. <i>aa-cleanprof</i> has been a fundamental utility within the AppArmor toolset since its early development, evolving alongside the core project to provide essential profile management and system hygiene capabilities.


title: SEE ALSO
content:
apparmor(7), aa-genprof(8), aa-enforce(8), aa-complain(8), aa-disable(8), aa-logprof(8), aa-status(8)


title: TLDR
content:
<b>Clean a profile to remove unused rules</b>`sudo aa-cleanprof [profile_name]`<br><b>Clean multiple profiles at once</b>`sudo aa-cleanprof [profile1 profile2 ...]`<br><b>Specify the directory containing profiles</b>`sudo aa-cleanprof [[-d|--dir]] /[path/to/profiles] [profile_name]`<br><b>Run silently without prompts</b>`sudo aa-cleanprof [[-s|--silent]] [profile_name]`<br><b>Prevent profile reload after cleaning</b>`sudo aa-cleanprof --no-reload [profile_name]`<br><b>Display help</b>`aa-cleanprof [[-h|--help]]`


title: TLDR
content:
<b>Display the home directory for the current user</b>`xdg-user-dir`<br><b>Display the location of a user directory</b>`xdg-user-dir [DESKTOP|DOWNLOAD|TEMPLATES|PUBLICSHARE|DOCUMENTS|MUSIC|PICTURES|VIDEOS]`


title: DESCRIPTION
content:
The <b>virt-what</b> command is a small shell script that attempts to detect if the current system is running inside a virtual machine and, if so, which hypervisor it is using. It outputs a list of detected hypervisors, one per line, to standard output. This tool is essential for scripts and applications that need to adapt their behavior based on whether they are running on physical hardware or within a virtualized environment. It probes various system characteristics, including DMI information, CPU flags, kernel modules, and device presence, to identify common virtualization platforms such as KVM, VMware, VirtualBox, Xen, Hyper-V, OpenVZ, and LXC.


title: CAVEATS
content:
<b>virt-what</b> makes a best effort to detect virtualization. While generally reliable, it may not be foolproof and could occasionally produce false positives or negatives, especially with newer or less common hypervisors, or heavily customized environments. Its accuracy depends on the underlying system exposing sufficient virtualization indicators. Although <b>virt-what</b> itself doesn't explicitly require root privileges for basic operation, some of the underlying system checks it performs (e.g., reading DMI tables) might benefit from or implicitly rely on elevated permissions for complete information and access.


title: OUTPUT INTERPRETATION
content:
The command outputs one hypervisor name per line if detected. If multiple hypervisors are detected (e.g., a nested virtualization scenario, or a container running within a VM), all will be listed. If no virtualization is detected, the command outputs nothing to standard output and exits with a zero status. Possible outputs include: <I>kvm</I>, <I>vmware</I>, <I>virtualbox</I>, <I>xen</I>, <I>microsoft</I>, <I>hyperv</I>, <I>openvz</I>, <I>lxc</I>, <I>qemu</I>, <I>ibm-systemz</I>, <I>oracle-vm</I>, <I>parallels</I>, <I>bhyve</I>, etc. The output is designed to be easily parsable by scripts and automation tools.


title: EXIT STATUS
content:
<b>virt-what</b> exits with status 0 if it runs successfully (whether or not a hypervisor is detected). A non-zero exit status indicates an error during execution, such as missing required binaries or inability to access necessary system information.


title: HISTORY
content:
<b>virt-what</b> is part of the <I>libvirt</I> project's client utilities, though it's often packaged separately in various Linux distributions. It was developed to provide a simple, reliable, and standardized way for scripts and applications to determine the virtualization status of a system without needing complex parsing of various system files or proprietary APIs. Its development reflects the increasing prevalence of virtualization and the need for applications to be aware of their execution environment, often used in cloud computing and data center automation.


title: TLDR
content:
<b>Detect if you are running in a virtual machine</b>`virt-what`<br><b>Log output of virt-what into a file</b>`virt-what > [path/to/file]`<br><b>Display version</b>`virt-what --version`


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short usage statement for the command.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the AppArmor utility being used.<br><br>


title: DESCRIPTION
content:
<b>aa-teardown</b> is a utility from the AppArmor user-space tools suite designed to unload all currently active AppArmor profiles from the Linux kernel. When executed, this command instructs the kernel to cease enforcing the security rules defined by any loaded AppArmor profiles, effectively disabling AppArmor confinement for all applications that were previously restricted. This action is irreversible without manually reloading profiles or a system reboot. It is typically used for system maintenance, testing, or when transitioning away from AppArmor, but users should be aware that it significantly reduces the system's security posture by removing all active confinement. The command requires root privileges to execute and only affects profiles in kernel memory; it does not delete profile files from the filesystem.


title: CAVEATS
content:
Running <b>aa-teardown</b> requires superuser privileges (e.g., using <b>sudo</b>). This command unloads <i>all</i> AppArmor profiles, effectively removing all confinement. It does not remove profile files from the filesystem; for that, consider using <b>aa-disable(8)</b> for specific profiles or manually deleting the files and rebooting. Unloading all profiles can significantly reduce the system's security posture until profiles are reloaded.


title: GLOBAL IMPACT
content:
It's critical to understand that <b>aa-teardown</b> unloads <i>all</i> currently loaded AppArmor profiles. This means that all applications previously confined by AppArmor will run without any restrictions imposed by AppArmor. If the intent is to disable a specific profile, <b>aa-disable(8)</b> is the appropriate command.


title: PROFILE PERSISTENCE
content:
Using <b>aa-teardown</b> does not remove the AppArmor profile files from the filesystem (typically located in <i>/etc/apparmor.d/</i>). Profiles will likely be reloaded automatically upon the next system boot unless explicitly disabled or removed from their respective directories. For permanent removal or disabling of specific profiles, filesystem operations combined with <b>aa-disable(8)</b> are necessary.


title: HISTORY
content:
AppArmor, including its core utilities like <b>aa-teardown</b>, was initially developed by Immunix and later maintained by Novell and SUSE. It was designed as a proactive security module for Linux, providing Mandatory Access Control (MAC). <b>aa-teardown</b> has been a fundamental part of the AppArmor user-space tools since its early days, consistently serving the purpose of globally unloading profiles from the kernel to manage system security configurations.


title: TLDR
content:
<b>Disable all AppArmor profiles and stop enforcement</b>`sudo aa-teardown`<br><b>Display help</b>`aa-teardown [[-h|--help]]`


title: PARAMETERS
content:
<b>-a, --add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add policies. If a profile with the same name already exists, it is replaced unless <I>-r</I> is used exclusively.<br><br><b>-r, --replace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replace existing policies. This option requires the profile to already be loaded in the kernel.<br><br><b>-R, --remove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove profiles from the kernel. Policies will no longer be enforced or monitored after removal.<br><br><b>-p, --parse-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parse policy files without loading them into the kernel. This mode is useful for syntax checking and validation.<br><br><b>-C, --complain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the specified profiles to complain mode. In this mode, policy violations are logged but not prevented.<br><br><b>-E, --enforce</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the specified profiles to enforce mode. In this mode, policy violations are actively blocked by the kernel.<br><br><b>-I <dir>, --include <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a directory to the include path. This is used by the parser to find included policy fragments.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output messages, displaying only critical errors or essential information.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity of output, providing more detailed information about the parsing and loading process.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message with command options and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information for <b>apparmor_parser</b> and exit.<br><br>


title: DESCRIPTION
content:
<b>apparmor_parser</b> is a fundamental utility for managing AppArmor security profiles on Linux systems. It serves as the primary tool for compiling and manipulating AppArmor policy files, translating human-readable rules into a binary format understood by the AppArmor kernel module. Its core functions include loading new policies, replacing existing ones with updated versions, and removing profiles from the kernel. This command is also invaluable for developing and debugging policies, offering modes to simply parse files for syntax errors without making live system changes. By facilitating the dynamic loading and unloading of security profiles, <b>apparmor_parser</b> enables administrators to enforce fine-grained access control policies for applications, enhancing system security and mitigating potential vulnerabilities.


title: CAVEATS
content:
Using <b>apparmor_parser</b> to load or unload policies typically requires root privileges.<br>Incorrectly configured or malformed policies can lead to application malfunction or system instability.<br>The AppArmor kernel module must be loaded and enabled for policies to take effect and be managed.


title: POLICY MODES AND ENFORCEMENT
content:
AppArmor profiles can operate in 'enforce' or 'complain' mode. <b>apparmor_parser</b> provides direct command-line options (<I>-C</I> for complain, <I>-E</I> for enforce) to switch profiles between these modes, affecting how policy violations are handled (blocked vs. logged).


title: HANDLING INCLUDE PATHS
content:
Complex AppArmor policies often utilize 'includes' to organize and reuse common policy rules. The <I>-I</I> option is critical for specifying additional directories where the parser should search for these included policy fragments, ensuring proper compilation of modular policy sets.


title: HISTORY
content:
AppArmor, and subsequently <b>apparmor_parser</b>, originated from Novell's security efforts, providing a profile-based mandatory access control system for Linux. From its early development, the parser has been a cornerstone utility, enabling the conversion of human-readable policy rules into a format understood by the kernel. It has continuously evolved to support new AppArmor features and policy syntax, becoming an indispensable tool for managing system security profiles across various Linux distributions.


title: TLDR
content:
<b>Load a profile into the kernel</b>`sudo apparmor_parser [[-a|--add]] [profile_file]`<br><b>Replace an existing profile</b>`sudo apparmor_parser [[-r|--replace]] [profile_file]`<br><b>Remove a profile from the kernel</b>`sudo apparmor_parser [[-R|--remove]] [profile_name]`<br><b>Load a profile in complain mode (logs violations but doesn't block)</b>`sudo apparmor_parser [[-C|--complain]] [[-r|--replace]] [path/to/profile]`<br><b>Preprocess a profile (resolve includes) and write binary cache to file</b>`apparmor_parser [[-p|--preprocess]] [[-o|--ofile]] [path/to/output.cache] [[-Q|--skip-kernel-load]] [path/to/profile]`<br><b>Preprocess and print binary profile to stdout without loading</b>`apparmor_parser [[-p|--preprocess]] [[-S|--stdout]] [[-Q|--skip-kernel-load]] [path/to/profile]`<br><b>Replace a profile while skipping cache reads</b>`sudo apparmor_parser [[-r|--replace]] [[-T|--skip-read-cache]] [path/to/profile]`<br><b>Replace a profile, rebuild cache, and write it to a custom directory</b>`sudo apparmor_parser [[-r|--replace]] [[-W|--write-cache]] [[-L|--cache-loc]] /[path/to/cache] [path/to/profile]`


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information for the command and exits.<br><br><b><b>-d</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a simulated run; prints what would be removed without actually deleting any files.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output messages, only displaying errors.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, providing more detailed output during execution.<br><br>


title: DESCRIPTION
content:
<i><b>aa-remove-unknown</b></i> is a utility designed to manage AppArmor profiles by removing those that are no longer needed or recognized by the system.<br><br>It identifies profile files located on disk (typically in <i>/etc/apparmor.d/</i>) that are not currently loaded by the Linux kernel's AppArmor module and are not associated with any installed packages.<br><br>This command is particularly useful for system maintenance, helping to clean up residual profiles after software has been uninstalled or when manually created profiles become stale. By eliminating these unknown or orphaned profiles, <i><b>aa-remove-unknown</b></i> helps maintain a tidy and secure AppArmor environment, preventing potential conflicts or confusion from outdated security policies. It's recommended to use the <i>--dry-run</i> option first to preview changes.


title: CAVEATS
content:
Using <i><b>aa-remove-unknown</b></i> without the <i>--dry-run</i> option will permanently delete profile files from your system. Exercise caution and verify the list of profiles to be removed. Ensure that profiles identified as 'unknown' are truly no longer needed, especially if you manage custom AppArmor profiles manually.


title: HOW 'UNKNOWN' IS DETERMINED
content:
A profile is considered 'unknown' by <i><b>aa-remove-unknown</b></i> if its corresponding file exists on disk (typically in <i>/etc/apparmor.d/</i>) but it is neither currently loaded into the kernel's AppArmor securityfs interface (<i>/sys/kernel/security/apparmor/profiles</i>) nor traceable back to an installed package that provides it. This helps identify profiles that are stale or unmanaged.


title: HISTORY
content:
<i><b>aa-remove-unknown</b></i> is part of the AppArmor user-space utilities, which have evolved alongside the AppArmor security module in the Linux kernel. AppArmor originated with Immunix, was later adopted by Novell (SUSE), and has since become a standard security feature in many Linux distributions. This tool was developed to address the practical need for managing and cleaning up AppArmor profiles as systems change, packages are installed or removed, and profiles might become orphaned or obsolete.


title: TLDR
content:
<b>Perform a dry run to see which profiles would be removed</b>`sudo aa-remove-unknown -n`<br><b>Actually remove the profiles</b>`sudo aa-remove-unknown`<br><b>Display help</b>`aa-remove-unknown [[-h|--help]]`


title: SYNOPSIS
content:
`uv-sync` is typically invoked from the UnrealIRCd installation directory or via a wrapper script. Its exact syntax can vary slightly depending on the UnrealIRCd version and how the script is implemented, but commonly it's used without direct arguments, relying on pre-configured target servers within the script or an accompanying file.<br><br>Common usage might be:<br><I>./uv-sync</I><br><br>Or if parameters are supported (less common for the default script):<br><I>./uv-sync [options] [target_server]</I>


title: DESCRIPTION
content:
`uv-sync` is a utility script distributed with the <I>UnrealIRCd</I> Internet Relay Chat (IRC) daemon. Its primary function is to facilitate the synchronization of configuration files, most notably <I>unrealircd.conf</I>, across multiple linked IRC servers within an <I>UnrealIRCd</I> network. This ensures consistent settings, modules, and oper information throughout the network, which is crucial for stability and proper operation. The script typically automates the process of securely copying the master configuration file from a central server to other remote servers, often leveraging standard secure copy protocols like <I>SCP</I> or <I>RSYNC</I>. While not a standard system-wide command with its own <I>man</I> page, it's an essential tool for administrators managing multi-server <I>UnrealIRCd</I> setups, simplifying configuration deployment and maintenance.


title: CAVEATS
content:
`uv-sync` is a shell script, not a compiled binary, and its exact implementation can vary between UnrealIRCd versions or if customized by an administrator. It typically relies on external tools like <I>SCP</I> or <I>RSYNC</I> for file transfer, meaning these tools and SSH keys or passwordless SSH need to be properly configured on the system for `uv-sync` to function correctly. Its use requires careful attention to file permissions and network security, as it deals with transferring sensitive configuration data.


title: SCRIPT NATURE
content:
`uv-sync` is typically a shell script (<I>.sh</I> or <I>.pl</I>) distributed within the <I>utils/</I> directory of the UnrealIRCd installation. Unlike standard Linux commands that have dedicated manual pages and formal command-line interfaces, `uv-sync`'s operation is often controlled by editing variables directly within the script or via separate configuration files it sources, rather than through command-line arguments. This approach allows for greater flexibility in deployment but means its "parameters" are not standardized.


title: HISTORY
content:
`uv-sync` originated as a supplementary utility within the <I>UnrealIRCd</I> project, designed to address the practical challenge of managing consistent configurations across complex, multi-server IRC networks. Its development evolved alongside <I>UnrealIRCd</I> itself, as administrators sought more automated and reliable methods than manual file transfers. While its core function has remained consistent—synchronizing configuration files—its specific implementation and reliance on underlying tools like <I>SCP</I> have adapted over time. It's an example of a common pattern in open-source projects where shell scripts are provided to automate common administrative tasks.


title: TLDR
content:
<b>Sync the project environment with the lockfile</b>`uv sync`<br><b>Sync and include all optional dependencies</b>`uv sync --all-extras`<br><b>Sync with specific optional dependencies</b>`uv sync --extra [extra_name]`<br><b>Sync only development dependencies</b>`uv sync --only-dev`<br><b>Sync excluding development dependencies</b>`uv sync --no-dev`<br><b>Sync specific dependency groups</b>`uv sync --group [group_name]`<br><b>Check if environment is already synchronized (no changes)</b>`uv sync --check`<br><b>Preview what would be synced without making changes</b>`uv sync --dry-run`


title: SYNOPSIS
content:
<b>jira</b> <i>[global_options]</i> <b>&lt;command&gt;</b> <i>[command_options]</i> <i>[arguments]</i><br><br><i>Examples of common usage:</i><br>&nbsp;&nbsp;<b>jira</b> <b>issue</b> <b>create</b> <i>--project</i> &lt;PROJECT&gt; <i>--summary</i> &lt;SUMMARY_TEXT&gt; <br>&nbsp;&nbsp;<b>jira</b> <b>issue</b> <b>view</b> &lt;ISSUE_KEY&gt; <br>&nbsp;&nbsp;<b>jira</b> <b>search</b> &quot;assignee = currentUser() AND status = 'To Do'&quot; <br>&nbsp;&nbsp;<b>jira</b> <b>transition</b> &lt;ISSUE_KEY&gt; <i>--transition</i> &quot;Done&quot; <br>&nbsp;&nbsp;<b>jira</b> <b>comment</b> <b>add</b> &lt;ISSUE_KEY&gt; <i>--message</i> &quot;Completed this task today.&quot;


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or a specific subcommand.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of the Jira CLI tool currently installed.<br><br><b><b>--server</b> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the base URL of the Jira instance to connect to. This is often configured once.<br><br><b><b>--user</b> <i>&lt;USERNAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the Jira username for authentication.<br><br><b><b>--password</b> <i>&lt;PASSWORD&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the Jira password for authentication. Less secure; API tokens are preferred.<br><br><b><b>--token</b> <i>&lt;TOKEN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a Personal Access Token (PAT) or API token for more secure authentication.<br><br><b><b>&lt;command&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific operation to perform (e.g., <b>issue</b>, <b>search</b>, <b>transition</b>, <b>comment</b>, <b>configure</b>).<br><br><b><b>--project</b> <i>&lt;KEY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the project key (e.g., 'PROJ') for operations like issue creation or filtering.<br><br><b><b>--summary</b> <i>&lt;TEXT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the summary (short description or title) for a new Jira issue.<br><br><b><b>--description</b> <i>&lt;TEXT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the detailed description for a Jira issue.<br><br><b><b>--assignee</b> <i>&lt;USERNAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns an issue to a specific Jira user.<br><br><b><b>--issue</b> <i>&lt;KEY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refers to a specific Jira issue key (e.g., 'PROJ-123') for viewing, updating, or commenting.<br><br><b><b>--transition</b> <i>&lt;NAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the workflow transition to apply to an issue (e.g., 'Done', 'In Progress').<br><br><b><b>--message</b> <i>&lt;TEXT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The content of a comment to add to an issue.<br><br><b><b>--jql</b> <i>&lt;QUERY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A Jira Query Language (JQL) string used for searching and filtering issues.<br><br>


title: DESCRIPTION
content:
The <i>jira</i> command, typically provided by third-party command-line interface (CLI) tools, enables users to interact with Atlassian Jira instances directly from their Linux terminal. It is not a standard utility included with most Linux distributions but rather a specialized client for the Jira platform. These tools streamline workflows by allowing the creation, viewing, updating, and transitioning of issues, adding comments, performing searches, and managing projects without needing to access the web interface. Designed for developers, system administrators, and power users, the <i>jira</i> command facilitates automation through scripting, integration into CI/CD pipelines, and efficient management of large numbers of Jira tasks, significantly enhancing productivity for teams leveraging Jira.


title: CAVEATS
content:
The <i>jira</i> command is typically a third-party tool and not part of the standard Linux utility set. Therefore, it requires manual installation (e.g., via <b>pip</b> for Python-based tools or package managers for other versions). Proper configuration, including the Jira server URL and authentication credentials (like API tokens or personal access tokens), is essential before use. Its exact syntax and available commands can vary significantly between different CLI implementations (e.g., Python-based, Go-based, Node.js-based tools), so users should consult the specific tool's documentation. Security implications of storing credentials on the command line or in configuration files should be carefully considered.


title: INSTALLATION AND CONFIGURATION
content:
Before using a <i>jira</i> CLI tool, it typically requires initial setup. This often involves running a command like <b>pip install jira-cli</b> (for Python-based tools) or downloading a pre-compiled binary. Post-installation, users usually need to run a <b>jira configure</b> command or manually edit a configuration file (e.g., <b>~/.jira.d/config.yml</b>) to provide their Jira server URL, username, and an API token or personal access token for authentication. Some tools support environment variables for sensitive information.


title: COMMON USE CASES
content:
The <i>jira</i> command is extensively used for:<br><ul><li><b>Automating Issue Creation:</b> Scripting the creation of tasks from other systems, monitoring tools, or logs.</li><li><b>Reporting & Analytics:</b> Fetching issue data in bulk for custom reports and data analysis.</li><li><b>Workflow Automation:</b> Automatically transitioning issues based on external events (e.g., Git commits, CI/CD build status, external system updates).</li><li><b>Batch Operations:</b> Updating or commenting on multiple issues simultaneously based on specific criteria.</li><li><b>Quick Lookups:</b> Rapidly checking issue status, details, or assignments without leaving the terminal.</li></ul>


title: HISTORY
content:
The emergence of <i>jira</i> command-line tools is a natural progression driven by the widespread adoption of Atlassian Jira for project management and issue tracking. As organizations increasingly automate workflows and integrate development processes with CI/CD pipelines, the demand for programmatic access to Jira grew. While Atlassian provides a comprehensive REST API, direct command-line clients were developed by the community to abstract the complexities of HTTP requests and JSON parsing, offering a simpler, more intuitive interface for power users and scripters. These tools typically started appearing in the late 2000s and early 2010s, evolving with Jira's features and API versions to provide robust, efficient, and scriptable interactions with the platform.


title: TLDR
content:
<b>List recent issues</b>`jira issue list`<br><b>List issues from the current sprint, assigned to me</b>`jira sprint list --current [[-a|--assignee]] $(jira me)`<br><b>Create a new issue, optionally set a parent issue</b>`jira issue create [[-P|--parent]] [parent]`


title: SYNOPSIS
content:
<I>Navigate to the cloned Prowler directory first:</I><BR><B>cd prowler</B><BR><BR><B>python3 prowler.py [CLOUD_PROVIDER] [OPTIONS]</B><BR><BR><I>Example: Run all AWS CIS checks:</I><BR><B>python3 prowler.py aws --groups cis</B><BR><BR><I>Example: Run specific Azure checks:</I><BR><B>python3 prowler.py azure --checks azure_storage_secure_transfer_required</B>


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the program's help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br><b>--cloud &lt;cloud_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the cloud provider to scan (e.g., <B>aws</B>, <B>azure</B>, <B>gcp</B>).<br><br><b>--checks &lt;check_id,check_id,...&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run specific comma-separated check IDs. E.g., <B>--checks cis_1.1</B>.<br><br><b>--services &lt;service_name,service_name,...&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run checks for specific comma-separated services. E.g., <B>--services s3,ec2</B>.<br><br><b>--groups &lt;group_name,group_name,...&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run checks for specific comma-separated groups (e.g., <B>cis,hipaa,gdpr</B>).<br><br><b>--output-modes &lt;format,format,...&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify desired output formats (e.g., <B>json,csv,html,cli</B>).<br><br><b>--output-directory &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directory where reports will be saved.<br><br><b>--profile &lt;profile_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific cloud provider profile (e.g., AWS CLI named profile).<br><br><b>--region &lt;region_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the cloud region for checks. E.g., <B>us-east-1</B>.<br><br>


title: DESCRIPTION
content:
Prowler is an open-source command-line tool dedicated to comprehensive security assessments, auditing, incident response, continuous monitoring, hardening, and forensics readiness across various cloud environments, including AWS, Azure, and GCP. It empowers organizations to validate their cloud infrastructure's adherence to security best practices and compliance standards like CIS Benchmarks, HIPAA, GDPR, ISO 27001, PCI DSS, and SOC 2. The term "prowler-github" commonly refers to obtaining Prowler by cloning its official GitHub repository, which is the typical deployment method on Linux systems. Once cloned, users execute Prowler using Python, navigating to the tool's directory. It offers a modular design, allowing for the execution of specific checks, entire service groups, or all available checks, providing detailed reports on potential misconfigurations and vulnerabilities. Its flexibility makes it an invaluable asset for various cloud security operations.


title: CAVEATS
content:
The term "prowler-github" is not a standalone Linux command but rather refers to the Prowler tool that is commonly obtained and run from its GitHub repository. <BR>It requires Python 3 and its dependencies to be installed. <BR>Proper cloud provider credentials (e.g., AWS IAM permissions) are essential for Prowler to perform its checks effectively. <BR>It is an assessment tool providing point-in-time snapshots, not a real-time monitoring solution. <BR>Output can be extensive; users should utilize filtering and output options for manageability.


title: INSTALLATION
content:
Typical installation involves cloning the Prowler repository from GitHub and installing its Python dependencies. <BR><B>git clone https://github.com/prowler-cloud/prowler.git</B><BR><B>cd prowler</B><BR><B>pip install -r requirements.txt</B>


title: CLOUD CREDENTIALS
content:
Prowler requires appropriate credentials to interact with your cloud environment. For AWS, this often involves configuring IAM roles, access keys, or using AWS CLI profiles. Similar mechanisms exist for Azure (Service Principals) and GCP (Service Accounts) to grant Prowler the necessary permissions to perform its security checks.


title: HISTORY
content:
Prowler was initially developed by Toni de la Fuente with a focus on AWS security hardening, particularly aligning with CIS Benchmarks. Its open-source nature and ease of use quickly led to its adoption within the cloud security community. Over time, its capabilities expanded significantly to include assessments for other major cloud providers like Azure and GCP, as well as a broader range of compliance frameworks. The project's active development and maintenance primarily occur through its GitHub repository, reflecting its community-driven evolution into a comprehensive cloud security auditing tool.


