# CommandSection

title: OUTPUT FORMATS
content:
When compiling with <b>llvm-gcc</b>, the output format depends on the options used. Using <b>-c</b> will typically produce an LLVM bitcode file (often with a .o or .bc extension), while <b>-S</b> will generate human-readable LLVM assembly (.ll extension). These intermediate files can then be processed further by other LLVM utilities like llc for native code generation or opt for optimization.


title: ROLE IN LLVM ECOSYSTEM
content:
<b>llvm-gcc</b> played a critical role in bootstrapping the LLVM ecosystem. It enabled developers to compile existing codebases into LLVM IR, allowing LLVM's powerful optimization passes and diverse backends to be tested and improved. It was a bridge to demonstrate LLVM's capabilities before the development of a native, tightly integrated front-end like <b>Clang</b>.


title: HISTORY
content:
The development of <b>llvm-gcc</b> began in the early 2000s as a foundational component of the LLVM project. At the time, GCC was the dominant open-source compiler, and LLVM aimed to provide a flexible, retargetable compilation framework. Since building a new front-end from scratch (like <b>Clang</b>) was a massive undertaking, <b>llvm-gcc</b> was created as a pragmatic solution. It allowed the LLVM project to quickly demonstrate its optimization and code generation capabilities by leveraging GCC's well-established language front-ends.<br><br>For several years, <b>llvm-gcc</b> was the primary way to compile C/C++/Objective-C code into LLVM IR. It was used by Apple for their Xcode development environment before they transitioned to <b>Clang</b> as their default compiler. As <b>Clang</b> matured and became a viable, high-performance alternative, the necessity and relevance of <b>llvm-gcc</b> diminished. It was eventually phased out, marking a significant milestone in LLVM's evolution from a backend project to a complete compiler suite.


title: PARAMETERS
content:
<b>-assemble</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assemble the input file. This is the default operation if <i>-disassemble</i> is not specified.<br><br><b>-disassemble</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble the input file, interpreting its contents as machine code.<br><br><b>-arch <architecture></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target architecture for assembly or disassembly, e.g., <i>x86</i>, <i>aarch64</i>, <i>arm</i>.<br><br><b>-mcpu <cpu_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target CPU model for instruction set and performance tuning, e.g., <i>skylake</i> for x86, <i>cortex-a72</i> for AArch64.<br><br><b>-filetype <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file type. Common types include <i>obj</i> (object file), <i>asm</i> (assembly file), or <i>null</i> (discard output).<br><br><b>-output <filename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output filename. If not provided, output is sent to standard output.<br><br><b>-show-encoding</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When disassembling, display the raw byte encoding for each instruction.<br><br><b>-show-inst</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When disassembling, display the internal LLVM instruction representation alongside the assembly.<br><br><b>-triple <triple></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target triple, e.g., <i>x86_64-linux-gnu</i>. This implicitly sets the architecture, vendor, OS, and environment.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a summary of command-line options.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of <i>llvm-mc</i>.<br><br>


title: DESCRIPTION
content:
<i>llvm-mc</i> is a versatile utility within the LLVM project that functions as both a machine code assembler and disassembler. It provides a command-line interface for converting assembly language source code into machine-executable object files, or conversely, for disassembling machine code back into human-readable assembly instructions.<br><br>This tool is invaluable for developers involved in low-level system programming, compiler development, or security research. It allows precise inspection and manipulation of machine code across various architectures supported by LLVM, leveraging LLVM's robust target-independent code generation and machine code emission infrastructure. It's often used for testing new LLVM target backends, analyzing binaries, or understanding the low-level representation of compiled code.


title: CAVEATS
content:
<i>llvm-mc</i>'s functionality is heavily dependent on the specified target architecture and CPU, as it relies on the LLVM backend's support for that specific target. When disassembling raw binary input, ensure the correct architecture is specified. Note that <i>llvm-mc</i> only produces object files and does not perform linking to create executables.


title: TYPICAL USE CASES
content:
<i>llvm-mc</i> is frequently used by LLVM developers for testing new target backends or instruction sets, by security researchers for reverse engineering binaries and analyzing malware, and by low-level programmers for deeply understanding the translation of high-level code into machine instructions. Its ability to read from standard input and write to standard output makes it highly adaptable for integration into automated scripts and complex toolchains.


title: HISTORY
content:
<i>llvm-mc</i> emerged as a fundamental utility within the broader LLVM project, developed to provide a consistent and flexible interface for machine code assembly and disassembly across its expanding array of supported architectures. Its evolution is closely tied to LLVM's growth as a modern compiler infrastructure, aiming to offer a more robust and extensible alternative to traditional, often platform-specific, assemblers and disassemblers by leveraging LLVM's powerful intermediate representation and target description frameworks.


title: PARAMETERS
content:
<b>-a, --debug-syms</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all symbols, including debugger-only symbols.<br><br><b>-D, --dynamic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only dynamic symbols.<br><br><b>-g, --extern-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only external symbols.<br><br><b>-n, --numeric-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort symbols by their address numerically.<br><br><b>-P, --portability</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use POSIX.2 format for the output. This ensures a consistent, parsable format.<br><br><b>-r, --reverse-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverse the order of the sort for the symbols.<br><br><b>-S, --print-size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the size of data symbols in addition to other information.<br><br><b>-t <radix>, --radix=<radix></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display symbol values in the specified radix (d for decimal, o for octal, x for hexadecimal).<br><br><b>-u, --undefined-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only undefined symbols. These are symbols referenced but not defined in the object file.<br><br><b>--defined-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only defined symbols. These are symbols that have a definition within the object file.<br><br><b>--print-file-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Precede each symbol's information with the name of the file it came from, useful when processing multiple files.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief usage message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of <i>llvm-nm</i> and exit.<br><br>


title: DESCRIPTION
content:
<i>llvm-nm</i> is a utility included in the LLVM toolchain designed to list symbols from object files, archives, and shared libraries. It provides information about the symbols defined or referenced within a given binary file, including their <b>name</b>, <b>type</b>, <b>value</b>, and <b>section</b>. This tool is particularly useful for inspecting compiled code, debugging, and understanding the structure of executable binaries or libraries.<br><br>It supports various object file formats commonly used in systems where LLVM is deployed and can also operate on LLVM bitcode files, offering insight into the symbol tables generated by LLVM compilers. It's an essential tool for developers working with C, C++, and other languages compiled by LLVM, offering a modern alternative to the traditional <i>nm</i> command within the LLVM ecosystem.


title: CAVEATS
content:
<i>llvm-nm</i> is designed to integrate seamlessly with the LLVM ecosystem. While it aims for compatibility with GNU <i>nm</i>, there might be subtle differences in output formatting or behavior for certain esoteric flags or specific object file types. It is primarily optimized for object files and bitcode generated by LLVM compilers.


title: SYMBOL TYPE CHARACTERS
content:
The second column of <i>llvm-nm</i>'s output typically shows the type of the symbol. The character can be lowercase or uppercase, with uppercase generally indicating a global or external symbol and lowercase indicating a local symbol.<br>Some common types include:<br><b>A</b>: Absolute symbol<br><b>B</b>: Uninitialized data segment (BSS)<br><b>C</b>: Common symbol<br><b>D</b>: Initialized data segment<br><b>I</b>: Indirect symbol (e.g., PLT entry)<br><b>N</b>: Debug symbol<br><b>R</b>: Read-only data segment<br><b>T</b>: Text (code) segment<br><b>U</b>: Undefined symbol (referenced but not defined in this file)<br><b>W</b>: Weak symbol<br><b>V</b>: Weak object<br><b>-</b>: Stabs debug symbol<br><b>?</b>: Unknown or unsupported symbol type


title: HISTORY
content:
<i>llvm-nm</i> is an integral part of the LLVM project, which originated in 2000 at the University of Illinois Urbana-Champaign. It was developed to provide a modern, modular, and reusable set of compiler technologies. <i>llvm-nm</i> was created as part of this broader initiative to offer symbol table inspection capabilities consistent with the LLVM internal object file model. It serves as a direct replacement for the GNU <i>nm</i> utility within an LLVM-centric development workflow, evolving alongside the general advancement and adoption of the LLVM toolchain.


title: PARAMETERS
content:
<b><b>-d</b>, <b>--disassemble</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble all sections that contain executable instructions.<br><br><b><b>-D</b>, <b>--disassemble-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble all sections in the object file, including data sections.<br><br><b><b>-s</b>, <b>--full-contents</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the full contents of all requested sections.<br><br><b><b>-t</b>, <b>--syms</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the symbol table entries for the object file.<br><br><b><b>-x</b>, <b>--all-headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all available header information, including file, section, and symbol details.<br><br><b><b>-h</b>, <b>--section-headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the contents of the section headers.<br><br><b><b>-S</b>, <b>--source</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Intermix source code with disassembly, if debug information is available.<br><br><b><b>-r</b>, <b>--reloc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the relocation entries in the file.<br><br><b><b>-C</b>, <b>--demangle</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Demangle low-level symbol names into user-level names (e.g., C++ functions).<br><br><b><b>-j</b> &lt;<i>section</i>&gt;, <b>--section</b>=&lt;<i>section</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only process and display information for the specified section.<br><br><b><b>-M</b> &lt;<i>options</i>&gt;, <b>--disassembler-options</b>=&lt;<i>options</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass specific options to the disassembler (e.g., 'att' for AT&T syntax, 'intel' for Intel syntax).<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the command.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of <i>llvm-objdump</i>.<br><br>


title: DESCRIPTION
content:
<i>llvm-objdump</i> is a versatile command-line utility provided as part of the LLVM toolchain. It serves as an object file displayer, allowing users to examine the contents of object files, archives, and executables. Its primary function is to disassemble machine code into human-readable assembly, but it also provides extensive functionality to display various low-level details.<br><br>Users can inspect symbol tables, section headers, relocation entries, and other metadata embedded within the binary. While conceptually similar to the GNU <i>objdump</i> tool, <i>llvm-objdump</i> is specifically designed to work seamlessly with object files produced by LLVM compilers and toolchains. It supports a wide array of object file formats (like ELF, Mach-O, COFF) and architectures.<br><br>This tool is indispensable for software developers, reverse engineers, and security analysts who need to understand the compiled output of their code, debug issues at the machine code level, or analyze third-party binaries.


title: CAVEATS
content:
<b><i>llvm-objdump</i></b> is primarily designed for binaries generated by LLVM toolchains, although it often works with others. Its output format may differ from GNU <b><i>objdump</i></b>, which can affect scripts expecting a specific format. Source intermixing with <b>-S</b> requires presence of debug information.


title: ARCHITECTURE SUPPORT
content:
<b><i>llvm-objdump</i></b> supports a broad spectrum of processor architectures that LLVM targets, including but not limited to x86, ARM, AArch64, MIPS, PowerPC, RISC-V, and many others, reflecting LLVM's widespread applicability across various hardware platforms.


title: HISTORY
content:
<b><i>llvm-objdump</i></b> is an integral part of the LLVM project, an open-source compiler infrastructure. It was developed to provide a native and often more advanced object file analysis tool for the LLVM ecosystem, serving as a counterpart to GNU Binutils' <b><i>objdump</i></b>. Its development has evolved with the LLVM compiler, continuously supporting new architectures, object file formats, and debugging information standards as they are integrated into the LLVM framework. Its modular design allows for flexible extensions and sophisticated analysis capabilities.


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scan the entire file, not just initialized sections.<br><br><b>-f, --print-file-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the name of the file before each string found.<br><br><b>-min-len=<number>, -n <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print sequences of characters that are at least <number> characters long. The default is usually 4.<br><br><b>-o, --offset</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the offset within the file before each string in decimal radix.<br><br><b>-t <format>, --radix=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the offset in the specified radix. Valid formats are 'o' (octal), 'x' (hexadecimal), and 'd' (decimal).<br><br><b>-e <encoding>, --encoding=<encoding></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the character encoding of the strings to find. Options include 's' (single-byte characters, usually ASCII/UTF-8), 'S' (double-byte big-endian), 'b' (double-byte little-endian), 'l' (4-byte little-endian), and 'B' (4-byte big-endian).<br><br><b>--section=<section-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only search for strings within the specified section (e.g., '.text', '.data').<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of <i>llvm-strings</i>.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a summary of command-line options.<br><br>


title: DESCRIPTION
content:
<i>llvm-strings</i> is a powerful utility from the LLVM project, designed to extract sequences of printable characters from specified files. It functions similarly to the standard Unix <i>strings(1)</i> command but is uniquely optimized for inspecting LLVM bitcode files, as well as common executable formats like ELF, Mach-O, and COFF. This tool is invaluable for reverse engineering, debugging, and security analysis, allowing users to uncover embedded text such as error messages, URLs, configuration strings, or other textual data hidden within various sections of a binary, including data, read-only data, and code. It provides flexible options to control string length, character encoding, and output formatting, making it adaptable for diverse analytical needs.


title: CAVEATS
content:
<i>llvm-strings</i> primarily detects printable characters based on the specified encoding; it may not correctly identify obfuscated, compressed, or encrypted strings. The output can be very verbose for large binary files, potentially requiring filtering or redirection.<br>It searches for contiguous sequences of printable characters, which means non-printable bytes within a string will terminate it, potentially splitting legitimate strings.


title: SUPPORTED FILE TYPES
content:
Beyond generic binary files, <i>llvm-strings</i> is proficient at parsing and extracting strings from various specific file types, including LLVM bitcode files, ELF (Executable and Linkable Format), Mach-O (macOS/iOS), and COFF (Common Object File Format) executables, shared libraries, and object files.


title: CHARACTER ENCODING SUPPORT
content:
The command offers robust support for various character encodings, allowing users to accurately extract strings in ASCII, UTF-8, and wide character sets such as UTF-16 and UTF-32 (both big-endian and little-endian), which is crucial for internationalized software analysis.


title: HISTORY
content:
<i>llvm-strings</i> is an integral part of the LLVM project, which commenced development in 2000 at the University of Illinois at Urbana-Champaign. It was developed to provide a specialized utility for extracting strings that seamlessly integrates with the LLVM toolchain, understanding and processing LLVM-specific file formats (like bitcode) in addition to standard executable formats. Its continuous development reflects the evolving needs of analyzing modern compiled binaries and LLVM artifacts.


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message showing available command-line options and exits.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the LMMS version information and exits.<br><br><b><I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an LMMS project file (e.g., <I>.mmp</I> or <I>.mmpz</I>) to open immediately upon launching the application.<br><br>


title: DESCRIPTION
content:
<b>LMMS</b>, short for <I>Linux MultiMedia Studio</I>, is a free and open-source digital audio workstation (DAW) that allows users to produce music by arranging samples, synthesizing sounds, playing on a MIDI keyboard, and combining the features of trackers and sequencers. Designed for musicians and producers, it offers a user-friendly interface to compose, mix, and automate songs.<br><br>Key features include a Song Editor for arranging tracks, a Beat+Bassline Editor for drum patterns and bass lines, a Piano Roll for editing melodies and chords, and a Mixer for adjusting volumes and applying effects. LMMS comes with a variety of built-in virtual instruments (synthesizers) and effects plugins, and also supports industry standards like VST(i) plugins, allowing for extensive sound design possibilities. It aims to provide a complete music production environment without requiring proprietary software.


title: CAVEATS
content:
<b>LMMS</b> is a graphical application and requires a running X server or equivalent display environment. Performance can be resource-intensive, especially when using numerous virtual instruments, effects, or complex VST plugins. While it supports VST plugins, compatibility can sometimes vary, particularly with older 32-bit VSTs on 64-bit systems. LMMS is primarily focused on MIDI sequencing and sample manipulation; it does not offer direct multi-track audio recording capabilities like some other DAWs, though audio samples can be imported.


title: CORE CAPABILITIES
content:
<b>LMMS</b> excels in MIDI sequencing, sample-based composition, and sound synthesis through its array of built-in virtual instruments and support for VSTi plugins. It provides tools for creating intricate melodic lines, complex drum patterns, and full song arrangements, making it ideal for electronic music production, chip-tune, and beat-making.


title: CROSS-PLATFORM AVAILABILITY
content:
While its name suggests Linux, <b>LMMS</b> is actively developed and available for Linux, Windows, and macOS. This cross-platform compatibility allows musicians to collaborate and share projects seamlessly across different operating systems, broadening its appeal and user base.


title: HISTORY
content:
Development of <b>LMMS</b> began in 2004 by Tobias Doerffel, initially aimed at creating a free alternative to commercial music production software, primarily for Linux. The first stable release, version 0.4.0, was made available in 2005. Over the years, the project has grown as a community-driven open-source initiative, expanding its features, improving stability, and porting to other operating systems like Windows and macOS, becoming a truly cross-platform solution for digital music creation.


title: SYNOPSIS
content:
<b>ln</b> [<i>OPTION</i>]... <i>SOURCE</i> [<i>DEST</i>]<br><b>ln</b> [<i>OPTION</i>]... <i>SOURCE</i>... <i>DIRECTORY</i><br><b>ln</b> [<i>OPTION</i>]... <b>-t</b> <i>DIRECTORY</i> <i>SOURCE</i>...


title: PARAMETERS
content:
<b><b>-s</b>, <b>--symbolic</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create symbolic links instead of hard links. This is the most common option when not creating hard links.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove existing destination files or links that would otherwise prevent the link from being created.<br><br><b><b>-i</b>, <b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt before overwriting existing destination files. Overrides <b>-f</b>.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the name of each linked file.<br><br><b><b>-b</b>, <b>--backup</b>[=<i>CONTROL</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make a backup of any existing destination files before overwriting them. <i>CONTROL</i> can specify backup type (e.g., 'numbered', 'existing', 'none').<br><br><b><b>-d</b>, <b>--directory</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow superuser to make hard links to directories. Use with extreme caution as it can lead to filesystem loops and data loss.<br><br><b><b>-P</b>, <b>--physical</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make hard links directly to physical files rather than through symbolic links if <i>SOURCE</i> is a symbolic link. This is the default for hard links.<br><br><b><b>-t</b>, <b>--target-directory</b>=<i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <i>DIRECTORY</i> in which to create the links. This allows specifying the target directory before the sources.<br><br>


title: DESCRIPTION
content:
The <b>ln</b> command is used to create links between files or directories within a Linux filesystem. It supports two primary types of links: <br><br><b>Hard Links:</b> A hard link is essentially another name or directory entry for an existing file. All hard links to a file point to the same inode (data block on disk). This means that if you modify the content of the file through one hard link, it affects all other hard links. Hard links have several characteristics: they must reside on the same filesystem as the original file, they cannot link to directories (by default, and generally discouraged even with superuser privileges), and deleting the original file does not delete the data itself until the last hard link is removed. <br><br><b>Symbolic Links (Soft Links):</b> A symbolic link, often called a symlink or soft link, is a special type of file that contains a text string which is the path to another file or directory. It acts like a pointer or shortcut. Unlike hard links, symbolic links can span different filesystems and can link to directories. If the original file or directory pointed to by a symbolic link is moved or deleted, the symbolic link becomes 'broken' or 'dangling' and will no longer work. Symbolic links are commonly used to create aliases for frequently accessed files or directories, or to provide flexible file organization.


title: CAVEATS
content:
<b>Hard Links:</b> Cannot span filesystems. Cannot link to directories (by default). Deleting the original file does not delete the data itself until the last hard link is removed.<br><b>Symbolic Links:</b> Become 'broken' or 'dangling' if the target file/directory is moved, renamed, or deleted. This can lead to unexpected behavior if not managed properly.<br><b>Security:</b> Creating arbitrary symbolic links can be a security risk (symlink attacks) if permissions are not properly managed, as they can be used to redirect file operations to unintended locations.


title: TYPES OF LINKS
content:
The <b>ln</b> command primarily creates two types of links:<br><b>Hard Links:</b> Direct pointers to the same inode on the filesystem. They share the same data and metadata as the original file. All hard links are equivalent; there is no 'original' once they are created.<br><b>Symbolic Links (Soft Links):</b> These are special files that contain the path to another file or directory. They act like shortcuts. If the target is moved or deleted, the symlink will become broken (dangling).


title: INODES AND HARD LINKS
content:
In Unix-like systems, files are identified by an inode number, which points to the actual data on disk. A hard link is simply an additional directory entry that points to an existing inode. When you create a hard link, the link count for that inode is incremented. The file's data is only truly deleted from disk when its link count drops to zero (i.e., all hard links, including the original file entry, are removed).


title: RELATIVE VS. ABSOLUTE SYMBOLIC LINKS
content:
Symbolic links can store either an absolute path (e.g., <i>/home/user/my_file</i>) or a relative path (e.g., <i>../my_file</i>). Relative links are generally more flexible and portable, as they remain valid even if the link and its target are moved together within the directory structure, as long as their relative positions remain the same. Absolute links are easier to manage if the target is in a fixed, well-known location.


title: HISTORY
content:
The <b>ln</b> command has been a fundamental utility in Unix-like operating systems since their early days. Initially, it primarily supported the creation of hard links. Symbolic links were introduced much later, notably with 4.2 BSD in the early 1980s, to address the limitations of hard links, particularly the inability to link across filesystems or to directories. Modern versions of <b>ln</b>, such as those provided by GNU Coreutils, include numerous extensions and options for greater control over link creation, including backup options and verbose output.


title: PARAMETERS
content:
<b>-d <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens all log files found within the specified <i>directory</i>.<br><br><b>-c <cmd></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the given internal <i>command</i> after all files have been loaded.<br><br><b>-f <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads and executes internal commands from the specified <i>file</i>.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs supplementary files, such as sample configurations or format definitions.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in <b>read-only</b> mode, preventing any accidental modifications or data changes.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tails the specified files or directories, continuously showing new content as it arrives.<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the view from automatically resetting to the bottom when new content is loaded.<br><br><b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the path to <i>lnav</i>'s data directory and then exits.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information for <i>lnav</i> and then exits.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message explaining command-line options and then exits.<br><br>


title: DESCRIPTION
content:
<i>lnav</i> is an advanced, curses-based log file viewer that automatically detects common log formats such as syslog, Apache, Nginx, and various application logs. It offers powerful features like syntax highlighting, filtering, searching (including regular expressions and historical searches), and real-time tailing of multiple log files simultaneously. A standout feature is its <b>built-in SQL query engine</b>, which allows users to execute SQL queries directly against the loaded log data as if it were a relational database. This enables sophisticated analysis, aggregation, and correlation of log entries. <i>lnav</i> also supports decompression of gzipped files, pretty-printing and navigation of structured data like JSON and XML, and can even open logs from URLs. Its intuitive interface and powerful capabilities make it an indispensable tool for system administrators and developers for efficient log troubleshooting and analysis.


title: CAVEATS
content:
While powerful, <i>lnav</i> can consume significant memory and CPU resources when dealing with extremely large log files or numerous concurrently tailed files. The performance of SQL queries is directly dependent on the volume of log data and the complexity of the query. There might be a slight learning curve for users to fully leverage its advanced features, especially the SQL querying capabilities and internal command-line interface. <i>lnav</i> is strictly a log viewer and analyzer; it does not provide any capabilities for modifying the log files themselves.


title: BUILT-IN SQL QUERY ENGINE
content:
Allows users to run SQL queries directly on loaded log data. Log fields are treated as database columns, enabling complex aggregations, filtering, and joins across different log types. This is invaluable for deep analysis and correlation.


title: AUTOMATIC LOG FORMAT DETECTION
content:
Automatically identifies common log formats (e.g., syslog, Apache, Nginx, generic access logs, Android logs) and applies appropriate highlighting and parsing rules without manual configuration.


title: TIME-SERIES VIEW
content:
Provides a visual representation of log messages over time, allowing quick identification of spikes or anomalies in log activity. This view is particularly useful for performance monitoring and troubleshooting.


title: LIVE TAILING AND AGGREGATION
content:
Can tail multiple log files or directories simultaneously, aggregating their output into a single chronological view. This is crucial for monitoring distributed systems or applications with multiple log sources.


title: STRUCTURED DATA SUPPORT
content:
Beyond plain text logs, <i>lnav</i> can pretty-print and navigate structured data like JSON and XML embedded within log messages or as standalone files, making it easier to inspect complex data structures.


title: URL SUPPORT
content:
Allows opening log files directly from HTTP/HTTPS URLs, enabling analysis of remote logs without explicit download.


title: HISTORY
content:
<i>lnav</i> was created by Tim Stack and first released around 2007, evolving from a simple curses-based log viewer into a comprehensive log analysis tool. Its development has focused on integrating advanced features like automatic log format detection and a powerful SQL query engine directly into an interactive terminal interface. Written in C++, it has gained significant popularity in the Linux administration and development communities for its efficiency and unique capabilities.


title: SYNOPSIS
content:
<b>lndir</b> [<i>options</i>] <i>fromdir</i> [<i>todir</i>]<br><br><I>fromdir</I>: The source directory whose structure and contents will be mirrored.<br><I>todir</I>: The target directory where the symbolic link hierarchy will be created. If omitted, `.` (the current directory) is assumed.


title: PARAMETERS
content:
<b><b>-silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output messages for each link created or updated.<br><br><b><b>-nosym</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates hard links instead of symbolic links. Note: Hard links can only be created within the same filesystem and cannot link directories.<br><br><b><b>-ignorelinks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not create links to symbolic links found in the source directory (<i>fromdir</i>). If a symlink is encountered in <i>fromdir</i>, its target will not be linked.<br><br><b><b>-unchanged</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not update entries in <i>todir</i> that already exist and point to the correct, up-to-date file in <i>fromdir</i>. This can speed up operations on large, stable trees.<br><br><b><b>-force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always overwrite existing links or files in <i>todir</i> if they don't match the source, even if the target entry appears to be newer.<br><br><b><b>-dryrun</b>, <b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run without making any changes to the filesystem. This shows what <b>lndir</b> would do.<br><br><b><b>-allow-absolute-links</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If a symbolic link in <i>fromdir</i> is absolute, create an absolute symbolic link in <i>todir</i>. By default, <b>lndir</b> attempts to create relative links where possible.<br><br>


title: DESCRIPTION
content:
<b>lndir</b> is a utility designed to create a parallel directory hierarchy where files are represented by symbolic links (symlinks) to their original counterparts. This tool is particularly useful in development environments, especially when building software, as it allows developers to compile and test code in a separate build tree without duplicating large source files. Instead of copying gigabytes of source code, <b>lndir</b> creates a "shadow" directory structure populated with symlinks pointing back to the original source files. This saves significant disk space and ensures that changes to the source files are immediately reflected in the build tree without requiring a full re-copy.<br><br>When <b>lndir</b> processes a directory, it recursively creates corresponding subdirectories and then creates symlinks for each file found in the source directory. If a target directory already exists, <b>lndir</b> intelligently updates it by creating links for new files and ensuring existing links point to the correct, most recent versions of files, typically by comparing modification times. It can also handle various linking strategies, such as creating hard links instead of symlinks, or ignoring existing symlinks in the source. Its primary benefit lies in providing a convenient, space-efficient method for managing separate build or test environments that rely on a common set of source files.


title: CAVEATS
content:
<b>lndir</b> does not remove files or directories from <i>todir</i> that no longer exist in <i>fromdir</i>. This means <i>todir</i> can accumulate stale entries over time if files are deleted from the source.<br><br>Using `<b>-nosym</b>` for hard links limits functionality to a single filesystem and prevents linking of directories. <br><br>Care must be taken when using `<b>-force</b>` as it can overwrite existing files or links in the target directory, potentially causing data loss if <i>todir</i> contains non-link files that you wish to preserve.


title: UPDATE LOGIC
content:
When updating an existing <i>todir</i>, <b>lndir</b> compares the modification time (mtime) of files. If a source file's mtime is newer than the linked file in <i>todir</i>, or if the link is broken/incorrect, <b>lndir</b> will recreate or update the symbolic link to point to the correct, newer source file. This intelligent update mechanism ensures consistency without unnecessary re-linking.


title: COMMON USE CASES
content:
Beyond software development, <b>lndir</b> can be used to create lightweight, flexible read-only copies of configuration directories, or to set up environments where multiple projects share a common set of assets without duplicating them on disk. It's a space-saving alternative to `cp -r` for situations where changes to the source should be immediately reflected in the target.


title: HISTORY
content:
<b>lndir</b> originated within the X Window System development community, specifically as part of the `imake` build system. It was crucial for managing large source trees and enabling developers to build X in a separate directory without duplicating the entire source code. Its utility for creating shadow build trees made it a staple in many open-source projects that adopted `imake` or similar build methodologies. While modern build systems often provide their own mechanisms for handling out-of-source builds, <b>lndir</b> remains a useful standalone utility for its specific purpose.


title: SYNOPSIS
content:
<B>lnstat</B> [<I>OPTION</I>...]<br><br>Common usage:<br><B>lnstat</B><br><B>lnstat</B> <B>-d</B> <I>delay</I><br><B>lnstat</B> <B>-f</B> <I>file</I>


title: PARAMETERS
content:
<b><B>-f</B> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads statistics from the specified <I>file</I> instead of the default <CODE>/proc/net/stat</CODE>. This is useful for analyzing saved snapshots of statistics.<br><br><b><B>-r</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays raw kernel statistics. This option typically shows more detailed, less human-readable counters directly from the kernel, which might be useful for specific debugging scenarios.<br><br><b><B>-c</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays column headers for the output. Without this option, only the statistical values are shown, making interpretation harder for the first line of output or when new fields appear.<br><br><b><B>-d</B> <I>delay</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Repeats the display of statistics indefinitely, with a <I>delay</I> in seconds between each refresh. Similar to other system monitoring tools like <B>vmstat</B> or <B>iostat</B>, this allows for real-time monitoring of network stack changes.<br><br><b><B>-V</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the <B>lnstat</B> command and exits.<br><br>


title: DESCRIPTION
content:
The <B>lnstat</B> command, part of the widely-used <B>iproute2</B> suite, provides a concise summary of aggregated statistics from various <I>Linux</I> kernel networking subsystems. It retrieves raw data primarily from the <CODE>/proc/net/stat</CODE> virtual filesystem entry, offering insights into low-level network activity.<br><br>Unlike tools such as <B>netstat</B> or <B>ss</B> which focus on active connections and sockets, <B>lnstat</B> delves into system-wide counters related to routing table lookups, neighbor table entries, various <I>IP</I> protocol statistics (<I>IPv4</I>, <I>IPv6</I>, <I>TCP</I>, <I>UDP</I>, <I>ICMP</I>), and more. This makes it invaluable for network administrators and developers debugging performance issues, identifying potential bottlenecks, or monitoring the overall health of the network stack.<br><br>Its output is often dense and requires some understanding of kernel networking internals to interpret fully, but it provides a critical, low-overhead view of how the network stack is behaving at a fundamental level.


title: CAVEATS
content:
The output of <B>lnstat</B> can be quite cryptic and requires familiarity with <I>Linux</I> kernel networking internals to fully interpret. It primarily reports aggregated, system-wide counters, not per-process or per-connection statistics.<br><br>While it generally doesn't require elevated privileges to run (as it reads from <CODE>/proc</CODE> which is often world-readable), some systems or specific configurations might restrict access to the underlying data. The format and content of the statistics can also vary slightly between different kernel versions.


title: HISTORY
content:
<B>lnstat</B> is a utility developed as part of the <B>iproute2</B> project, which was initiated by Alexey Kuznetsov. The <B>iproute2</B> suite emerged as the modern replacement for the traditional <B>net-tools</B> package (<B>ifconfig</B>, <B>route</B>, <B>netstat</B>, etc.) in <I>Linux</I>, leveraging the more advanced <I>Netlink</I> socket interface for interacting with the kernel.<br><br>While many <B>iproute2</B> tools utilize <I>Netlink</I>, <B>lnstat</B> primarily relies on reading directly from the <CODE>/proc</CODE> filesystem, specifically <CODE>/proc/net/stat</CODE>, to gather its aggregated network statistics. Its purpose has remained consistent: to provide a lean, low-level view of the kernel's internal network counters for diagnosis and monitoring.


title: PARAMETERS
content:
<b><i>FONTFILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the PC screen font (.psf) file to be loaded.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for the <i>loadfont</i> utility.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a brief help message and usage information.<br><br>


title: DESCRIPTION
content:
<i>loadfont</i> is a utility used to load a PC screen font (typically in PSF format) into the kernel's console font memory.<br>This command directly affects the appearance of text on the Linux text console (TTYs), allowing users to customize font styles, sizes, and character sets. While historically important for console personalization, it is often a wrapper or symbolic link to the more versatile <i>setfont(8)</i> command on modern Linux distributions. Its primary purpose is to provide an alternative or legacy method for console font management, particularly when dealing with older font formats or specific system setups.


title: CAVEATS
content:
Using <i>loadfont</i> typically requires root privileges to modify kernel console settings. It only affects the text-mode virtual consoles (TTYs) and has no impact on graphical desktop environments.<br>On many contemporary systems, <i>loadfont</i> is a symbolic link or a less commonly used alias for <i>setfont(8)</i>, which offers broader functionality and is the preferred command for console font manipulation.<br>The command expects font files in the PC Screen Font (PSF) format.


title: PC SCREEN FONT (PSF) FORMAT
content:
The <i>loadfont</i> command is designed to load fonts specifically formatted as PC Screen Font (PSF) files. PSF is a simple bitmap font format commonly used on Linux text consoles. These files contain character bitmaps and metadata, allowing for efficient rendering of text in console environments.


title: HISTORY
content:
The <i>loadfont</i> command has been a part of Linux console utilities, often found within the <i>kbd</i> or <i>console-tools</i> packages.<br>It emerged as a dedicated tool for loading PC screen fonts directly into the console, a crucial function for customizing the text-mode interface in early Linux environments.<br>Over time, its functionality has largely been absorbed or superseded by the more comprehensive <i>setfont(8)</i> command, which provides extended control over console fonts and character mappings. Consequently, on many modern distributions, <i>loadfont</i> exists primarily as a compatibility symlink to <i>setfont</i>.


title: PARAMETERS
content:
<b><i>KEYMAP-FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the keymap file to be loaded. If not provided, <b>loadkeys</b> will attempt to load a default keymap or search for a standard one.<br><br><b><b>-b</b>, <b>--bkeymap</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the current keymap in binary format to standard output. This format is not human-readable but can be reloaded faster by <b>loadkeys</b>.<br><br><b><b>-c</b>, <b>--clear</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears the current keymap, effectively disabling all custom key mappings and reverting to a basic default.<br><br><b><b>-d</b>, <b>--default</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the default keyboard map (usually <i>us.map.gz</i> or similar) from the standard keymap directory.<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>-m</b>, <b>--mkeymap</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the current keymap in <b>loadkeys</b> format to standard output. This output can be used as a source for a new keymap file.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warnings and other verbose output, displaying only error messages.<br><br><b><b>-s</b>, <b>--script</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the current keymap in a script format, which can be useful for debugging or programmatic manipulation.<br><br><b><b>-u</b>, <b>--unicode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables loading of Unicode keymaps. This is important for supporting a wide range of characters beyond traditional ASCII.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the keymap loading process.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><b>-w</b>, <b>--console=<i>DEVICE</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the console device to operate on (e.g., <i>/dev/console</i>). By default, <b>loadkeys</b> attempts to determine the active console.<br><br>


title: DESCRIPTION
content:
The <b>loadkeys</b> command is used to change the kernel's keyboard translation table, often referred to as the 'keymap'. This keymap defines how physical key presses on the keyboard are interpreted and translated into characters or actions on the Linux console (TTYs). It's essential for configuring keyboard layouts specific to different languages (e.g., German, French, Spanish) or specialized layouts (e.g., Dvorak). <br><br>When executed, <b>loadkeys</b> reads a specified keymap file, which contains rules for mapping scancodes (raw input from the keyboard) to keycodes, and then keycodes to character outputs, function keys, or other special behaviors. This command is typically run during the system's boot process to set the desired keyboard layout for the console, but it can also be used interactively to temporarily switch layouts.


title: CAVEATS
content:
<b>loadkeys</b> primarily affects the Linux console (TTYs) and generally <I>does not</I> affect graphical environments (like Xorg or Wayland). Graphical environments manage their own keyboard layouts, typically using utilities like <b>setxkbmap</b>. <br><br>Modifying system-wide keymaps usually requires root privileges. Loading an incorrect or corrupted keymap can make your console keyboard unusable, potentially requiring a reboot or access via SSH to fix.


title: KEYMAP FILES
content:
Keymap files are plain text files that define the mapping between keyboard scancodes, keycodes, and the actions produced (characters, function keys, modifier states, etc.). They are typically found in directories like <i>/usr/share/kbd/keymaps/</i>. These files follow a specific syntax, allowing for complex mappings including dead keys for accents, compose sequences, and different shift states.


title: PERSISTENT CONFIGURATION
content:
To ensure a specific keymap is loaded every time the system boots, <b>loadkeys</b> is usually invoked by system initialization scripts or services. On systems using `systemd`, the keymap is often configured via `systemd-vconsole-setup.service`, which reads settings from files like <i>/etc/vconsole.conf</i>. Other distributions might use `init.d` scripts or configuration files such as <i>/etc/default/keyboard</i> to specify the desired keymap.


title: HISTORY
content:
<b>loadkeys</b> is part of the `kbd` package, which provides essential tools for managing the Linux console keyboard and fonts. Its core functionality of loading keyboard maps has been a fundamental part of the Linux console setup since its early days, ensuring multilingual and diverse keyboard support on command-line interfaces. While graphical environments have evolved separate keyboard configuration systems, <b>loadkeys</b> remains the authoritative tool for the text-based console.


title: PARAMETERS
content:
<b><I>driver_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies the name of the Windows driver to explicitly bind or load. In many common uses, this parameter was not directly used with `loadndisdriver` as the binding was managed by the `ndiswrapper` utility, and `loadndisdriver` simply loaded the `ndiswrapper` kernel module itself. If present, it would load the module and attempt to activate the specified driver.<br><br>


title: DESCRIPTION
content:
The `loadndisdriver` command is typically a helper script or an old utility associated with the <I>ndiswrapper</I> project. Its primary purpose is to facilitate the loading of the <I>ndiswrapper</I> kernel module, which enables a Linux system to use Windows NDIS (Network Driver Interface Specification) wireless LAN drivers. <br><br>In environments where native Linux drivers for specific wireless hardware are unavailable or buggy, <I>ndiswrapper</I> provided a crucial workaround. The `loadndisdriver` command, when executed, often ensured that the necessary <I>ndiswrapper</I> kernel module was loaded into the running kernel, making it possible for the system to then utilize pre-installed Windows wireless drivers. While direct interaction with <I>ndiswrapper</I> through its primary utility (`ndiswrapper`) handles the installation and binding of specific Windows drivers, `loadndisdriver` served as a simplified way to activate the <I>ndiswrapper</I> environment, often used in startup scripts to ensure the wireless adapter was functional upon system boot. It's largely considered a legacy solution today, as native Linux wireless support has significantly improved.


title: CAVEATS
content:
<b>Performance and Stability</b>: Using Windows drivers through an abstraction layer can introduce performance overhead and reduce system stability compared to native Linux drivers.<br><b>Security Risks</b>: Windows drivers are not designed for the Linux kernel and could potentially contain vulnerabilities or behave unexpectedly, posing security risks.<br><b>Compatibility</b>: Not all Windows NDIS drivers are compatible with <I>ndiswrapper</I>. Success varies greatly depending on the specific hardware and driver version.<br><b>Legacy Solution</b>: This command and the <I>ndiswrapper</I> project are largely considered legacy. Modern Linux distributions generally offer excellent native wireless driver support, reducing the need for such workarounds.


title: USAGE CONTEXT
content:
The `loadndisdriver` command was not a standalone core Linux utility but rather a component within the <I>ndiswrapper</I> ecosystem. Users would first install the <I>ndiswrapper</I> software, then use the main `ndiswrapper` utility to install Windows `.inf` and `.sys` driver files for their specific wireless adapter. After successful installation, `loadndisdriver` (or more commonly, `modprobe ndiswrapper`) would be used to load the kernel module, enabling the wrapped Windows driver. It was often placed in system startup scripts (`/etc/rc.local` or similar) to ensure the wireless functionality was available at boot.


title: HISTORY
content:
The <I>ndiswrapper</I> project, which `loadndisdriver` is part of, emerged in the early 2000s when Linux's native support for wireless network adapters was significantly lacking. Many popular Wi-Fi chipsets, especially those from Broadcom and others, did not have open-source Linux drivers, forcing users to resort to proprietary drivers or find alternative solutions. <br><br><I>Ndiswrapper</I> filled this gap by providing a wrapper module that allowed the Linux kernel to interface with Windows NDIS drivers. `loadndisdriver` typically served as a simple script to activate this setup, often integrated into boot processes. Its usage peaked before the mid-2010s. With the continuous improvement and inclusion of native open-source and proprietary Linux drivers directly in the kernel or through distributions, the necessity and prevalence of <I>ndiswrapper</I> and its helper scripts like `loadndisdriver` have significantly declined.


title: PARAMETERS
content:
<b>None</b><br>&nbsp;&nbsp;&nbsp;&nbsp;This command, likely a simple script or part of an older <I>ndiswrapper</I> installation's instructions, typically did not accept command-line options or parameters. Its primary function was to execute the necessary steps (e.g., loading the <I>ndiswrapper</I> kernel module) to enable NDIS driver support.<br><br>


title: DESCRIPTION
content:
The <I>loadndisdriver-1.9</I> command is a historical utility or script, primarily associated with the <I>NDISwrapper</I> project. Its purpose was to enable Linux systems to utilize wireless network device drivers originally written for Microsoft Windows' <I>NDIS</I> (Network Driver Interface Specification) standard. During the early 2000s, Linux often lacked robust native driver support for many contemporary wireless chipsets. <I>NDISwrapper</I> filled this critical gap by providing a compatibility layer that allowed the Linux kernel to load and interpret Windows <I>.inf</I> and <I>.sys</I> driver files. <br><br>The <I>loadndisdriver-1.9</I> command, specifically referring to an older version of this ecosystem, would typically be invoked to load the core <I>ndiswrapper</I> kernel module into memory. This action made the NDISwrapper functionality available for configuring and using a Windows-driver-dependent wireless card. It was a crucial step in getting many Wi-Fi cards to work on Linux before widespread native driver support emerged.


title: CAVEATS
content:
This command and the underlying <I>NDISwrapper</I> technology are largely obsolete for modern Linux distributions. <br><br><b>1. Obsolescence:</b> Most contemporary wireless hardware now has excellent native Linux kernel driver support, rendering <I>NDISwrapper</I> unnecessary. <br><b>2. Stability:</b> Using Windows drivers on Linux via a wrapper can lead to instability, crashes, and suboptimal performance compared to native drivers. <br><b>3. Security:</b> Relying on proprietary Windows binary drivers can introduce security risks, as their code is not auditable by the Linux community. <br><b>4. Compatibility:</b> This specific version (<I>1.9</I>) is very old and unlikely to function correctly or integrate well with recent Linux kernels.


title: UNDERLYING KERNEL MODULE
content:
The <I>loadndisdriver-1.9</I> command's core function was to ensure the <I>ndiswrapper.ko</I> kernel module was loaded into the Linux kernel. This module is the heart of the <I>NDISwrapper</I> compatibility layer. Once loaded, it provides the framework necessary to interpret and interface with the Windows NDIS drivers that would have been previously installed using the main <I>ndiswrapper</I> utility (e.g., <I>ndiswrapper -i &lt;driver.inf&gt;</I>).


title: HISTORY
content:
The <I>loadndisdriver</I> concept, and specifically <I>NDISwrapper</I>, emerged in the early 2000s (around 2003-2004) when Linux's support for modern wireless chipsets was notably lacking. Many users were left with non-functional Wi-Fi adapters. <I>NDISwrapper</I> provided a groundbreaking solution, allowing users to leverage Windows drivers. <br><br>Version 1.9 refers to an early stage in the <I>NDISwrapper</I> project's development. Commands like <I>loadndisdriver-1.9</I> were part of the manual, often step-by-step, installation procedures outlined in various online forums and wikis. As Linux kernel development progressed and more native open-source drivers became available (especially for widely used chipsets like Broadcom, Intel, and Realtek), the necessity and prominence of <I>NDISwrapper</I> steadily declined. Today, it is rarely used, except in very specific niche cases involving extremely old or obscure hardware.


title: PARAMETERS
content:
<b>-n <I>requests</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Total number of requests to perform during the test.<br><br><b>-c <I>concurrency</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of concurrent requests or virtual users to simulate.<br><br><b>-p <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing data to be sent in the request body (e.g., for POST requests).<br><br><b>-T <I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the Content-Type header for requests, especially useful for POST data (e.g., "application/json").<br><br><b>-m <I>method</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the HTTP method to use for requests (e.g., GET, POST, PUT, DELETE).<br><br><b>-t <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout for each individual request in seconds.<br><br><b>-H <I>header</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a custom HTTP header to all requests (e.g., "Authorization: Bearer token"). Can be used multiple times.<br><br><b>-A <I>user:pass</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides credentials for HTTP Basic Authentication.<br><br><b>--ssl-no-verify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables SSL certificate verification, useful for testing self-signed certificates or development environments.<br><br><b>--duration <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the load test for a specified duration in seconds, instead of a fixed number of requests.<br><br><b>--rps <I>rate</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the rate of requests to a maximum of 'rate' requests per second.<br><br><b>--csv <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the detailed test results to a specified CSV formatted file.<br><br><b>--json <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the detailed test results to a specified JSON formatted file.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the test execution and results.<br><br>


title: DESCRIPTION
content:
The <b>loadtest</b> command is a powerful, open-source utility designed to simulate concurrent user traffic against web applications and APIs. Developed as a Python package, it helps developers and QA engineers assess the performance, stability, and scalability of their servers under various load conditions. It measures response times, throughput, and error rates, providing crucial insights into how a system behaves when subjected to a high volume of requests. Unlike simpler tools, <b>loadtest</b> offers options for custom headers, POST data, HTTP methods, SSL verification control, and detailed output formats like CSV or JSON, making it suitable for a wide range of testing scenarios from basic URL performance checks to complex API endpoint validations.


title: CAVEATS
content:
The <b>loadtest</b> command is provided by a Python package and is not a standard, pre-installed utility on most Linux distributions. It needs to be installed separately, typically via pip (e.g., <code>pip install loadtest</code>). Its functionality is primarily focused on HTTP/HTTPS load testing for web services.


title: EXAMPLE USAGE
content:
<i>loadtest</i> can be used for various scenarios. <br><br><b>Basic GET request with concurrency:</b><br><code>loadtest -n 1000 -c 100 http://example.com/api/status</code><br><br><b>POST request with JSON data from file:</b><br><code>loadtest -n 500 -c 50 -T application/json -p data.json https://api.example.com/create</code><br><br><b>Test for a specific duration with rate limit:</b><br><code>loadtest --duration 60 --rps 200 http://example.com/homepage</code>


title: HISTORY
content:
The <b>loadtest</b> utility originates from the Python ecosystem, initially developed as a convenient command-line tool for quickly running load tests on web applications and APIs. It leverages Python's capabilities for network requests and data processing, making it accessible and extensible for developers. Its development has focused on providing a balance between ease of use for basic testing and robust options for more complex scenarios, serving as a popular choice for performance validation in agile development environments.


title: PARAMETERS
content:
<b><i>unimapfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Unicode map file to be loaded. If not provided, <i>loadunimap</i> typically reads the map data from standard input. These files usually have a <i>.uni</i> extension and define character mappings for the console.<br><br>


title: DESCRIPTION
content:
<i>loadunimap</i> is a utility program designed to load a Unicode console map (unimap) into the Linux kernel. This map is crucial for systems that need to display Unicode characters correctly on the text console. It translates incoming raw byte sequences (typically from the keyboard or applications) into Unicode characters that the kernel can then render using the currently loaded console font. This command is part of the <b>console-tools</b> or <b>kbd</b> package and is primarily used for setting up internationalization features on non-graphical terminals, enabling correct display of various scripts and symbols beyond the standard ASCII set. It's often used in conjunction with <i>setfont</i> to ensure proper character rendering for console output.


title: CAVEATS
content:
<ul><li>This command primarily affects the <b>Linux text console</b>, not graphical environments (like X11 or Wayland).</li><li>Its functionality might be superseded or managed differently in modern Linux distributions by higher-level tools like <b>systemd's localectl</b>, which provides a unified interface for locale configuration.</li><li>Requires appropriate kernel support for console Unicode mapping.</li><li>Often needs <b>root privileges</b> to load maps into the kernel.</li></ul>


title: UNICODE MAP FILES
content:
Unicode map files (often with an <i>.uni</i> extension) define the mapping from a sequence of bytes (e.g., from a keyboard input or application output) to a Unicode character code. These files are typically text-based and contain rules for combining characters or converting specific byte sequences into their Unicode representations. They are essential for displaying complex scripts or handling various input methods correctly on the Linux console.


title: HISTORY
content:
The <i>loadunimap</i> utility has been a part of the Linux console tools for many years, primarily included within the <b>console-tools</b> or <b>kbd</b> package. Its development was driven by the need to provide proper internationalization support for the Linux text console, allowing users worldwide to correctly display and input non-ASCII characters. It evolved alongside the kernel's console infrastructure to support Unicode, moving beyond earlier character set limitations.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message with available options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program version information.<br><br><b>--by-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report results for each file processed, not just totals.<br><br><b>--by-file-by-lang</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report results for each file, organized by programming language.<br><br><b>--exclude-dir=<dir1,dir2,...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude specified directories from the analysis.<br><br><b>--exclude-ext=<ext1,ext2,...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files with the specified extensions.<br><br><b>--include-lang=<lang1,lang2,...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only count lines for the specified languages.<br><br><b>--csv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in comma-separated values (CSV) format.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON (JavaScript Object Notation) format.<br><br><b>--xml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in XML (Extensible Markup Language) format.<br><br><b>--sum-one-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat single files (e.g., polyglot files) as distinct languages in the summary.<br><br><b>--force-lang=<lang>,<ext1,ext2,...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force files with specified extensions to be counted as a certain language.<br><br><b>--skip-unrecognized</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip files whose language <I>cloc</I> cannot identify.<br><br><b>--vcs=<system></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process files from a specified version control system (e.g., <I>git</I>, <I>svn</I>).<br><br><b>--git</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shortcut for <I>--vcs=git</I>, analyzing files from a Git repository.<br><br><b>--ignored=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save a list of all ignored files to the specified file.<br><br>


title: DESCRIPTION
content:
<b>Disclaimer:</b> The command 'loc' is not a standard Unix/Linux command. This analysis assumes 'loc' is an abbreviation or common reference to <b><I>cloc</I></b> (Count Lines Of Code), a widely used command-line utility for counting lines of code, blank lines, and comments.<br><br><b><I>cloc</I></b> is a free, open-source tool designed to process various file types, including source code files, header files, and configuration files, providing a summary for each language detected and an overall total. It's extensively used by developers and project managers for estimating project size, tracking project progress, and analyzing codebases. The tool supports hundreds of programming languages and can analyze code in local directories, archives (like <I>zip</I>, <I>tar</I>), and even directly from version control repositories like Git and Subversion. Its versatility and accurate language parsing make it an indispensable tool for code metrics.


title: CAVEATS
content:
<b><I>cloc</I></b> relies on file extensions and internal heuristics to identify languages, which might not always be accurate for all edge cases or highly custom file types. It primarily counts physical lines of code, blank lines, and comments; it does not parse code for logical units or functional complexity. Performance can vary significantly based on the number and size of files being analyzed, and processing large codebases can be time-consuming.


title: LANGUAGE RECOGNITION
content:
<b><I>cloc</I></b> employs a robust internal database of language definitions and regular expressions to accurately identify over 200 programming languages, scripting languages, markup languages, and other text-based formats. This sophisticated mechanism allows it to precisely distinguish between executable code, comment lines, and blank lines, adhering to each language's specific syntax rules.


title: OUTPUT FORMATS
content:
Beyond its clear, human-readable console output, <b><I>cloc</I></b> provides various machine-readable output formats, including CSV, JSON, and XML. This flexibility makes it exceptionally easy to integrate into automated workflows, continuous integration/continuous deployment (CI/CD) pipelines, custom reporting tools, and other systems for generating metrics and dashboards programmatically.


title: HISTORY
content:
<b><I>cloc</I></b> was originally developed by Al Danial and first released around 2006. Written in Perl, it rapidly gained popularity due to its extensive language support, impressive processing speed, and cross-platform compatibility. It has since been actively maintained and continuously improved, evolving into a de-facto standard tool within the software development community for generating code metrics and analyzing codebase size.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Declares an indexed array variable.<br><br><b>-A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Declares an associative array variable.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Declares an integer variable.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Declares a nameref (name reference) variable, which acts as an alias for another variable. This is particularly useful for passing variables by reference to functions.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Declares a readonly variable; its value cannot be changed after initialization within the function's scope.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the variable for export to child processes spawned from within the function. While local, it would be exported if a subshell or external command were executed from the function.<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Bash 5.0+) Declares a <I>global</I> variable from within a function, overriding the default local scope. This option is useful for intentionally creating or modifying a global variable from inside a function, such as when a function is designed to set a global status flag.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the attributes and values of currently defined local variables. If no name is provided, all local variables accessible in the current function scope are shown.<br><br><b><I>name</I>[=<I>value</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the variable to declare, optionally initialized with a <I>value</I>. Multiple variables can be declared on a single line, separated by spaces.<br><br>


title: DESCRIPTION
content:
The <b>local</b> command is a <I>shell built-in</I>, primarily used within shell functions in environments like Bash, ksh, and zsh. Its fundamental purpose is to define variables whose scope is restricted to the function in which they are declared. This means the variable exists only for the duration of the function's execution and is not accessible from outside the function, nor does it affect variables with the same name in the global scope or in calling functions.<br><br>Using <b>local</b> is crucial for writing robust and modular shell scripts. It helps prevent unintended side effects, such as a function inadvertently modifying a global variable with the same name, or causing naming conflicts between different parts of a script. It enhances code reusability by ensuring functions are self-contained and operate on their own set of variables.<br><br>While similar to the <b>declare</b> built-in, <b>local</b> implicitly applies the 'local' attribute, making variables function-scoped by default. It supports many of the same options as <b>declare</b> for specifying variable attributes like type (e.g., integer, array) or behavior (e.g., readonly, exported).


title: CAVEATS
content:
<b><I>Behavior Outside Functions:</I></b> If <b>local</b> is invoked outside of a function, it behaves identically to the <b>declare</b> or <b>typeset</b> built-ins, creating or modifying a global variable. This is a common source of confusion and unexpected behavior, as it loses its 'local' scoping property.<br><br><b><I>Variable Shadowing:</I></b> When a local variable is declared with the same name as a global variable, the local variable 'shadows' the global one within the function's scope. Any operations on that variable name inside the function will affect the local variable, leaving the global variable's value unchanged. Once the function exits, the local variable is destroyed, and the original global variable becomes accessible again.<br><br><b><I>Dynamic vs. Lexical Scope (Historical Note):</I></b> In older versions of Bash (pre-5.0), <b>local</b> variables were effectively dynamically scoped for functions called by the current function (i.e., a called function might see the local variable if it didn't declare its own). Modern Bash versions and good scripting practices favor a more predictable lexical scope. The introduction of <b>local -g</b> in Bash 5.0 helps manage intentional interaction with global variables, promoting cleaner scope management.


title: USAGE EXAMPLES
content:
Here are a few examples demonstrating the use of <b>local</b>:<br><br><b><I>Basic Local Variable (Shadowing Global):</I></b><br><br><I>my_function() {<br>&nbsp;&nbsp;local message="Hello from function"<br>&nbsp;&nbsp;echo "Inside: $message"<br>}<br><br>message="Hello from global"<br>echo "Before: $message"<br>my_function<br>echo "After: $message"</I><br><br>Output:<br><I>Before: Hello from global<br>Inside: Hello from function<br>After: Hello from global</I><br><br>Notice how the global 'message' was unaffected by the function's local 'message'.<br><br><b><I>Local Readonly Variable:</I></b><br><br><I>another_function() {<br>&nbsp;&nbsp;local -r MY_CONSTANT=123<br>&nbsp;&nbsp;echo "Constant: $MY_CONSTANT"<br>&nbsp;&nbsp;# MY_CONSTANT=456  # This line would cause an error: readonly variable<br>}<br><br>another_function</I><br><br><b><I>Using local -g (Bash 5.0+ to create/modify global):</I></b><br><br><I>update_global() {<br>&nbsp;&nbsp;local -g GLOBAL_VAR="New Global Value"<br>}<br><br>GLOBAL_VAR="Initial Global Value"<br>echo "Before: $GLOBAL_VAR"<br>update_global<br>echo "After: $GLOBAL_VAR"</I><br><br>Output:<br><I>Before: Initial Global Value<br>After: New Global Value</I>


title: RETURN STATUS
content:
The <b>local</b> built-in returns an exit status of zero (0) upon successful declaration or modification of variables. A non-zero status (typically 1) is returned if an error occurs, such as attempting to use an invalid option, providing an invalid variable name, or trying to declare a variable as readonly that is already set and non-readonly (without using <b>local -g</b> to manage global scope implications). For instance, if you try to declare a variable with an invalid name or an option that doesn't exist, <b>local</b> will return a non-zero exit status.


title: HISTORY
content:
The concept of explicitly scoped variables within functions gained prominence in shell scripting languages to enhance modularity and prevent unintended side effects common with globally scoped variables. The <b>typeset</b> built-in in the Korn Shell (ksh) was one of the early implementations providing variable attributes and local scope.<br><br>Bash adopted this concept, introducing its own <b>local</b> built-in specifically to declare variables with function-local scope. This was a significant step towards enabling more robust and maintainable shell scripts, allowing developers to write self-contained functions without worrying about polluting the global namespace. The design aimed to simplify variable management within functions, making code more predictable and reusable.<br><br>Over the years, Bash has evolved, with notable enhancements like the introduction of <b>local -g</b> in Bash 5.0. This option provides a way to explicitly declare or interact with global variables from within a function, offering greater control over variable scope in complex scripting scenarios, while still emphasizing the primary role of <b>local</b> for function-specific variables.


title: PARAMETERS
content:
<b><I>LOCALE</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more specific locale names (e.g., <i>en_US.UTF-8</i>) to generate, overriding the list in <i>/etc/locale.gen</i> if provided.<br><br><b>--purge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all previously generated locale data that is not explicitly requested in <i>/etc/locale.gen</i> or via command-line arguments.<br><br><b>--no-purge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the removal of any existing locale data. This is often the default behavior.<br><br><b>--gen-archive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces regeneration of the primary locale archive (e.g., <i>/usr/lib/locale/locale-archive</i>) from individual locale files, even if no new locales are generated.<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available locale names that can be generated on the system.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br>


title: DESCRIPTION
content:
<b>locale-gen</b> is a crucial utility that compiles and generates system-wide locale data, which is essential for proper internationalization (i18n) on Linux systems.<br><br>Applications rely on these compiled locales to correctly display language-specific information, including character sets, currency formats, date and time representations, sorting rules, and numeric separators. By default, <b>locale-gen</b> reads the <i>/etc/locale.gen</i> configuration file, which lists the desired locales to be generated (e.g., <i>en_US.UTF-8</i>, <i>de_DE.UTF-8</i>).<br><br>Upon execution, it processes the textual locale definitions found in directories like <i>/usr/share/i18n/locales</i> and creates binary locale archives or individual locale files, typically consolidated into <i>/usr/lib/locale/locale-archive</i>. This optimization significantly speeds up locale lookup by applications.<br><br>While often invoked automatically during system updates or through tools like <b>dpkg-reconfigure locales</b> on Debian-based systems, direct invocation allows administrators to generate specific locales or manage the installed set of locales manually.


title: CAVEATS
content:
<i><b>locale-gen</b> typically requires root privileges to execute because it modifies system-wide files.</i><br><br><i>Changes to <i>/etc/locale.gen</i> do not take effect until <b>locale-gen</b> is run. Generating a large number of locales can consume significant disk space and increase system boot time or initial application loading times.</i><br><br><i>The generated locales affect system-wide settings; individual users might still need to configure their environment variables (e.g., <i>LANG</i>, <i>LC_ALL</i>) to utilize specific locales.</i>


title: CONFIGURATION FILE
content:
The primary configuration for <b>locale-gen</b> is the file <i>/etc/locale.gen</i>. This file contains a list of locale definitions, usually commented out. Uncommenting a line tells <b>locale-gen</b> to generate that specific locale when it is run without arguments. Each entry typically includes the locale name and its character encoding (e.g., <i>en_US.UTF-8</i>).


title: OUTPUT LOCATION
content:
Generated locale data is usually stored in a consolidated locale archive, most commonly at <i>/usr/lib/locale/locale-archive</i>. In some configurations, individual locale files might be placed directly in <i>/usr/lib/locale/</i> directories. Applications consult this archive or these files to obtain locale-specific data.


title: HISTORY
content:
<i><b>locale-gen</b> is an integral part of the <B>GNU C Library (glibc)</B> distribution, which provides fundamental routines for all Linux programs. Its functionality has been crucial since the early days of Linux to enable broad internationalization support. The command's primary role is to efficiently compile human-readable locale definitions into optimized binary formats, a process that has remained largely consistent over its development, adapting to evolving locale standards and character encodings like UTF-8.</i>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show package version and exit.<br><br><b>--no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b>--json=MODE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in JSON format. Mode can be 'short' or 'pretty'.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current system locale and keyboard settings configured for both the virtual console and X11.<br><br><b>set-locale LOCALE...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the system locale. This command updates the <b>/etc/locale.conf</b> file. Multiple locale assignments can be provided (e.g., LANG=en_US.UTF-8 LC_TIME=en_US.UTF-8).<br><br><b>list-locales</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all known locales that are supported by the system.<br><br><b>set-keymap MAP [TOGGLEMAP]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the virtual console (VC) keyboard map. This updates the <b>KEYMAP</b> variable in <b>/etc/vconsole.conf</b>.<br><br><b>list-keymaps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all known virtual console keyboard maps.<br><br><b>set-x11-keymap LAYOUT [MODEL] [VARIANT] [OPTIONS]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the X11 keyboard map. This updates the <b>X11_KEYMAP</b> variables in <b>/etc/vconsole.conf</b>, which are used by Xorg.<br><br><b>list-x11-keymap-rules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all known X11 keymap rules.<br><br><b>list-x11-keymap-models</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all known X11 keymap models.<br><br><b>list-x11-keymap-layouts</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all known X11 keymap layouts.<br><br><b>list-x11-keymap-variants [LAYOUT]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all known X11 keymap variants, optionally filtered by a specific layout.<br><br><b>list-x11-keymap-options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all known X11 keymap options.<br><br>


title: DESCRIPTION
content:
<i>localectl</i> is a powerful command-line utility designed to query and change the system-wide locale and keyboard layout settings on Linux systems. As an integral component of the <br><b>systemd</b> initialization system, it offers a standardized and centralized approach to managing these critical configurations. Unlike older, more fragmented methods, <b>localectl</b> provides a unified interface for both the virtual console (VC) environment and the X11 graphical environment. It seamlessly manages the persistent storage of these settings by writing to and reading from the <br><b>/etc/locale.conf</b> and <b>/etc/vconsole.conf</b> files, ensuring that your chosen language, character set, and keyboard mappings are consistently applied across reboots and different user sessions. This command simplifies the complex task of configuring how your system handles language, character encoding, number formatting, currency, and time, as well as mapping physical keyboard keys to their intended characters.


title: CAVEATS
content:
Changing settings with <b>localectl</b> typically requires root privileges or PolicyKit authentication. <br>While <b>localectl</b> configures X11 keyboard maps, these changes may not take full effect until the display manager or X server is restarted. <br>The command relies heavily on <b>systemd</b> and may not be available or fully functional on non-<b>systemd</b> Linux distributions. <br>Locale changes made by <b>set-locale</b> only affect future processes and system services; existing processes might need to be restarted to pick up new locale settings.


title: CONFIGURATION FILES
content:
<b>localectl</b> manages system-wide settings stored in two primary files: <b>/etc/locale.conf</b> for locale-related settings (e.g., <b>LANG</b>, <b>LC_ALL</b>) and <b>/etc/vconsole.conf</b> for virtual console keyboard mappings (<b>KEYMAP</b>) and font settings.


title: X11 KEYBOARD MAP INTEGRATION
content:
When configuring X11 keyboard maps, <b>localectl</b> interacts with the underlying <b>XKB</b> (X Keyboard Extension) configuration system. It simplifies the selection of layouts, models, variants, and options that would otherwise be configured using lower-level tools like <b>setxkbmap</b> or by directly editing Xorg configuration files.


title: LOCALE CATEGORIES
content:
The <b>set-locale</b> command allows setting various locale categories like <b>LANG</b> (general locale), <b>LC_CTYPE</b> (character classification and conversion), <b>LC_NUMERIC</b> (numeric formatting), <b>LC_TIME</b> (date and time formatting), <b>LC_MONETARY</b> (currency formatting), and <b>LC_MESSAGES</b> (message language). These categories dictate how the system behaves in terms of language-specific conventions.


title: HISTORY
content:
<b>localectl</b> was introduced as a core component of the <b>systemd</b> project, aiming to consolidate and standardize system configuration tools. Its development focused on providing a consistent and persistent way to manage locale and keyboard settings across different boot stages and user environments, thereby replacing older, less integrated methods that varied across distributions. It rapidly became a standard utility in modern Linux systems adopting <b>systemd</b>, simplifying configuration for administrators.


title: PARAMETERS
content:
<b>-i <I>inputfile</I>, --input-file=<I>inputfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the locale definition source file to be compiled.<br><br><b>-f <I>charmap</I>, --charmap=<I>charmap</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character map (or codeset) to be used for the locale. This defines the character set encoding for the locale, e.g., 'UTF-8' or 'ISO-8859-1'.<br><br><b>-c, --no-archive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;By default, compiled locales are added to a system-wide locale archive. This option prevents the locale from being added to the archive, storing it as an individual file instead.<br><br><b>-A <I>archive_path</I>, --add-to-archive=<I>archive_path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds the compiled locale to a specified locale archive file, rather than the default system archive.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <b>localedef</b> to overwrite an existing locale definition without prompting.<br><br><b>--check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a syntax check on the input file but does not compile or install the locale. Useful for validating locale definitions.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces more detailed output during the compilation process, showing progress and information about the processed definitions.<br><br><b>--no-warnings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all warning messages during compilation.<br><br><b>--warnings=<I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the warning level. Common levels include 'error' (treat warnings as errors) or 'all' (show all possible warnings).<br><br>


title: DESCRIPTION
content:
The <b>localedef</b> command is a utility used to compile locale definition source files into a binary locale object. These binary files are then utilized by C library functions (such as <i>setlocale(3)</i>, <i>strcoll(3)</i>, and <i>strftime(3)</i>) to provide language and culture-specific behaviors for applications running on a Linux system.<br><br>A locale definition file, typically with a <i>.ld</i> or <i>.def</i> extension, contains detailed specifications for various locale categories, including character classification, collation sequences, monetary formatting, date and time representation, and message formatting. When <b>localedef</b> processes such a file, it checks the syntax and semantics, and then generates a compact, optimized binary representation of the locale data.<br><br>This compiled locale data is crucial for internationalization (i18n) and localization (l10n), enabling systems to correctly display and process text, numbers, and dates according to regional conventions. The output binary files are usually stored in system-wide directories like <i>/usr/lib/locale</i> or <i>/usr/share/locale</i>, making them accessible to all applications that rely on the system's locale settings.


title: CAVEATS
content:
Compiling locales generally requires root privileges to write to system directories (e.g., <i>/usr/lib/locale</i>).<br>Incorrect or malformed locale definitions can lead to unexpected behavior in applications that rely on locale data.<br>Care must be taken to match the specified character map with the actual encoding of the input source file to avoid corruption.


title: LOCALE SOURCE FILES
content:
Locale definition source files (e.g., <i>en_US.UTF-8.ld</i>) are plain text files structured into categories like <b>LC_CTYPE</b> (character classification), <b>LC_COLLATE</b> (string comparison), <b>LC_MONETARY</b> (currency formatting), <b>LC_NUMERIC</b> (numeric formatting), <b>LC_TIME</b> (date and time formatting), and <b>LC_MESSAGES</b> (affirmative/negative responses). These categories collectively define the locale's behavior across various aspects.


title: OUTPUT LOCATION AND LOCALE ARCHIVE
content:
Compiled locale files are typically stored in a directory structure under <i>/usr/lib/locale/</i> or <i>/usr/share/locale/</i>, where each locale gets its own subdirectory (e.g., <i>/usr/lib/locale/en_US.UTF-8/</i>). For performance, many systems also maintain a 'locale archive' (e.g., <i>/usr/lib/locale/locale-archive</i>), which is a single file containing all compiled locales. This archive allows applications to load locale data more efficiently, reducing disk I/O when switching locales.


title: HISTORY
content:
<b>localedef</b> is a fundamental utility in Linux and Unix-like operating systems, stemming from the POSIX standard for internationalization (i18n). Its functionality has been a core component of the GNU C Library (glibc) for decades, providing the necessary infrastructure to compile human-readable locale source definitions into machine-readable binary formats. This process is essential for enabling applications to adapt to diverse linguistic and cultural conventions, reflecting its long-standing importance in system-level internationalization efforts.


title: PARAMETERS
content:
<b>-b, --basename</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Match only the base name of path names.<br><br><b>-c, --existing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only list entries that currently exist on the filesystem. This performs a <i>stat()</i> check for each database entry.<br><br><b>-i, --ignore-case</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore case distinctions when matching patterns.<br><br><b>-n NUM, --limit=NUM</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit after finding <i>NUM</i> successful matches.<br><br><b>-r, --regex</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret patterns as basic regular expressions (BREs).<br><br><b>-0, --null</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Separate entries with a null character, useful for scripting.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress error messages.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br>


title: DESCRIPTION
content:
The <b><code>locate</code></b> command is a utility on Unix-like operating systems used for quickly finding files by name. Unlike the <b><code>find</code></b> command, which searches the filesystem in real-time, <b><code>locate</code></b> operates by querying a pre-built database of all files on the system. This database is typically created and updated by the <b><code>updatedb</code></b> command, often run periodically via a cron job (e.g., daily).<br><br>The primary advantage of <b><code>locate</code></b> is its speed. Because it doesn't need to traverse the filesystem, it can return results almost instantly, even on systems with a vast number of files. This makes it ideal for quick checks when you know part of a filename. However, its main limitation is that the results are only as current as the last time the database was updated. If files have been created, deleted, or renamed since then, <b><code>locate</code></b> will not reflect those changes. Additionally, since it reads from a global database, it can show paths to files that the current user might not have permission to access, which can be a privacy concern for some.


title: CAVEATS
content:
<b>Database Freshness:</b> The results from <b><code>locate</code></b> are only as up-to-date as the last time the <b><code>updatedb</code></b> command was run. Newly created, deleted, or renamed files will not be reflected until the database is updated.<br><br><b>Security and Privacy:</b> <b><code>locate</code></b> reads from a global database, which typically contains paths to all files on the system, regardless of the current user's permissions. This means it can list files or directories that the user might not actually be able to access, potentially revealing sensitive file paths.<br><br><b>Permissions during indexing:</b> If <b><code>updatedb</code></b> was run with restricted permissions, the database might not contain all files on the system.


title: DATABASE LOCATION
content:
The default location for the <b><code>locate</code></b> database is commonly <i><code>/var/lib/mlocate/mlocate.db</code></i> or similar paths like <i><code>/var/lib/locate/locate.db</code></i>. The exact path can vary depending on the system and <b><code>locate</code></b> implementation.


title: DATABASE UPDATES
content:
The database is typically updated by the <b><code>updatedb</code></b> command, usually executed nightly via a system cron job (e.g., within <i><code>/etc/cron.daily/</code></i> or a similar directory). Users can also run <b><code>sudo updatedb</code></b> manually to force an immediate update.


title: HISTORY
content:
The <b><code>locate</code></b> command has been a staple utility in Unix-like operating systems for decades, providing a fast alternative to real-time filesystem searches. Its development is closely tied to the <i>findutils</i> package (or <i>mlocate</i> for newer, more efficient versions), which aims to provide fundamental file search utilities. The efficiency of <b><code>locate</code></b>, relying on a pre-built index, was particularly advantageous in older computing environments where disk I/O was a significant bottleneck. While its core functionality remains consistent, implementations like <i>mlocate</i> have introduced optimizations for larger databases and modern file systems.


title: SYNOPSIS
content:
<I>locust</I> [<B>--help</B>] [<B>-f</B> <I>LOCUSTFILE</I>] [<B>--host</B> <I>HOSTNAME</I>] [<B>--web-host</B> <I>HOSTNAME</I>] [<B>--port</B> <I>PORT</I>] [<B>--users</B> <I>NUM_USERS</I>] [<B>--spawn-rate</B> <I>RATE</I>] [<B>--run-time</B> <I>TIME</I>] [<B>--csv</B> <I>FILENAME</I>] [<B>--headless</B>] [<B>--master</B>] [<B>--worker</B>] [<B>--expect-workers</B> <I>COUNT</I>] [<B>--stop-timeout</B> <I>SECONDS</I>] [<B>--skip-teardown</B>] [<B>--env</B> <I>ENV</I>]


title: PARAMETERS
content:
<b><B>-f</B> <I>LOCUSTFILE</I>, <B>--locustfile</B> <I>LOCUSTFILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Python file containing your test scenarios (Locustfile).<br><br><b><B>--host</B> <I>HOSTNAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The base host (prefix) to be tested, e.g., <I>http://localhost:8089</I>. This sets the <I>host</I> attribute for <I>HttpUser</I> classes.<br><br><b><B>--web-host</B> <I>HOSTNAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Host for the web UI to bind to. Defaults to <I>127.0.0.1</I> (localhost).<br><br><b><B>--port</B> <I>PORT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Port for the web UI to bind to. Defaults to <I>8089</I>.<br><br><b><B>--users</B> <I>NUM_USERS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Total number of concurrent users to simulate. Used when running in headless mode.<br><br><b><B>--spawn-rate</B> <I>RATE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The rate per second at which users are spawned. Used when running in headless mode.<br><br><b><B>--run-time</B> <I>TIME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop the test after the specified run time. E.g., <I>20m</I> for 20 minutes, <I>3h</I> for 3 hours. Used in headless mode.<br><br><b><B>--csv</B> <I>FILENAME_PREFIX</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Store results in CSV files (requests and statistics) with the given filename prefix. Used in headless mode.<br><br><b><B>--headless</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run Locust without the web UI. Useful for automated tests in CI/CD pipelines.<br><br><b><B>--master</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run Locust as a master node in a distributed setup. This node coordinates workers and aggregates results.<br><br><b><B>--worker</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run Locust as a worker node in a distributed setup. This node executes user tasks and sends statistics to the master.<br><br><b><B>--expect-workers</B> <I>COUNT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When running as master, wait until this many workers have connected before starting the test.<br><br><b><B>--stop-timeout</B> <I>SECONDS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Time in seconds to wait for graceful stop of load tests before forcing exit. Defaults to <I>80</I> seconds.<br><br><b><B>--skip-teardown</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not run the teardown functions after test completion.<br><br><b><B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br>


title: DESCRIPTION
content:
Locust is an open-source, event-based user load testing tool written in Python. It allows developers and testers to define user behavior in Python code, rather than relying on complex XML configurations or GUI-based scripting. Locust simulates thousands or millions of concurrent users against a system to identify performance bottlenecks and assess scalability.<br><br>It provides a user-friendly web interface for real-time monitoring of test progress, requests per second, response times, and error rates. Its distributed architecture enables testing at massive scale by allowing multiple worker instances to be controlled by a single master instance. This makes it highly flexible for testing various protocols, though it's most commonly used for HTTP/S web applications.<br><br>Unlike many traditional load testing tools, Locust's emphasis on Python code for test scenarios offers immense flexibility and seamless integration with existing development workflows, making it a popular choice for performance testing and capacity planning.


title: CAVEATS
content:
Locust is a Python application and is not a built-in Linux utility. It requires Python 3 and the <I>pip</I> package manager to be installed. Users must install it via <I>pip install locust</I> (or through system package managers if available) before it can be used. Its performance is influenced by the underlying Python interpreter and system resources, though it is designed to be highly efficient and scalable through its distributed execution capabilities. While primarily used for HTTP/S, testing other protocols requires custom client implementations within the Python test scripts.


title: DISTRIBUTED TESTING
content:
<I>Locust</I> supports distributed load generation across multiple machines. A single 'master' node manages the test, aggregates statistics from all workers, and provides the web UI. Multiple 'worker' nodes execute the actual user simulations and send their performance metrics back to the master. This architecture allows for generating massive loads far beyond the capabilities of a single machine, making it suitable for large-scale performance testing.


title: PYTHON TEST SCENARIOS
content:
Tests in <I>Locust</I> are defined as plain Python classes, typically inheriting from <I>User</I> or <I>HttpUser</I>. This approach allows developers to leverage the full power of Python for defining user behavior, including defining various tasks with different probabilities, sequential actions, dynamic data generation, and custom validation logic. This code-based approach provides unparalleled flexibility and allows for version controlling test scripts alongside application code.


title: HISTORY
content:
Locust was created by <I>Carl Groner</I> and first released in <I>2011</I>. It was developed out of a need for a more flexible and programmable load testing tool compared to existing commercial and open-source solutions of the time. Its design emphasizes simplicity and extensibility through Python code, allowing testers to define complex user behaviors and test scenarios easily. Over the years, it has gained significant popularity within the development and QA communities for its ease of use, scalability, and seamless integration with modern CI/CD pipelines. It is actively maintained and evolved by a community of contributors, continuously adding new features and improving performance.


title: SYNOPSIS
content:
<code>log2pcap</code> [<b>OPTIONS</b>] <i>&lt;unified2_log_file&gt;</i> <i>&lt;output_pcap_file&gt;</i>


title: PARAMETERS
content:
<b>-r <i>&lt;rule_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><br></i>Specifies the path to a Snort rules file. This allows <br><code>log2pcap</code> to display the actual rule messages <br>associated with the SIDs found in the unified2 log, <br>providing more human-readable context for alerts.<br><br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><br></i>Enables verbose output, providing more details about <br>the conversion process, including information on records <br>processed and errors encountered.<br><br><br><b>-N <i>&lt;event_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><br></i>Filters the input unified2 log to process only events <br>matching the specified Event ID. This is useful for <br>extracting packets related to a specific alert instance.<br><br><br><b>-S <i>&lt;sensor_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><br></i>Filters the input unified2 log to process only events <br>originating from a specific Sensor ID. Useful in <br>environments with multiple Snort sensors.<br><br><br><b>-L <i>&lt;packet_limit&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><br></i>Limits the number of packets extracted and written <br>to the output PCAP file to the specified count. <br>This can be used to manage output file size.<br><br><br>


title: DESCRIPTION
content:
<code>log2pcap</code> is a utility typically included with the Snort Intrusion Detection System (IDS). Its primary function is to convert Snort's proprietary <code>unified2</code> binary log format into a standard PCAP (Packet Capture) file. <br><br>This conversion is invaluable for security analysts as it allows them to reconstruct and analyze the actual network traffic that triggered specific Snort alerts. By transforming log data into PCAP, tools like Wireshark or similar network protocol analyzers can be used to deep-dive into the packet contents, helping to understand the nature of an attack, validate alerts, or perform detailed forensic analysis. It effectively bridges the gap between Snort's alert logs and common network analysis tools, providing a richer context for security events.


title: CAVEATS
content:
<code>log2pcap</code> is primarily designed for Snort's <code>unified2</code> log format and is not a general-purpose text-to-PCAP converter. It requires that the original packet data be present within the <code>unified2</code> logs, which depends on Snort's logging configuration (e.g., <code>output unified2: log_packets</code> must be enabled in <code>snort.conf</code>). Without packet data in the logs, it can only extract alert metadata, not full packets.


title: UNIFIED2 LOGS EXPLAINED
content:
<i><br></i><code>log2pcap</code> works specifically with Snort's <code>unified2</code> log format. This binary format was designed to efficiently store both alert metadata and the actual network packets that triggered those alerts. This integrated approach allows <code>log2pcap</code> to extract the full packet payload, which is crucial for detailed forensic analysis, unlike simpler text-based alert logs.<br>


title: ENHANCING FORENSIC ANALYSIS
content:
<i><br></i>The ability to reconstruct original network packets from IDS logs significantly enhances forensic capabilities. Analysts can replay traffic, inspect packet headers and payloads, and corroborate alert data with actual network events using familiar tools like Wireshark, rather than being limited to textual alert summaries.<br>


title: HISTORY
content:
<code>log2pcap</code> has been a core utility within the Snort IDS ecosystem for many years, developed alongside Snort to facilitate the forensic analysis of IDS alerts. Its purpose is to convert Snort's internal binary log format (<code>unified2</code>) into a widely compatible PCAP format. Its evolution is tied directly to Snort's development and its increasing sophistication in logging and alert management, playing a crucial role in post-detection analysis workflows for security professionals.


title: SYNOPSIS
content:
<i>logger</i> [<i>-i</i>] [<i>-f file</i>] [<i>-p priority</i>] [<i>-s</i>] [<i>-t tag</i>] [<i>-u socket</i>] [<i>message ...</i>]


title: PARAMETERS
content:
<b><i>message ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The message to be logged. If not specified, <i>logger</i> reads from standard input (stdin).<br><br><b><i>-i</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the process ID (PID) of the <i>logger</i> process with each line.<br><br><b><i>-f file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the message from the specified <i>file</i> instead of from the command line arguments. Each line in the file becomes a separate log entry.<br><br><b><i>-p priority</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the priority of the message. The <i>priority</i> can be given as a numerical value or as a <I>facility.level</I> pair (e.g., <I>user.info</I>, <I>daemon.crit</I>).<br><br><b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the message to standard error (stderr), in addition to sending it to the system log.<br><br><b><i>-t tag</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks every line to be logged with the specified <i>tag</i>. This tag typically appears before the message text in the log entry, helping to identify the source of the log.<br><br><b><i>-u socket</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the message to the specified Unix domain socket instead of the default syslog socket (e.g., <I>/dev/log</I> or <I>/run/systemd/journal/socket</I>).<br><br>


title: DESCRIPTION
content:
The <i>logger</i> command provides a shell interface to the <i>syslog</i> system module. It allows users to send messages directly from the command line or within shell scripts to the system's logging daemon (e.g., <i>syslogd</i>, <i>rsyslogd</i>, or <i>syslog-ng</i>).<br><br>These messages are then processed by the logging daemon according to its configuration (typically <i>/etc/syslog.conf</i> or <i>/etc/rsyslog.conf</i>). This makes <i>logger</i> an invaluable tool for debugging scripts, integrating custom application logs into the centralized system log, security auditing, and general system monitoring.<br><br>Users can specify the message's facility and priority level, allowing for fine-grained control over how messages are categorized and routed by the syslog system.


title: CAVEATS
content:
The <i>logger</i> command relies on a running <i>syslog</i> daemon (e.g., <i>rsyslogd</i>, <i>syslog-ng</i>, or <i>systemd-journald</i>) to function correctly. If no daemon is active or configured to receive messages, entries sent by <i>logger</i> will likely be discarded without a trace.<br><br>The actual destination and handling of log messages are entirely dictated by the configuration of the syslog daemon (e.g., <i>/etc/syslog.conf</i> or <i>/etc/rsyslog.conf</i>). Care should be taken not to log sensitive information directly, as it may be written to disk in plain text, accessible to unauthorized users.


title: PRIORITIES AND FACILITIES
content:
Syslog messages are categorized by a <i>facility</i> and a <i>level</i> (also known as priority or severity). This two-part classification allows the syslog daemon to filter, route, and store messages based on their origin and importance.<br><br><b>Common Facilities:</b><br>These denote the source of the message:<br><i>kern</i> (kernel messages), <i>user</i> (user-level messages), <i>mail</i> (mail system), <i>daemon</i> (system daemons), <i>auth</i> (security/authorization messages), <i>syslog</i> (internal syslogd messages), <i>lpr</i> (line printer subsystem), <i>news</i> (USENET news system), <i>uucp</i> (UUCP subsystem), <i>cron</i> (cron/at daemon), <i>authpriv</i> (private security/authorization messages), <i>ftp</i> (FTP daemon), <i>local0</i> through <i>local7</i> (reserved for local use).<br><br><b>Common Levels (Severity, from highest to lowest):</b><br>These indicate the severity of the event:<br><i>emerg</i> (panic conditions – system unusable), <i>alert</i> (conditions that should be corrected immediately), <i>crit</i> (critical conditions, e.g., hard device errors), <i>err</i> (error conditions), <i>warning</i> (warning conditions), <i>notice</i> (normal but significant condition), <i>info</i> (informational messages), <i>debug</i> (debugging messages).


title: USAGE EXAMPLES
content:
Here are some practical examples demonstrating the use of the <i>logger</i> command:<br><br><b>Log a simple informational message:</b><br><i>logger "My application successfully started."</i><br><br><b>Log a critical error message from the 'daemon' facility:</b><br><i>logger -p daemon.crit "CRITICAL: Database connection lost!"</i><br><br><b>Log a message with a custom tag and include the PID:</b><br><i>logger -i -t MY_SCRIPT "Processing daily report."</i><br><br><b>Log multiple lines of content from a file:</b><br><i>echo -e "Line 1 of log\nLine 2 of log" > /tmp/app_events.txt<br>logger -f /tmp/app_events.txt -t APP_EVENTS</i><br><br><b>Log from standard input using a pipe:</b><br><i>dmesg | tail -n 5 | logger -t KERNEL_LAST_5 -p kern.info</i>


title: HISTORY
content:
The <i>logger</i> command has been a staple Unix utility for many decades, evolving closely with the <i>syslog</i> protocol itself. Its fundamental purpose—to provide a simple command-line interface for sending messages to the system log—has remained consistent.<br><br>Historically, it was a basic part of system administration toolsets, ensuring that scripts and manual commands could easily integrate with central logging. In modern Linux distributions, it's typically included as part of the <i>util-linux</i> package, maintaining its widespread availability and utility across various logging backends like <i>rsyslog</i> and <i>systemd-journald</i>.


title: SEE ALSO
content:
<i>syslogd(8)</i>, <i>rsyslogd(8)</i>, <i>syslog.conf(5)</i>, <i>rsyslog.conf(5)</i>, <i>journalctl(1)</i>


title: PARAMETERS
content:
<b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves the environment of the calling process, rather than resetting it completely. Useful when invoked by programs like <I>su</I>.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force login, bypassing the password prompt. This option is typically used by programs that have already authenticated the user (e.g., <I>su</I>) or requires root privileges.<br><br><b>-h host</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the hostname of the remote host from which the user is logging in. Primarily used for remote login protocols like <I>rlogin</I>.<br><br><b>-r service</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the PAM service name to use for authentication and session management. This allows custom PAM configurations for different login scenarios.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Log failed login attempts to the <I>lastlog</I> file. This is often the default behavior to track security incidents.<br><br>


title: DESCRIPTION
content:
The <b>login</b> command is a fundamental utility on Linux and Unix-like systems, primarily responsible for authenticating a user and establishing a new interactive session. It is typically invoked by <I>getty</I> (for local console logins) or <I>sshd</I> (for remote SSH logins) after a connection has been established. <br><br>Upon execution, <b>login</b> prompts the user for their username and then their password. It verifies these credentials against the system's authentication database. If successful, <b>login</b> sets up the user's environment, including variables like <B>HOME</B>, <B>SHELL</B>, <B>PATH</B>, <B>TERM</B>, <B>USER</B>, and <B>LOGNAME</B>. It then changes the current directory to the user's home directory and executes the user's default shell as specified in <I>/etc/passwd</I>. <br><br><b>login</b> plays a crucial security role by enforcing authentication policies, managing failed login attempts, and logging successful and unsuccessful access attempts to system logs like <I>lastlog</I> and <I>faillog</I>. Its behavior is highly configurable via Pluggable Authentication Modules (PAM).


title: CAVEATS
content:
The <b>login</b> command is rarely executed directly by end-users; it is usually invoked by system daemons like <I>getty</I> for local console access or <I>sshd</I> for remote access. Its behavior is heavily dependent on the system's Pluggable Authentication Modules (PAM) configuration, which determines authentication methods, session setup, and account restrictions. Misconfiguration of PAM can lead to users being unable to log in.


title: PAM INTEGRATION
content:
Modern implementations of <I>login</I> heavily rely on Pluggable Authentication Modules (PAM). PAM provides a modular framework for authentication, account management, session management, and password management. When <I>login</I> runs, it consults the PAM configuration files (e.g., <I>/etc/pam.d/login</I>) to determine the exact steps for authenticating the user, setting up their session environment, and enforcing security policies. This modularity makes <I>login</I> highly adaptable to various authentication backends and security requirements.


title: ENVIRONMENT SETUP
content:
After successful authentication, <I>login</I> is responsible for setting up the user's initial environment. This includes setting critical environment variables such as <B>HOME</B> (user's home directory), <B>SHELL</B> (user's default shell), <B>PATH</B> (directories for executable commands), <B>TERM</B> (terminal type), <B>USER</B>, and <B>LOGNAME</B>. It also typically changes the current working directory to the user's home directory. Furthermore, it executes initialization scripts like <I>/etc/profile</I> and the user's shell-specific startup files (e.g., <I>~/.profile</I>, <I>~/.bashrc</I>, <I>~/.zshrc</I>) to fully configure the session before handing control to the user's shell.


title: HISTORY
content:
The <b>login</b> command is one of the oldest and most fundamental utilities in Unix-like operating systems, existing since the early versions of Unix. Its core function of authenticating users and establishing sessions has remained consistent. Over time, its capabilities expanded to integrate with various authentication mechanisms, notably with the introduction of Pluggable Authentication Modules (PAM) in the mid-1990s. PAM externalized the authentication logic, allowing <b>login</b> to use different authentication methods (e.g., local passwords, Kerberos, LDAP) without requiring code changes, significantly enhancing its flexibility and security.


title: DESCRIPTION
content:
The <b>logout</b> command is a <i>shell built-in</i>, meaning its functionality is provided directly by the command interpreter (e.g., <b>bash</b>, <b>csh</b>, <b>tcsh</b>) rather than being a separate executable program.<br><br>It is primarily used to <b>terminate the current login shell session</b>, effectively ending the user's interactive session. While similar to the <b>exit</b> command, which terminates any shell instance, <b>logout</b> is specifically designed for <i>login shells</i>. This implies that it typically only works if the current shell is the initial shell started after a user's authentication (e.g., via <b>ssh</b>, direct console login, or graphical terminal emulator configured to launch a login shell).<br><br>Upon successful execution, <b>logout</b> usually results in the <i>closing of the terminal window</i> or the <i>disconnection of the SSH session</i> from which the command was issued. This command is particularly relevant in command-line environments, such as when working on remote servers via <b>SSH</b>, or within a standalone terminal session on a local machine. It ensures a clean departure from the system, releasing resources and closing open connections related to the session.


title: CAVEATS
content:
<b>Shell Built-in Specificity</b>: <b>logout</b> is a <i>shell built-in</i> command, meaning its behavior can slightly vary between different shells (e.g., <b>bash</b>, <b>csh</b>, <b>tcsh</b>). It is not a standalone executable found in standard system paths.<br><br><b>Login Shell Requirement</b>: It generally only works if the current shell is the <i>initial login shell</i>. If executed in a subshell, it might behave like <b>exit</b> or simply fail.<br><br><b>No Arguments/Options</b>: The command typically accepts no arguments or options.<br><br><b>Running Jobs</b>: Some shells may prevent <b>logout</b> if there are background jobs running without <b>nohup</b>, prompting the user or requiring explicit termination of jobs before logging out.<br><br><b>Comparison with exit</b>: For non-login shells or general script termination, <b>exit</b> is often a more universal and reliable choice.


title: DIFFERENCES WITH EXIT
content:
While both <b>logout</b> and <b>exit</b> serve to terminate a shell, their primary distinctions lie in their scope and typical usage. <b>logout</b> is specifically intended for <i>login shells</i>; it usually only works if the current shell is the initial shell opened at login and often triggers a complete session termination (e.g., closing the terminal window or disconnecting an SSH session). Conversely, <b>exit</b> can terminate <i>any</i> shell (login or non-login) and is more commonly used in scripts, functions, or to simply close a subshell without necessarily ending the entire user session.


title: HISTORY
content:
The <b>logout</b> command has been a fundamental feature of Unix-like shells, particularly the <i>C shell</i> (<b>csh</b>) and its derivatives like <b>tcsh</b>, for many decades. Its inclusion provided a distinct command for terminating a user's interactive session, differentiating it from the more general <b>exit</b> command which could terminate any shell instance.<br><br>While still present and functional in modern shells like <b>bash</b>, its usage might be less prominent in graphical desktop environments where users often rely on GUI-driven logout options. However, for server administration, remote access via <b>SSH</b>, and traditional command-line work, <b>logout</b> remains a simple and direct method for session termination.


title: PARAMETERS
content:
<b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Follow</i> log output. <b>logread</b> will not terminate after printing the current log, but wait for new messages and print them as they arrive.<br><br><b><b>-e</b> <i>&lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Filter</i> log output by a regular expression <b>pattern</b>. Only messages matching the <b>pattern</b> will be displayed.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reverse</i> output order. Prints the newest messages <b>first</b>.<br><br><b><b>-l</b> <i>&lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Limit</i> output to the last <b>count</b> messages.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Help</i>. Displays a <b>help</b> message and exits.<br><br>


title: DESCRIPTION
content:
<i>logread</i> is a lightweight utility primarily used on embedded Linux systems, such as OpenWrt, to access and display kernel and system log messages.<br><br>Unlike more complex logging daemons like <b>syslogd</b> or <b>journalctl</b>, <i>logread</i> often reads directly from a circular buffer in memory (like <b>/dev/kmsg</b>) or a small persistent file, making it suitable for devices with limited storage and processing power. It provides a simple way to view recent system events, errors, and informational messages, which is crucial for debugging and monitoring device health without requiring a full-fledged logging infrastructure. Its simplicity means it typically lacks advanced filtering, persistence, or remote logging capabilities found in more comprehensive logging solutions.


title: CAVEATS
content:
<b>logread</b> is typically very basic. It might not support advanced filtering, long-term persistence, or remote logging.<br><br>Log storage is often a circular buffer in RAM, meaning logs are <b>lost</b> on reboot and have a <b>limited</b> history.<br><br><b>Availability</b>: Primarily found on embedded systems (e.g., OpenWrt) and <b>not</b> commonly part of standard desktop/server Linux distributions.


title: HISTORY
content:
<i>logread</i> emerged as a minimalist logging solution for environments with <b>severe resource constraints</b>, particularly in the embedded Linux space (e.g., <b>OpenWrt</b>). Its development was driven by the need for a simple, low-overhead way to view system events without the memory and storage footprint of traditional <i>syslog</i> implementations. It often works in conjunction with <b>busybox</b>, which provides many common Unix utilities in a single executable, further emphasizing its lightweight nature. Its evolution has focused on <b>efficiency</b> and <b>simplicity</b> rather than feature expansion.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--size-limit</b> <i>size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the size of the log file. If the log file reaches or exceeds the specified <i>size</i> (in bytes), it is truncated to zero length before new output is written. This prevents log files from growing indefinitely.<br><br><b><b>-a</b>, <b>--append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends output to the <i>logfile</i> if it already exists. Without this option, <b>logsave</b> will truncate the <i>logfile</i> (or create a new one) each time it is run.<br><br><b><b>-t</b>, <b>--time-format</b> <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the timestamp format using <i>strftime(3)</i> syntax. This allows for flexible control over how the timestamps appear in the log file. For example, <code>%F %T</code> for YYYY-MM-DD HH:MM:SS.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose mode, causing <b>logsave</b> to print additional diagnostic or informational messages to standard error.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for <b>logsave</b> and exits.<br><br>


title: DESCRIPTION
content:
The <b>logsave</b> command is a utility designed to execute a specified command and capture its standard output (stdout) and standard error (stderr) into a designated log file. Its primary feature is the automatic insertion of timestamps at the beginning of each line of output, making it exceptionally useful for monitoring long-running processes, cron jobs, or scripts where a chronological record of events is crucial. <br><br>Unlike simple redirection (e.g., <code>command > logfile</code>), <b>logsave</b> ensures that every line is prefaced with the exact time it was output by the wrapped command, providing valuable context for debugging, auditing, or performance analysis. It can either create a new log file or append to an existing one, and offers options for size limits and custom time formats. It is part of the <i>util-linux</i> project, a collection of essential Linux system utilities.


title: CAVEATS
content:
<b>logsave</b> does not handle log rotation on its own; for advanced log management (like keeping multiple rotated logs), external tools such as <i>logrotate(8)</i> should be used in conjunction with <b>logsave</b>. <br><br>The accuracy of timestamps can be affected if the wrapped command buffers its output extensively; <b>logsave</b> adds the timestamp when a line is actually received, not necessarily when it was generated by the command. <br><br>Standard input to the wrapped command is passed through normally, but standard output and standard error are redirected to the log file.


title: EXIT STATUS
content:
<b>logsave</b> returns the exit status of the <i>command</i> it executes. If the <i>command</i> cannot be executed (e.g., not found), <b>logsave</b> returns a non-zero exit status (typically 127 for command not found, or 126 for command not executable).


title: EXAMPLES
content:
<b>1. Basic usage to log a script's output:</b><br><code>logsave /var/log/myscript.log /usr/local/bin/my_daily_script.sh</code><br><br><b>2. Appending to an existing log file with a custom time format:</b><br><code>logsave -a -t "%Y-%m-%d %H:%M:%S" /var/log/apt_updates.log apt update && apt upgrade -y</code><br><br><b>3. Logging a command that runs indefinitely, with a size limit:</b><br><code>logsave -s 10M /var/log/app_monitor.log /usr/bin/some_monitoring_app --loop</code>


title: HISTORY
content:
<b>logsave</b> is a long-standing utility that forms part of the <i>util-linux</i> project, a collection of essential user-space utilities for Linux systems. Its purpose has remained consistent over time: to provide a robust and easy-to-use method for capturing time-stamped output of commands, particularly beneficial in unattended or background environments. Its inclusion in <i>util-linux</i> underscores its fundamental role in system administration and scripting, ensuring its widespread availability across Linux distributions.


title: SYNOPSIS
content:
<b>logstash</b> [<i>OPTIONS</i>]<br><b>logstash</b> <b>-f</b> <i>CONFIG_PATH</i> [<i>OPTIONS</i>]<br><b>logstash</b> <b>-e</b> <i>CONFIG_STRING</i> [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b><b>-f</b>, <b>--path.config</b> <i>CONFIG_PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>Logstash</i> configuration file(s) or directory. Can be a single file, a comma-separated list of files, or a directory containing configuration files.<br><br><b><b>-e</b>, <b>--config.string</b> <i>CONFIG_STRING</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the provided configuration string directly, without needing a separate file. Useful for quick tests or small configurations.<br><br><b><b>-r</b>, <b>--reload-every</b> <i>INTERVAL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables automatic configuration reloading. <i>Logstash</i> will monitor the config file(s) for changes and reload them every <i>INTERVAL</i> seconds. (e.g., <b>--reload-every 5s</b>).<br><br><b><b>--path.data</b> <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the path to the <i>Logstash</i> data directory, used for persistent queues, metrics, and other internal data. Defaults to <b>data/</b> inside the <i>Logstash</i> home directory.<br><br><b><b>--path.settings</b> <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the directory containing <i>Logstash</i> settings files (e.g., <b>logstash.yml</b>, <b>jvm.options</b>). Defaults to <b>config/</b>.<br><br><b><b>--log.level</b> <i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the logging level for <i>Logstash</i>. Common levels include <b>fatal</b>, <b>error</b>, <b>warn</b>, <b>info</b>, <b>debug</b>, <b>trace</b>. Defaults to <b>info</b>.<br><br><b><b>--config.test_and_exit</b>, <b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests the configuration for syntax errors and validity, then exits. Does not start the <i>Logstash</i> pipeline.<br><br><b><b>--allow-env</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the use of environment variables directly within the configuration files using <b>${ENV_VAR}</b> syntax.<br><br><b><b>-w</b>, <b>--pipeline.workers</b> <i>COUNT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of worker threads to use for filter and output processing. Defaults to the number of CPU cores.<br><br><b><b>-b</b>, <b>--pipeline.batch.size</b> <i>SIZE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of events an individual worker thread will pull from the input queue at once. Defaults to 125.<br><br>


title: DESCRIPTION
content:
<i>Logstash</i> is an open-source, server-side data processing pipeline that ingests data from a multitude of sources simultaneously, transforms it, and then sends it to your favorite 'stash', often <i>Elasticsearch</i>.<br><br>It's a core component of the <i>Elastic Stack</i> (formerly known as the ELK Stack, comprising <i>Elasticsearch</i>, <i>Logstash</i>, and <i>Kibana</i>). <i>Logstash</i> uses a flexible plugin-based architecture, allowing it to collect various types of data (logs, metrics, web applications, data stores) through <b>input</b> plugins, process and enrich this data using <b>filter</b> plugins (e.g., parsing, transforming, adding context), and then output the processed data to different destinations via <b>output</b> plugins (e.g., <i>Elasticsearch</i>, <i>Kafka</i>, S3, files). Its primary use case is centralized log management and analytics.


title: CAVEATS
content:
<i>Logstash</i> is built on <i>JRuby</i> and runs on the <i>Java Virtual Machine (JVM)</i>, which can lead to significant memory and CPU consumption, especially for large volumes of data. Proper resource allocation and JVM tuning are crucial for production deployments. Configuration can become complex with multiple inputs, filters, and outputs, requiring careful design and testing. Debugging can be challenging, often relying heavily on log output and the <b>--config.test_and_exit</b> option.


title: TYPICAL USAGE
content:
<i>Logstash</i> is commonly deployed as a daemon or service that continuously runs in the background, consuming data from various sources (e.g., <i>Filebeat</i> agents, message queues), processing it according to its configured pipelines, and then forwarding it to a central data store like <i>Elasticsearch</i> for indexing and analysis. It's a critical component for centralizing and enriching diverse data types.


title: CONFIGURATION STRUCTURE
content:
A <i>Logstash</i> configuration file is divided into three main sections: <b>input</b>, <b>filter</b>, and <b>output</b>.<br><ul><li><b>Input:</b> Defines where <i>Logstash</i> gets its data (e.g., <b>file</b>, <b>beats</b>, <b>http</b>, <b>kafka</b>).</li><li><b>Filter:</b> Processes and transforms the data (e.g., <b>grok</b> for parsing, <b>mutate</b> for modifying fields, <b>geoip</b> for adding location data).</li><li><b>Output:</b> Specifies where the processed data should be sent (e.g., <b>elasticsearch</b>, <b>stdout</b>, <b>file</b>, <b>s3</b>).</li></ul>


title: HISTORY
content:
<i>Logstash</i> was originally created by <i>Jordan Sissel</i> in 2009 as a flexible tool for managing event data. Its ability to collect, parse, and store logs efficiently quickly gained traction within the developer community. It became a foundational component of the <i>Elastic Stack</i> (ELK Stack) after being acquired by <i>Elastic</i>, the company behind <i>Elasticsearch</i> and <i>Kibana</i>. Over the years, its architecture has evolved, emphasizing modularity through plugins and robustness for enterprise-grade data pipelines.


title: SEE ALSO
content:
<b>elasticsearch</b>(1), <b>kibana</b>(1), <b>filebeat</b>(1), <b>metricbeat</b>(1), <b>systemd</b>(1)


title: PARAMETERS
content:
<b><b>--detail</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the level of detail in the report. Common values include <i>Low</i>, <i>Med</i>, <i>High</i>, or an integer (e.g., 0-10).<br><br><b><b>--format</b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format of the report. Accepted values are <i>text</i> or <i>html</i>.<br><br><b><b>--output</b> <i>&lt;method&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines where the report is sent. Options include <i>mail</i>, <i>stdout</i> (print to screen), or <i>file</i>.<br><br><b><b>--mailto</b> <i>&lt;email_address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends the generated report to the specified email address.<br><br><b><b>--file</b> <i>&lt;filename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the report to the specified file path instead of mailing or printing.<br><br><b><b>--print</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A shortcut for <b>--output stdout</b>, printing the report directly to the terminal.<br><br><b><b>--range</b> <i>&lt;time_range&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the time period for which logs should be processed. Examples include <i>yesterday</i>, <i>today</i>, <i>all</i>, <i>last24hours</i>, or custom ranges like <i>'2023/01/01 10:00:00'..'2023/01/01 11:00:00'</i>.<br><br><b><b>--service</b> <i>&lt;service_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes logs only for the specified service(s). Can be used multiple times to include several services (e.g., <b>--service http --service sshd</b>).<br><br><b><b>--config_dir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative directory for configuration files instead of the default.<br><br><b><b>--log_dir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative directory where log files are located.<br><br><b><b>--hostname</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the system's hostname in the report header.<br><br><b><b>--debug</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output for troubleshooting, with increasing verbosity levels (0-10).<br><br>


title: DESCRIPTION
content:
<b>Logwatch</b> is a customizable log analysis program designed to process system logs, identify relevant information, and generate concise reports. It aggregates data from various log files, such as syslog, mail logs, Apache access logs, and more, presenting it in a human-readable format. This helps system administrators quickly spot potential issues, security alerts, or important operational events without manually sifting through large volumes of log data. It's highly configurable, allowing users to specify the level of detail, report format (text or HTML), output destination (email, stdout, or file), and which services to monitor.


title: CAVEATS
content:
Logwatch relies heavily on Perl scripts for parsing, which can be complex to customize for new or unusual log formats. Its performance can degrade on systems with extremely high log volumes or when processing many services, as it processes logs sequentially. Ensure that your system's mail services are correctly configured for email reports to be delivered successfully. If `logwatch` is already running via a default cron job, be mindful to avoid conflicts with any custom scheduling.


title: CONFIGURATION FILES
content:
The primary configuration file for <b>Logwatch</b> is typically located at <i>/etc/logwatch/conf/logwatch.conf</i>, which controls global settings such as output options, detail levels, and time ranges. More specific configurations and parsing scripts for individual services are found in subdirectories like <i>/etc/logwatch/conf/services/</i> and <i>/etc/logwatch/scripts/services/</i>, enabling fine-grained control over how each log type is processed.


title: CRON INTEGRATION
content:
<b>Logwatch</b> is most commonly utilized as a daily automated task via <i>cron</i>. On many Linux systems, a script such as <i>/etc/cron.daily/00logwatch</i> is responsible for executing it automatically, usually in the early morning hours, to process the previous day's logs and send a summary report to the configured recipient.


title: HISTORY
content:
Logwatch originated as a Perl-based tool developed to simplify the often tedious process of analyzing vast and complex system log files. Its primary goal was to provide system administrators with a concise, daily summary of critical events, thereby reducing the need for manual inspection of raw logs. It has been a standard utility included in many Linux distributions for well over a decade, evolving to support a wide range of log formats and services through its flexible, modular script architecture.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b><b>-F</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force color output, even if stdout is not a TTY.<br><br><b><b>-f</b>, <b>--fast</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a faster, less CPU-intensive color generation mode.<br><br><b><b>-p</b>, <b>--spread</b> <I>PERCENT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the spread of the rainbow (default is 3.0). Higher values create wider color bands.<br><br><b><b>-a</b>, <b>--animate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable animation of the rainbow effect.<br><br><b><b>-d</b>, <b>--duration</b> <I>DURATION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the duration of the animation in frames (default is 12). Only applicable with <I>-a</I>.<br><br><b><b>-s</b>, <b>--speed</b> <I>SPEED</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the animation speed in frames per second (default is 20.0). Only applicable with <I>-a</I>.<br><br><b><b>-i</b>, <b>--invert</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invert the colors of the rainbow.<br><br><b><b>-S</b>, <b>--seed</b> <I>SEED</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a specific random seed for color generation, useful for consistent output.<br><br>


title: DESCRIPTION
content:
lolcat is a command-line utility that applies a vibrant rainbow color effect to text output. It reads input from standard input (stdin) or specified files and writes the colorized output to standard output (stdout). Primarily designed for aesthetic purposes, lolcat transforms plain terminal text into eye-catching displays. It's frequently used to pipe the output of other commands, such as <I>ls</I>, <I>cat</I>, or <I>echo</I>, making their results more visually engaging. Beyond static coloration, lolcat can also animate the rainbow effect, creating a mesmerizing scrolling color pattern. While not a core system utility, it's a popular tool for adding a touch of fun and personalization to the Linux command-line experience, embodying the playful spirit of "lolspeak" and internet culture from which its name derives. It's particularly favored for demonstrations, terminal screenshots, or simply brightening up everyday command usage.


title: CAVEATS
content:
While entertaining, <I>lolcat</I> should be used judiciously. Extensive animation on large outputs can consume significant CPU resources. It's primarily an aesthetic tool and not suitable for situations where clear, unformatted text is required, such as scripting or parsing outputs. Additionally, it's not a standard pre-installed utility on most Linux distributions and typically needs to be installed separately.


title: USAGE EXAMPLES
content:
Here are some common ways to use <I>lolcat</I> to colorize your terminal output:<br><br><b>1. Colorize a simple text string:</b><br><code>echo "Hello, Lolcat!" | lolcat</code><br><br><b>2. Apply rainbow colors to command output:</b><br><code>ls -l | lolcat</code><br><br><b>3. Animate a file's content:</b><br><code>cat my_file.txt | lolcat -a -s 50 -d 10</code><br><br><b>4. Invert the rainbow colors:</b><br><code>ip a show dev eth0 | lolcat -i</code>


title: INSTALLATION
content:
<I>lolcat</I> is not typically part of standard Linux distributions. It can often be installed via your system's package manager (e.g., <I>sudo apt install lolcat</I> on Debian/Ubuntu, <I>sudo pacman -S lolcat</I> on Arch Linux) or as a Ruby gem (<I>gem install lolcat</I>) or Python package (<I>pip install lolcat</I> for a Python version).


title: HISTORY
content:
The <I>lolcat</I> command originated as a Ruby gem, leveraging Ruby's capabilities for text processing and terminal manipulation. Its name is a playful nod to the popular internet meme "lolcat," combined with the common Unix command <I>cat</I>, which it often complements by piping output. Since its initial development, its unique and visually appealing output has led to its widespread adoption among Linux enthusiasts. While the original implementation was in Ruby, its popularity has inspired reimplementations in other programming languages like Python, making it accessible to an even broader user base across various environments. Its history reflects a blend of internet culture and practical command-line utility.


title: PARAMETERS
content:
<b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares only alphanumeric characters, ignoring case and other special characters. This mimics traditional dictionary lookup behavior where punctuation and capitalization are often disregarded for sorting.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores the case of letters when comparing, making the search case-insensitive. This applies to both the search <I>STRING</I> and the content of the <I>FILE</I>s.<br><br><b>-t <I>char</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a <I>character</I> that marks the end of a word. Only characters up to (but not including) this termination character are considered for the search string and the file entries. This is useful for files where words might have suffixes or additional data on the same line, and you only want to match the primary word part.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for the <b><I>look</I></b> command and exits.<br><br>


title: DESCRIPTION
content:
The <b><I>look</I></b> command is a specialized utility designed for quickly searching for words within sorted text files, typically dictionary files.<br><br>It performs a fast binary search on the specified file(s), making it highly efficient for large word lists. By default, it searches for words that <i>begin with</i> a given string in <I>/usr/share/dict/words</I> or files specified by the <I>WORDS</I> environment variable. If additional file arguments are provided, <b><I>look</I></b> searches those files instead.<br><br>Its primary use case is for quick dictionary-style lookups, where you need to find all entries that start with a particular prefix. Unlike general-purpose search tools like <I>grep</I>, <b><I>look</I></b> requires the input file to be sorted, which allows it to use a much faster binary search algorithm. It offers options to ignore case and to use dictionary-style comparisons, making it versatile for various text datasets.


title: CAVEATS
content:
<ul><li><b>File Must Be Sorted:</b> <b><I>look</I></b> fundamentally relies on its input file(s) being sorted (lexicographically, or according to dictionary rules if <I>-d</I> is used). If the file is not correctly sorted, the command will produce incorrect or unpredictable results.</li><li><b>Start-of-Word Matching Only:</b> It only finds entries where the search <I>STRING</I> appears at the very beginning of a word. It does not perform a general substring search.</li><li><b>Default Dictionary Path:</b> The default dictionary file, typically <I>/usr/share/dict/words</I>, might not exist on all systems or may require installing a specific dictionary package.</li></ul>


title: ENVIRONMENT VARIABLES
content:
The <b><I>look</I></b> command respects the <I>WORDS</I> environment variable. If <I>WORDS</I> is set to a path, <b><I>look</I></b> will use that file as its default dictionary instead of <I>/usr/share/dict/words</I> when no explicit file arguments are provided.


title: INPUT FILE FORMAT
content:
For <b><I>look</I></b> to function correctly, each word or entry in the input file(s) must be on its own line. The file must also be sorted according to the collation rules of the current locale, unless the <I>-d</I> (dictionary order) or <I>-f</I> (fold case) options are used to modify the comparison logic.


title: HISTORY
content:
<b><I>look</I></b> is a venerable Unix utility, with roots dating back to the early BSD systems. Its design leverages the efficiency of binary search, a fundamental algorithm in computer science, to provide rapid lookups in sorted data. This made it particularly valuable in environments where quick access to large word lists or dictionaries was essential, often predating the widespread use of more general-purpose text processing tools for such specific tasks. It is typically found as part of the <I>bsd-games</I> package or <I>util-linux</I> on modern Linux distributions, maintaining its original purpose as a fast word-search tool.


title: SYNOPSIS
content:
<b>lookandfeeltool</b> <i>[options]</i><br><b>lookandfeeltool</b> --list<br><b>lookandfeeltool</b> --apply <i>&lt;theme-name&gt;</i><br><b>lookandfeeltool</b> --reset<br><b>lookandfeeltool</b> --set-active <i>&lt;theme-id&gt;</i>


title: PARAMETERS
content:
<b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>lookandfeeltool</b> utility.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message, detailing command usage and available options.<br><br><b><b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently installed and available global look and feel themes on the system.<br><br><b><b>--apply <i>&lt;theme-name&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the global look and feel theme specified by <i>&lt;theme-name&gt;</i>. The name must exactly match one of the themes listed by <b>--list</b>.<br><br><b><b>--reset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the KDE Plasma desktop's look and feel settings to the system's default global theme.<br><br><b><b>--set-active <i>&lt;theme-id&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the global look and feel theme specified by its internal <i>&lt;theme-id&gt;</i>. This option is an alternative to <b>--apply</b> and can be useful for themes with complex or non-standard names.<br><br>


title: DESCRIPTION
content:
The <b>lookandfeeltool</b> command-line utility is an integral part of the KDE Plasma desktop environment, designed to manage and apply global "Look and Feel" themes. These comprehensive themes encapsulate various aspects of the desktop's visual presentation and user experience, including the Plasma theme, application style, color scheme, window decorations, icon theme, cursor theme, and font settings, often bundling wallpapers as well.<br><br>It provides a non-graphical interface for functionalities typically accessible through the "System Settings" application's "Look and Feel" module. This makes <b>lookandfeeltool</b> particularly valuable for scripting desktop configurations, automating theme deployment across multiple systems, or applying specific aesthetic setups without relying on the graphical user interface. Users can leverage this tool to list available themes, apply a chosen theme by name or ID, or revert the desktop to its default appearance. It's a key component for power users, theme developers, and system administrators who require programmatic control over the KDE Plasma desktop's aesthetics.


title: CAVEATS
content:
This command is specific to the KDE Plasma desktop environment and requires it to be installed and running. Changes applied typically affect the current user's session. It is not a universally available Linux command on non-KDE systems.


title: THEME STRUCTURE
content:
A global look and feel theme is typically a directory containing various configuration files and assets (e.g., <i>metadata.desktop</i>, <i>colors/</i>, <i>icons/</i>, <i>plasmashell/</i>, <i>wallpapers/</i>). These themes are usually stored in <i>~/.local/share/plasma/look-and-feel/</i> for user-installed themes, and <i>/usr/share/plasma/look-and-feel/</i> for system-wide themes.


title: THEME COMPONENTS
content:
A single global theme bundles and applies settings for the Plasma theme, application style (e.g., GTK, Qt), color scheme, window decorations, icon theme, cursor theme, font settings, and often a default wallpaper, providing a cohesive desktop aesthetic.


title: SCRIPTING USE CASES
content:
This command is invaluable for scripting desktop setups, allowing system administrators to standardize desktop appearances across an organization, or for users to quickly switch between custom theme configurations without manual interaction via the GUI.


title: HISTORY
content:
The <b>lookandfeeltool</b> emerged as part of the KDE Plasma desktop environment, specifically aligning with the development of KDE Plasma 5 (and earlier in KDE 4), to consolidate disparate appearance settings into a unified "global theme" concept. Its evolution has paralleled the graphical "Look and Feel" module in KDE's System Settings, providing a command-line counterpart for automation and advanced configuration. It has become a standard utility for KDE power users and administrators.


title: PARAMETERS
content:
<b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt for input; instead, read <i>keywords</i> from standard input. This makes <b>lookbib</b> suitable for non-interactive use or scripting.<br><br><b><b>-i</b><i>filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>filename</i> as the output file for the <b>eign</b> preprocessor. This option is typically related to advanced internal processing and less commonly used.<br><br><b><b>-t</b><i>filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>filename</i> as the input transformation file for the <b>eign</b> preprocessor. Similar to <b>-i</b>, it's for specific internal configurations.<br><br><b><i>file ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more bibliographic database <i>files</i> to search. If no files are specified, <b>lookbib</b> reads the database from standard input.<br><br>


title: DESCRIPTION
content:
<b>lookbib</b> is an interactive command-line utility designed to assist users in locating and formatting bibliographic references. It searches specified bibliographic database <i>files</i> (or standard input) for entries matching user-provided <i>keywords</i>. Upon finding matches, it displays the corresponding bibliographic records, which are typically formatted for use with the <b>refer</b> preprocessor for <b>roff</b> documents. It provides a quick way to look up citations from a formatted database, making it a useful tool for authors preparing documents with <b>groff</b> or other <b>roff</b>-based systems.


title: CAVEATS
content:
Primarily integrated with the <b>groff</b> (<i>GNU roff</i>) typesetting system, <b>lookbib</b>'s relevance has diminished with the widespread adoption of modern document preparation tools (e.g., <i>LaTeX</i>, word processors with built-in citation managers). Its bibliographic database format (typically <b>refer</b> format) is specific to the <b>roff</b> ecosystem. The <b>-i</b> and <b>-t</b> options relate to the older <b>eign</b> preprocessor and are rarely used in contemporary contexts.


title: BIBLIOGRAPHIC FILE FORMAT
content:
<b>lookbib</b> expects bibliographic entries to be formatted according to the <b>refer</b> preprocessor's conventions. Each entry typically occupies a paragraph, with fields marked by a leading `<b>%</b>` character followed by a field code (e.g., `<b>%A</b>` for author, `<b>%T</b>` for title, `<b>%J</b>` for journal, `<b>%D</b>` for date). These files are plain text, making them human-readable and editable.


title: INTERACTIVE MODE
content:
When executed without the <b>-b</b> option, <b>lookbib</b> enters an interactive mode, prompting the user with `<i>Keywords:</i> `. Users can type one or more words, and <b>lookbib</b> will search the database for matching entries. Typing `<i>Ctrl+D</i>` (end-of-file) on an empty line will exit the interactive session.


title: HISTORY
content:
<b>lookbib</b> originated as part of the classic <i>Unix</i> <b>roff</b> toolchain developed at <i>Bell Labs</i>. It was later incorporated into <b>groff</b>, the <i>GNU</i> implementation of <b>roff</b>, ensuring its continued availability on modern <i>Unix-like</i> systems. While its core functionality remains the same, its practical usage has declined as document preparation workflows shifted away from text-based typesetting.


title: PARAMETERS
content:
<b>file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more object files (<i>.o</i>) or archive libraries (<i>.a</i>) to analyze. These files are scanned for their defined and undefined symbols to establish dependencies.<br><br>


title: DESCRIPTION
content:
The <i>lorder</i> command analyzes object files (<i>.o</i>) and archive libraries (<i>.a</i>) to determine their inter-dependencies. It produces a list of pairs of filenames, where the first file in a pair depends on the second file. This output is designed to be piped into <i>tsort</i> (topological sort) to generate a linear order of files suitable for linking by <i>ld</i>. It inspects the symbol tables of the input files, identifying undefined symbols (dependencies) and defined symbols (providers). <i>lorder</i> is particularly useful in Makefiles to ensure that static libraries and object files are passed to the linker in the correct order, which is crucial for resolving symbol references successfully. It does not perform the linking itself, but rather provides the necessary ordering information.


title: CAVEATS
content:
<i>lorder</i> is primarily relevant for static linking scenarios where the order of archives and object files passed to the linker matters significantly.<br>It relies on an external utility, <i>tsort</i>, to produce a usable linking order from its pairwise output.<br>For dynamic linking, dependencies are typically handled by the linker and runtime loader through different mechanisms (e.g., <i>DT_NEEDED</i> entries in shared libraries), making <i>lorder</i> less applicable.<br>Its utility has somewhat diminished in modern build environments that often employ more sophisticated and automated dependency tracking solutions.


title: TYPICAL USAGE
content:
The common pattern for using <i>lorder</i> is to pipe its output directly to <i>tsort</i> to obtain a linear, topologically sorted list of files that satisfies all dependencies.<br>Example: <code>lorder *.o *.a | tsort</code>


title: OUTPUT FORMAT
content:
<i>lorder</i> produces a list of pairs of filenames on standard output, one pair per line, separated by a space. If file <i>A</i> depends on file <i>B</i>, the output will contain a line like <code>A B</code>.


title: UNDERLYING MECHANISM
content:
The command works by inspecting the symbol tables of the provided object files and libraries. It looks for undefined symbols (symbols that are referenced but not defined within the current file) and then checks if these symbols are defined in other input files, thus establishing a dependency.


title: HISTORY
content:
<i>lorder</i> is a traditional Unix utility, typically part of the <i>binutils</i> suite or similar packages on Linux distributions. Its design reflects common practices for managing dependencies in older static linking environments. While its direct use in modern projects might be less frequent due to advanced build systems, it remains a foundational tool for understanding how static library dependencies were historically managed.


title: SYNOPSIS
content:
<i>lorem</i> [<i>OPTIONS</i>] [<i>COUNT</i>]<br><i>lorem</i> [<i>COUNT</i>] [<i>OPTIONS</i>]<br>The <i>COUNT</i> argument specifies the number of units to generate, defaulting to 5 words if no unit type is specified.


title: PARAMETERS
content:
<b><i>COUNT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of units (words, sentences, or paragraphs) to generate. If no unit option is specified, it defaults to words. Defaults to 5 if not provided.<br><br><b><i>-w</i>, <i>--words</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate <i>COUNT</i> words of lorem ipsum text. This is the default behavior if no unit option is specified.<br><br><b><i>-s</i>, <i>--sentences</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate <i>COUNT</i> sentences of lorem ipsum text.<br><br><b><i>-p</i>, <i>--paragraphs</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate <i>COUNT</i> paragraphs of lorem ipsum text.<br><br><b><i>-h</i>, <i>--html</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wrap each generated paragraph in HTML <b>&lt;p&gt;</b> tags. If generating words or sentences, the entire output will be wrapped in a single <b>&lt;p&gt;</b> tag.<br><br><b><i>-b</i>, <i>--bold-first</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make the first word of the output <b>bold</b>.<br><br>


title: DESCRIPTION
content:
The <i>lorem</i> command is a utility designed to produce pseudo-Latin placeholder text, commonly known as "Lorem Ipsum". This text is widely used in graphic design, web development, and publishing to fill content areas before the final text is available, allowing designers to focus on layout and typography without distraction from meaningful content. It offers flexibility to generate a specified quantity of words, sentences, or paragraphs, making it suitable for various prototyping and testing needs. This command aims to provide a quick and easy way to populate mock-ups and templates with realistic-looking content blocks.


title: CAVEATS
content:
This command is purely <i>hypothetical</i> and is not a standard utility found in typical Linux distributions. It is presented as an example of what a command generating "Lorem Ipsum" placeholder text might entail, reflecting the common needs for such a tool in development and design workflows.


title: USAGE EXAMPLES
content:
Generate 10 words:<br><b>lorem 10</b><br><br>Generate 3 paragraphs:<br><b>lorem -p 3</b><br><br>Generate 2 sentences with HTML paragraph tags:<br><b>lorem -s 2 -h</b><br><br>Generate 15 words with the first word bold:<br><b>lorem -w 15 -b</b>


title: HISTORY
content:
The practice of using "Lorem Ipsum" as placeholder text dates back to the 16th century, originating from a passage in Cicero's <i>De finibus bonorum et malorum</i>. While a dedicated <i>lorem</i> command is not natively present in standard Linux systems, the widespread utility of generating such text for design and development purposes has led to the creation of numerous scripts and external tools across various programming languages and platforms.


title: SEE ALSO
content:
<i>head(1)</i>: Output the first part of files., <i>tail(1)</i>: Output the last part of files., <i>cat(1)</i>: Concatenate files and print on the standard output., <i>echo(1)</i>: Display a line of text.


title: SYNOPSIS
content:
<b>losetup</b> [<i>options</i>] [<i>loopdevice</i> [<i>file</i>]]<br><b>losetup</b> -a | --all<br><b>losetup</b> -d | --detach &lt;<i>loopdevice</i>&gt;<br><b>losetup</b> -D | --detach-all<br><b>losetup</b> -f | --find [<i>file</i>]<br><b>losetup</b> -L | --list [<i>loopdevice</i>]


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show status of all loop devices. Used for listing.<br><br><b>-c, --crypt-setup <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a crypt device instance, using the specified name. Requires the 'cryptsetup' utility and 'dm_crypt' kernel module.<br><br><b>-d, --detach <loopdevice></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detach the specified loop device. If a file is mounted on it, it must be unmounted first.<br><br><b>-D, --detach-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detach all loop devices. This operation is potentially dangerous if filesystems are still mounted.<br><br><b>-E, --encryption <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the encryption type. This option is deprecated; it is recommended to use 'cryptsetup' directly for encrypted loop devices.<br><br><b>-f, --find</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Find the first unused loop device. If a file is specified, it will set up this file on the found loop device.<br><br><b>-F, --nooverlap</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When setting up, check for overlaps. This means that if an offset or sizelimit is specified, <b>losetup</b> will fail if the resultant device extends beyond the real end of the underlying file.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br><b>-L, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List detailed information about specified loop device(s). This is the default when no action option is given.<br><br><b>-n, --no-fork</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using <b>--crypt-setup</b>, do not fork a new process after setting up the loop device.<br><br><b>-o, --offset <offset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The data start is moved <i>offset</i> bytes into the specified file or device.<br><br><b>-P, --partscan</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the kernel to scan the partitions on the newly set up loop device. Useful for disk images containing multiple partitions.<br><br><b>-r, --read-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set up the loop device in read-only mode. The underlying file will not be written to.<br><br><b>-s, --sizelimit <size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The data end is limited to <i>size</i> bytes from the start of the data. Useful for loop devices that are smaller than the actual file.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>losetup</b> command is a utility used to manage <i>loop devices</i> in Linux. A loop device is a pseudo-device that makes a regular file accessible as a block device. This allows users to treat a file (like an ISO image, a disk image, or an encrypted container) as if it were a physical disk, enabling operations such as mounting a filesystem from it, creating partitions, or applying encryption.<br><br><b>losetup</b> can perform several key functions:<br>- Associating a loop device with a specified file or block device.<br>- Querying the status and properties of existing loop devices.<br>- Detaching loop devices from their associated files.<br>- Finding the first available (unused) loop device.<br>- Setting up parameters like offset, size limits, and read-only mode for the loop device.<br>- Integrating with encryption frameworks like <i>dm-crypt</i>.<br><br>It is commonly used for mounting CD/DVD ISO images without burning them, accessing virtual machine disk images, or creating encrypted filesystems within a single file. Most operations require root privileges.


title: CAVEATS
content:
<b>Root Privileges:</b> Most operations (setting up, detaching) require root privileges. Querying (<b>-a</b>, <b>-L</b>) can often be done by non-root users.<br><b>Kernel Module:</b> Loop devices depend on the 'loop' kernel module. It is usually loaded automatically, but if not, it can be loaded manually using 'modprobe loop'.<br><b>Unmounting First:</b> When detaching a loop device (<b>-d</b>), ensure that any filesystems mounted on it are unmounted first, otherwise the operation will fail or lead to data corruption.<br><b>Data Integrity:</b> Incorrect usage of <b>offset</b> or <b>sizelimit</b> can lead to data corruption or inaccessible data if not carefully managed.<br><b>Security:</b> Be cautious when attaching untrusted disk images or files. A maliciously crafted image could potentially exploit kernel vulnerabilities.


title: AUTOMATIC DEVICE ASSIGNMENT
content:
When setting up a loop device without specifying a <i>loopdevice</i> (e.g., <b>losetup -f &lt;file&gt;</b>), <b>losetup</b> automatically finds the first available loop device (e.g., <i>/dev/loop0</i>, <i>/dev/loop1</i>, etc.) and assigns the file to it. This simplifies the process by not requiring the user to manually track free loop devices.


title: LOOP DEVICE NAMING CONVENTION
content:
Loop devices are typically named <i>/dev/loopX</i>, where <i>X</i> is an integer starting from 0. The number of available loop devices is usually pre-configured (e.g., 8 or 256) and can sometimes be increased if needed by kernel parameters or module options.


title: HISTORY
content:
Loop devices and the <b>losetup</b> command have been a fundamental part of the Linux kernel and userland utilities since the early days of Linux. It is part of the <i>util-linux</i> project, which provides a large set of essential system utilities. Over time, new features like partition scanning (<b>-P</b>) and <i>dm-crypt</i> integration (<b>-c</b>) have been added to enhance its capabilities, reflecting the evolving needs for disk image management and encryption. Its core functionality has remained consistent, serving as a reliable tool for virtual disk management.


title: PARAMETERS
content:
<b>-d <i>destination</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the printer or class to print to. If not specified, the system default printer or the one defined by the <i>LPDEST</i> or <i>PRINTER</i> environment variables is used.<br><br><b>-n <i>copies</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of copies to print for each file.<br><br><b>-o <i>option</i>=<i>value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more printer-specific options. Common options include <i>media=A4</i>, <i>landscape</i>, <i>portrait</i>, <i>sides=two-sided-long-edge</i>, <i>fit-to-page</i>, <i>page-ranges=1-5,7</i>.<br><br><b>-t <i>title</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the title of the print job, which may appear in printer queues or headers.<br><br><b>-q <i>priority</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the priority of the print job from 1 (lowest) to 100 (highest).<br><br><b>-h <i>hostname</i>[:<i>port</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the CUPS server to connect to.<br><br><b>-i <i>job-id</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to modify or re-print an existing job. This option is typically used with other options like <i>-n</i> or <i>-o</i> to change job properties.<br><br><b>-P <i>page-list</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints only the specified pages. Example: <i>1-5,9,12-</i>.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the 'request id is...' message upon successful job submission.<br><br><b>-U <i>username</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for the print job if different from the current user.<br><br>


title: DESCRIPTION
content:
The <b>lp</b> command is used to submit print jobs to a designated printer or to the system's default printer. It is the primary command-line interface for printing files on systems utilizing the CUPS (Common Unix Printing System) backend, as well as historically for System V printing systems.<br><br>When invoked, <b>lp</b> sends the specified file(s) or standard input to the print spooler, which then manages the printing process. It allows users to control various aspects of the print job, such as the target printer, number of copies, page ranges, and specific printer options like paper size, orientation, and duplex printing, by using various command-line options. Upon successful submission, <b>lp</b> usually returns a job ID, which can be used to monitor or cancel the print job. It provides a flexible and powerful way to integrate printing into shell scripts and automated workflows.


title: CAVEATS
content:
The exact behavior and available options of <b>lp</b> can vary slightly depending on the underlying printing system (CUPS vs. traditional System V). Modern Linux distributions predominantly use CUPS.<br><br>Printer options specified with <i>-o</i> are printer-specific; not all printers support all options. Refer to your printer's documentation or use <b>lpoptions -l</b> <i>printername</i> to see supported options.<br><br>Permissions are crucial. Users must have appropriate permissions to submit jobs to a printer.<br><br>Jobs submitted using <b>lp</b> are typically spooled locally before being sent to the printer. Ensure sufficient disk space for large jobs.


title: DEFAULT PRINTER
content:
The <b>lp</b> command will use the default printer if no destination is specified with <i>-d</i>. The default printer can be set using the <i>LPDEST</i> or <i>PRINTER</i> environment variables, or configured system-wide.


title: STANDARD INPUT
content:
If no file argument is provided, <b>lp</b> reads data from standard input. This is useful for piping output from other commands directly to the printer, e.g., <i>ls -l | lp</i>.


title: HISTORY
content:
The <b>lp</b> command has a long history in Unix-like operating systems, originating from the AT&T System V Unix printing system. It traditionally served as the counterpart to the BSD <b>lpr</b> command. With the advent of CUPS (Common Unix Printing System) in the late 1990s, <b>lp</b> (along with <b>lpr</b>, <b>lpq</b>, <b>lprm</b>, etc.) was reimplemented to interface with the CUPS daemon. On most modern Linux distributions, <b>lp</b> directly communicates with CUPS, providing a unified and standardized printing interface that combines features from both System V and BSD printing traditions, while adding robust network printing capabilities. Its widespread adoption ensures backward compatibility while leveraging modern printing infrastructure.


title: SYNOPSIS
content:
<b>lpadmin</b> [ -E ] [ -U <i>username</i> ] [ -h <i>hostname</i>[:<i>port</i>] ] [ -R <i>remove-options</i> ] <i>options</i><br><br>Common usage patterns:<br>&nbsp;&nbsp;<b>lpadmin</b> -p <i>printer</i> [ -P <i>filename.ppd</i> ] [ -v <i>device-uri</i> ] [ -m <i>model</i> ] [ -D <i>description</i> ] [ -L <i>location</i> ] [ -o <i>option=value</i> ... ]<br>&nbsp;&nbsp;<b>lpadmin</b> -x <i>printer|class</i><br>&nbsp;&nbsp;<b>lpadmin</b> -d <i>printer</i><br>&nbsp;&nbsp;<b>lpadmin</b> -c <i>class</i> { <i>printer</i> ... }


title: PARAMETERS
content:
<b>-p <i>printer</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the name of the printer to add or modify.</i><br><br><b>-x <i>printer|class</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Deletes the specified printer or printer class.</i><br><br><b>-d <i>printer</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the specified printer as the system default destination.</i><br><br><b>-c <i>class</i> { <i>printer</i> ... }</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adds the specified printers to a class or creates a new class. Multiple printer names can be provided.</i><br><br><b>-v <i>device-uri</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the device Uniform Resource Identifier (URI) for the printer, defining how it's connected (e.g., usb://, ipp://, socket://).</i><br><br><b>-P <i>filename.ppd</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the PostScript Printer Description (PPD) file for the printer, defining its capabilities.</i><br><br><b>-m <i>model</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uses a pre-installed CUPS model (PPD file) for the printer. List available models with 'lpinfo -m'.</i><br><br><b>-D <i>description</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Provides a short, descriptive string for the printer, often displayed in print dialogs.</i><br><br><b>-L <i>location</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the physical location of the printer, useful for organization.</i><br><br><b>-o <i>option=value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets a specific printer option or attribute. Can be used multiple times for different options (e.g., 'printer-is-shared=true', 'job-hold-until=indefinite').</i><br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables the printer to accept new jobs.</i><br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables the printer for printing, allowing it to process jobs.</i><br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables sharing and browsing of the printer, making it visible to other systems on the network.</i><br><br><b>-u <i>allow/deny:user,...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Controls user access to the printer. Specifies a comma-separated list of users or groups allowed or denied access.</i><br><br><b>-E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Forces encryption when connecting to the CUPS server, enhancing security.</i><br><br><b>-U <i>username</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies an alternate username for authentication with the CUPS server.</i><br><br><b>-h <i>hostname</i>[:<i>port</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies an alternate CUPS server to connect to, useful for remote administration.</i><br><br><b>-R <i>remove-options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Removes specific options from the printer.</i><br><br>


title: DESCRIPTION
content:
<b>lpadmin</b> is a powerful command-line utility for managing and configuring printer queues and classes within the Common Unix Printing System (CUPS). It serves as the primary administrative tool for system administrators to perform a wide range of tasks, including adding new printers, deleting existing ones, modifying printer settings, setting default print destinations, enabling or disabling printer queues, and managing printer classes. It plays a crucial role in setting up both local and network-attached printers, allowing fine-grained control over printing behavior, access, and options. Its consistent interface simplifies complex printer management tasks on Unix-like operating systems.


title: CAVEATS
content:
<i><b>lpadmin</b> requires administrative privileges, typically root or membership in the 'lpadmin' group (as configured in CUPS), to modify CUPS configuration. Changes made by <b>lpadmin</b> are usually immediate but depend on the CUPS daemon being active and properly configured. Incorrectly specified device URIs or PPD files can prevent a printer from functioning correctly or exhibiting its full capabilities.</i>


title: PERMISSIONS
content:
<i>To use <b>lpadmin</b> to configure printers, you typically need to be the root user or a member of the 'lpadmin' or 'sys' group, as defined in the CUPS configuration (usually in /etc/cups/cups-files.conf). This ensures that only authorized users can modify system-wide printer settings, maintaining system security.</i>


title: DEVICE URIS
content:
<i>The <i>device-uri</i> parameter (used with the <b>-v</b> option) is critical for specifying how the printer is connected to the system or network. Examples include <b>usb://...</b> for USB printers, <b>ipp://hostname/ipp/print</b> for IPP printers, <b>lpd://hostname/queue</b> for LPD/LPR printers, and <b>socket://hostname:9100</b> for raw network connections. Understanding the correct URI format for your printer's connection type is essential for successful printer setup.</i>


title: PPD FILES
content:
<i>PPD (PostScript Printer Description) files, specified with the <b>-P</b> option, are text files that describe the capabilities and features of a specific printer model. They are crucial for CUPS to correctly interpret and render print jobs, allowing access to printer-specific options like paper sizes, duplexing capabilities, color modes, and resolution settings. Using the correct PPD ensures optimal printer functionality and access to all its features.</i>


title: HISTORY
content:
<i><b>lpadmin</b> is an integral part of the Common Unix Printing System (CUPS), originally developed by Easy Software Products and later acquired by Apple Inc. CUPS was designed to provide a modular and extensible printing system for Unix-like operating systems, aiming to replace older, less standardized printing solutions. <b>lpadmin</b> emerged as the primary command-line tool for administering CUPS queues, offering a unified and consistent interface for managing printers, classes, and their options. Its development has focused on adapting to evolving printing technologies and providing comprehensive control over the CUPS printing architecture.</i>


title: SYNOPSIS
content:
<pre>lpass [GLOBAL-OPTIONS] <COMMAND> [COMMAND-OPTIONS] [ARGUMENTS]</pre><i>Common Commands:</i><br><pre>  lpass login [--trust --plaintext-key]<br>  lpass logout<br>  lpass status<br>  lpass ls [-l --sync=now] [GROUP/NAME]<br>  lpass show [--clip --password --username --url --notes --field=FIELD] ID|NAME<br>  lpass generate [--no-symbols --num-numbers --length=LEN --num-repeating=NUM --num-uppercase] ID|NAME<br>  lpass add [--generate --notes --non-interactive] ID|NAME<br>  lpass sync</pre>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b>lpass</b> client or a specific command.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <b>lpass</b> client version.<br><br><b><b>--sync=<mode></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls vault synchronization behavior. Modes: <i>auto</i> (default), <i>now</i> (forces sync), <i>no</i> (prevents sync).<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses non-essential output, useful for scripting and automation.<br><br><b><b>--color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces color output even when stdout is not connected to a TTY.<br><br><b><b>--no-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables color output.<br><br><b><b>--disable-key-repeat</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to disable key repeat during sensitive input prompts, enhancing security.<br><br>


title: DESCRIPTION
content:
<b>lpass</b> is the official command-line client for LastPass, a widely used online password manager. It empowers users to securely interact with their LastPass vault directly from the terminal, offering a robust alternative to the graphical interface. This tool is invaluable for system administrators, developers, and users who prefer a text-based workflow or require automation capabilities. <br><br>Key functionalities include logging in and out, listing all stored sites and secure notes, retrieving specific credentials, generating strong, unique passwords, adding new entries, and modifying existing ones. <b>lpass</b> handles sensitive data by encrypting and decrypting the vault locally on the user's machine, ensuring that the master password and vault contents are never exposed in plaintext outside of the user's control. It supports features like multifactor authentication and integration with LastPass Enterprise accounts, making it a versatile tool for both individual and organizational use.


title: CAVEATS
content:
<ul><li><b>Online Dependency:</b> While <b>lpass</b> utilizes a local encrypted cache, initial setup and subsequent synchronization require an active internet connection to communicate with the LastPass service.</li><li><b>Master Password Handling:</b> For security, avoid storing your LastPass master password in environment variables or scripts in plaintext. <b>lpass</b> is designed to prompt for it interactively when needed.</li><li><b>Local Cache Security:</b> <b>lpass</b> stores an encrypted copy of your vault in <code>~/.lpass</code>. Ensure proper file permissions and protect this directory, as it contains your sensitive data.</li><li><b>Terminal History:</b> Commands like <code>lpass show</code> might output sensitive information to the terminal. Be mindful of shell history and logs, and clear them if necessary to prevent exposure.</li></ul>


title: AUTHENTICATION AND SESSION MANAGEMENT
content:
After installation, the first step is typically to run <code>lpass login</code> to authenticate with your LastPass account. This command will prompt for your email and master password. Upon successful login, <b>lpass</b> establishes a session and optionally caches your vault locally. You can check your login status with <code>lpass status</code> and terminate your session with <code>lpass logout</code>.


title: LOCAL ENCRYPTED CACHE
content:
<b>lpass</b> maintains a local, encrypted cache of your LastPass vault, typically located at <code>~/.lpass</code>. This cache allows for faster retrieval of credentials and enables some operations even when offline. The cache is encrypted using a key derived from your LastPass master password, meaning sensitive data is only decrypted in memory when <b>lpass</b> is actively used and authenticated.


title: SCRIPTING AND AUTOMATION
content:
One of the primary benefits of <b>lpass</b> is its suitability for scripting. Commands like <code>lpass show --password</code> can be piped into other tools, allowing for automated credential retrieval in scripts or integration with configuration management systems. When scripting, it's recommended to use the <code>--non-interactive</code> flag where applicable and carefully consider security implications of passing sensitive data.


title: HISTORY
content:
The <b>lpass</b> client originated as an independent, unofficial command-line interface for LastPass, initially developed by Kyle Spearin. Its creation filled a significant gap for Linux users and CLI enthusiasts who desired direct terminal access to their LastPass vaults without relying on browser extensions or unofficial scripts. Recognizing its utility and growing popularity, LastPass officially adopted and began maintaining the <b>lpass</b> project under the LastPass GitHub organization. This transition solidified <b>lpass</b>'s role as the go-to command-line solution, ensuring its continued development, security, and compatibility with the LastPass service. It remains an open-source project, actively maintained and improved by LastPass employees and community contributors.


title: PARAMETERS
content:
<b><b>abort</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Terminates the current printer daemon and disables the print queue immediately.<br><br><b><b>clean</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all completed jobs and associated files from the specified print queue.<br><br><b><b>disable</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents new jobs from being entered into the specified print queue.<br><br><b><b>down</b> {<b>all</b> | <i>printer</i>} [<i>message</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the queue, stops the daemon, and sets an optional message displayed to users trying to print.<br><br><b><b>enable</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows new jobs to be entered into the specified print queue.<br><br><b><b>exit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits the <b>lpc</b> interactive command interpreter.<br><br><b><b>help</b> [<i>command</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of recognized commands or a short description of a specific command.<br><br><b><b>quit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits the <b>lpc</b> interactive command interpreter.<br><br><b><b>restart</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to restart a printer daemon for the specified printer, useful if it has crashed.<br><br><b><b>start</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the print queue and starts the printer daemon.<br><br><b><b>status</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the status of the specified printer or all printers, showing daemon status, queue enabled state, and number of jobs.<br><br><b><b>stop</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the printer daemon but leaves the queue enabled for new jobs.<br><br><b><b>topq</b> <i>printer</i> {<i>job_number</i> ... | <i>user</i> ...}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Moves specified jobs or all jobs from a given user to the top of the queue for immediate printing.<br><br><b><b>up</b> {<b>all</b> | <i>printer</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the queue and starts the daemon for the specified printer (the opposite of <b>down</b>).<br><br>


title: DESCRIPTION
content:
<b>lpc</b> is a command-line utility used to administer the <b>lpr</b> (line printer) spooling system. It allows a system administrator or authorized user to control various aspects of the printing environment.<br>Key functions include <b>enabling</b> or <b>disabling</b> printer queues, <b>starting</b> or <b>stopping</b> printer daemons, <b>reordering</b> jobs within a print queue, and <b>querying</b> the <b>status</b> of individual printers or all printers.<br>While <b>lpr</b> and its related utilities like <b>lpc</b> were standard in <b>BSD</b>-based Unix systems, they have largely been replaced by more modern printing systems like <b>CUPS</b> (Common Unix Printing System) on many Linux distributions.<br>However, <b>lpc</b> can still be found on systems configured to use the traditional <b>lpr</b> system, often for compatibility or specific legacy hardware. It provides <b>granular control</b> over print jobs and printer availability, making it an essential tool for managing a legacy printing infrastructure.


title: CAVEATS
content:
The <b>lpc</b> command typically requires <b>root</b> privileges or membership in the <b>lp</b> group to perform administrative tasks. It is primarily associated with the traditional <b>BSD</b> <b>lpr</b> printing system, which has largely been superseded by <b>CUPS</b> on most modern Linux distributions. Its functionality is dependent on the proper configuration and running status of the underlying <b>lpr</b> daemon, and errors can be cryptic if the system is not correctly set up.


title: INTERACTIVE MODE
content:
When invoked without any arguments, <b>lpc</b> enters an interactive command interpreter mode. This allows users to issue multiple commands consecutively without having to re-execute the <b>lpc</b> command for each operation. This mode is particularly useful for performing several printer management tasks in a single session.


title: HISTORY
content:
<b>lpc</b> is an integral part of the original <b>BSD</b> <b>lpr</b> printing system, which originated in the Berkeley Software Distribution of Unix. This system was widely adopted in early Unix environments for managing shared line printers.<br>Over time, more advanced printing systems like <b>CUPS</b> emerged, offering broader support for modern printers, network protocols, and authentication. While <b>CUPS</b> has become the de facto standard on most Linux distributions, <b>lpc</b> and the <b>lpr</b> suite persist in legacy systems or for specific compatibility requirements.<br>Its usage has declined with the rise of graphical printer administration tools and the widespread adoption of <b>CUPS</b>.


title: SYNOPSIS
content:
<b>lpinfo</b> [ -E ] [ -h <I>server</I>[:<I>port</I>] ] [ -l ] { -m | -v } [ --device-id <I>device-id</I> ] [ --exclude-schemes <I>schemes</I> ] [ --include-schemes <I>schemes</I> ] [ --lang <I>language</I> ] [ --timeout <I>seconds</I> ]


title: PARAMETERS
content:
<b>-E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables encryption when connecting to the CUPS server.<br><br><b>-h <I>server</I>[:<I>port</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate CUPS server to connect to. If not specified, the default server (localhost:631) is used.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a long (detailed) listing of the devices or models, showing more attributes and information.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the available printer models and drivers (PPD files). These are the drivers CUPS can use to configure a printer queue.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the available printer device URIs (Uniform Resource Identifiers). These URIs represent discovered printers, whether local or network-based.<br><br><b>--device-id <I>DEVICE_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only PPD files that match the specified IEEE 1284 device ID. Useful for identifying compatible drivers for specific hardware.<br><br><b>--exclude-schemes <I>schemes</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes specific device URI schemes from the listing (e.g., 'usb', 'dnssd', 'ipp'). Multiple schemes can be separated by commas.<br><br><b>--include-schemes <I>schemes</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only specific device URI schemes in the listing (e.g., 'usb', 'dnssd', 'ipp'). Multiple schemes can be separated by commas.<br><br><b>--lang <I>language</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the natural language for the output (e.g., 'en' for English, 'fr' for French).<br><br><b>--timeout <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a timeout in seconds for device discovery operations. This is particularly relevant for network discovery.<br><br>


title: DESCRIPTION
content:
The <b>lpinfo</b> command is a command-line utility provided by the Common Unix Printing System (CUPS). Its primary function is to discover and list various types of information pertinent to printing resources, specifically available printer drivers (models) and printer device URIs. This tool is invaluable for system administrators and users alike, enabling them to identify what printers are discoverable on the network, connected locally (e.g., via USB), or which backend drivers (PPD files) are installed and available for use.<br><br>By providing options to list either devices or drivers, <b>lpinfo</b> facilitates the setup and configuration of new printers using utilities like <b>lpadmin</b>. It can show network-discovered printers via protocols like Bonjour/mDNS or IPP, and also list local devices connected through various backends. The detailed output helps in understanding the capabilities and connection methods of available printing hardware.


title: CAVEATS
content:
The <b>lpinfo</b> command relies on the CUPS daemon (<b>cupsd</b>) being active and properly configured to discover devices and drivers. Network discovery capabilities, such as Bonjour/mDNS, depend on the network environment and corresponding services being enabled. The output, especially with the <b>-l</b> option, can be quite verbose, so piping to <b>grep</b> or <b>less</b> might be necessary for specific searches. Access permissions might also affect the visibility of certain devices or drivers if not run as a privileged user.


title: COMMON USAGE
content:
Here are some common ways to use <b>lpinfo</b>:<br><br>To list all available printer device URIs:<br><I>lpinfo -v</I><br><br>To list all available printer drivers (PPD files):<br><I>lpinfo -m</I><br><br>To list detailed information about discovered devices:<br><I>lpinfo -v -l</I><br><br>To list drivers matching a specific device ID (e.g., from a USB printer):<br><I>lpinfo -m --device-id 'MFG:HP;MDL:LaserJet 400 Color M451;...'</I><br><br>To list only USB devices:<br><I>lpinfo -v --include-schemes usb</I>


title: BACKEND PROGRAMS
content:
<b>lpinfo</b> relies on CUPS backend programs (for example, <I>/usr/lib/cups/backend/usb</I>, <I>/usr/lib/cups/backend/dnssd</I>, <I>/usr/lib/cups/backend/ipp</I>) to discover devices. When <b>lpinfo -v</b> is executed, it runs these backend programs to enumerate available printers across different interfaces and protocols.


title: HISTORY
content:
<b>lpinfo</b> is an integral part of the Common Unix Printing System (CUPS), which was initially developed by Michael Sweet at Easy Software Products. CUPS was designed to provide a modern, modular, and extensible printing system for Unix-like operating systems, aiming to replace older, less flexible printing solutions like System V and BSD printing. <b>lpinfo</b> has been a core utility since the early days of CUPS, providing a standardized way to query available printing resources. After its acquisition by Apple Inc. in 2007, CUPS development continued under Apple, and more recently, the project transitioned to the OpenPrinting workgroup of the Linux Foundation, ensuring its continued evolution and maintenance in the open-source community.


title: SYNOPSIS
content:
<i>lpmove</i> <I>job-id</I> <I>destination</I><br><i>lpmove</i> <I>source-printer</I> <I>destination</I>


title: PARAMETERS
content:
<b>job-id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more print jobs to be moved. Job IDs are typically in the format <i>printername-jobnumber</i> (e.g., <i>laser-123</i>). Multiple job IDs can be listed separated by spaces.<br><br><b>source-printer</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the printer from which <b>all</b> currently queued print jobs will be moved. This transfers the entire queue to the destination printer.<br><br><b>destination</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the printer to which the specified job(s) or all jobs from the <i>source-printer</i> will be relocated.<br><br>


title: DESCRIPTION
content:
<i>lpmove</i> is a command-line utility within the CUPS (Common Unix Printing System) framework used to relocate print jobs. Its primary function is to move specific print jobs from one printer queue to another, or to transfer all pending jobs from a source printer to a different destination printer. This capability is invaluable for administrative tasks such as load balancing print resources, redirecting jobs from a malfunctioning printer, or consolidating print queues. It offers flexibility in managing print flow and ensuring job completion even if a primary printer becomes unavailable. Administrative privileges are usually required to move jobs not owned by the executing user.


title: CAVEATS
content:
To move jobs not owned by the current user, administrative privileges (e.g., root access or membership in the <i>lpadmin</i> group) are required. The <i>destination</i> printer must exist and be configured within CUPS. Moving active jobs may briefly interrupt printing or alter the job order on the destination printer.


title: USER PERMISSIONS
content:
Regular users can only move their own print jobs. To move jobs owned by other users or to move all jobs from a printer (using the <i>source-printer</i> syntax), you must have administrative rights, such as being the <i>root</i> user or a member of the <i>lpadmin</i> group.


title: FINDING JOB IDS
content:
To identify the <i>job-id</i> of pending print jobs, you can use the <i>lpstat -o</i> command. This command lists all active print jobs along with their corresponding IDs, which are necessary for specifying individual jobs to be moved by <i>lpmove</i>.


title: HISTORY
content:
<i>lpmove</i> is an integral part of the CUPS (Common Unix Printing System) suite, which was initially developed by Easy Software Products before being acquired by Apple Inc. CUPS revolutionized printing on Unix-like systems, including Linux and macOS, by providing a robust, network-aware, and standardized printing architecture. <i>lpmove</i> carries forward the job management capabilities found in older `lp` systems but with the enhanced flexibility and features of CUPS, maintaining a largely consistent usage model since its inception within the CUPS project.


title: SYNOPSIS
content:
<b>lpoptions</b> [ <i>options</i> ] [ -d <i>destination</i> | -P <i>printer</i> ] [ -l | -o <i>option</i>[=<i>value</i>]... | -r <i>option</i>... | -x <i>option</i>... ]


title: PARAMETERS
content:
<b><b>-E</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces encryption when connecting to the server, enhancing security.<br><br><b><b>-h</b> <i>hostname</i>[:<i>port</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate CUPS server to connect to. The default is the local host.<br><br><b><b>-U</b> <i>username</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username to use for authentication with the CUPS server, if required for the operation.<br><br><b><b>-d</b> <i>destination</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the system default printer for the current user. This updates the user's default printer in <i>~/.cups/lpoptions</i>.<br><br><b><b>-P</b> <i>printer[/instance]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the printer or class to query or set options for. If this option is omitted, the user's default printer is used.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the available options and their current settings for the specified printer. This is particularly useful for discovering what options a printer supports.<br><br><b><b>-o</b> <i>option</i>[=<i>value</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a printer option for the specified printer or the default printer. If no <i>value</i> is provided, the option is typically enabled (e.g., <i>-o Duplex</i> to enable duplex printing).<br><br><b><b>-r</b> <i>option</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets (removes) a specific printer option from the user's default options for the specified printer. This will cause the system or printer default for that option to be used instead.<br><br><b><b>-x</b> <i>option</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the specified option from the user's defaults. This is functionally similar to <b>-r</b>.<br><br>


title: DESCRIPTION
content:
The <b>lpoptions</b> command is a utility within the CUPS (Common Unix Printing System) framework. It allows users to manage and view the default printing options for specific printers or classes, or to set a default printer for their user account. These options can include settings like paper size (e.g., <i>PageSize=A4</i>), print quality, duplex printing (e.g., <i>Duplex=DuplexNoTumble</i>), and many others supported by the printer's PPD (PostScript Printer Description) file.<br><br>When used without arguments, <b>lpoptions</b> lists the user's current default printer and all its set options. With the <b>-P</b> option, it targets a specific printer. Using <b>-l</b>, it lists all available options and their current settings for a given printer. Options set via <b>lpoptions -o</b> are stored as user-specific defaults, typically in <i>~/.cups/lpoptions</i>, and will override any system-wide defaults for that user. This command is an essential tool for customizing the printing experience without resorting to graphical interfaces or directly editing configuration files.


title: CAVEATS
content:
The <b>lpoptions</b> command primarily manages <i>user-specific</i> default printing options, which are stored in <i>~/.cups/lpoptions</i>. While it can set a default printer for a user, it is not the primary tool for configuring system-wide printer properties or adding/removing printers; for those tasks, <b>lpadmin(8)</b> is used. Changes made with <b>lpoptions</b> will only affect print jobs initiated by the user who executed the command, unless system-wide configuration files (e.g., <i>/etc/cups/lpoptions</i>) are directly modified by an administrator, which is less common via this command.


title: FILE LOCATIONS
content:
User-specific default options set by <b>lpoptions</b> are stored in the file <i>~/.cups/lpoptions</i>. This file contains a list of printers and their associated user-defined options. System-wide default options, while generally configured via <b>lpadmin(8)</b>, can also be present in <i>/etc/cups/lpoptions</i>, though direct manipulation of this file by <b>lpoptions</b> is less common for non-root users.


title: EXAMPLES
content:
<ul><li>To list all available options for the default printer and their current settings:<br><b>lpoptions -l</b></li><br><li>To list options for a specific printer named '<i>myprinter</i>':<br><b>lpoptions -P myprinter -l</b></li><br><li>To set the default paper size to A4 and enable duplex printing for '<i>myprinter</i>':<br><b>lpoptions -P myprinter -o PageSize=A4 -o Duplex=DuplexNoTumble</b></li><br><li>To set '<i>myprinter</i>' as the default printer for the current user:<br><b>lpoptions -d myprinter</b></li><br><li>To remove the '<i>PageSize</i>' option from your user-specific defaults for the default printer:<br><b>lpoptions -r PageSize</b></li></ul>


title: HISTORY
content:
<b>lpoptions</b> is an integral part of the CUPS (Common Unix Printing System) suite, which was originally developed by Easy Software Products starting in the late 1990s. CUPS was designed to replace older, disparate printing systems on Unix-like operating systems with a modern, standardized, and network-aware architecture. The <b>lpoptions</b> command was introduced as part of this effort, providing a consistent command-line interface for users to manage their printing preferences and defaults, aligning with the modular design of CUPS and its reliance on PPD files for printer capabilities.


title: SYNOPSIS
content:
<b>lppasswd</b> [ <i>-a username</i> ] [ <i>-r realm</i> ] [ <i>-x filename</i> ]<br><b>lppasswd</b> <i>-g</i> [ <i>-x filename</i> ]


title: PARAMETERS
content:
<b><i>-a username</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds or updates the password for the specified <i>username</i>. If <i>username</i> is set to <i>-</i>, the command reads the username from standard input. If omitted, the password is set for the current user.<br><br><b><i>-g</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables group mode, typically used to update passwords for all administrators defined in the CUPS configuration (e.g., in <i>/etc/cups/printers.conf</i>). When this option is used, <i>lppasswd</i> prompts for a password for each relevant user or group.<br><br><b><i>-r realm</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the authentication realm for the password. The default realm is 'CUPS' if not specified. Realms help segregate different sets of credentials within the CUPS server.<br><br><b><i>-x filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the password file to use instead of the default. The default password file is typically <i>/etc/cups/passwd.md5</i> or <i>~/.cups/passwd.md5</i> for per-user configurations.<br><br>


title: DESCRIPTION
content:
<br>The <i>lppasswd</i> command is a utility provided by the Common Unix Printing System (CUPS) to manage user authentication for its web interface and administrative tasks. It is used to create, update, or remove encrypted passwords for users who need to access the CUPS web administration pages, typically found at <i>https://localhost:631</i>. Passwords managed by <i>lppasswd</i> are stored in a designated password file, commonly <i>/etc/cups/passwd.md5</i>, and are used for basic or digest authentication by the CUPS server.<br><br>It is crucial to understand that <i>lppasswd</i> does <b>not</b> manage system-level user passwords (like those in <i>/etc/shadow</i>) but rather a separate set of credentials specifically for CUPS's internal authentication mechanism. When executed, it prompts the user for a password, encrypts it (historically using MD5), and stores it in the specified password file, associating it with a username and an authentication realm.


title: CAVEATS
content:
Passwords managed by <i>lppasswd</i> are historically hashed using MD5, which is considered cryptographically weak for general password storage due to its susceptibility to collision attacks and brute-force attempts given modern computational power. While acceptable for basic HTTP authentication as used by CUPS, it should <b>not</b> be confused with more secure system-level password hashing mechanisms (e.g., bcrypt, scrypt, Argon2). Always ensure proper file permissions on the CUPS password file (e.g., <i>/etc/cups/passwd.md5</i>) to prevent unauthorized access.


title: PASSWORD FILE LOCATION
content:
The default password file used by <i>lppasswd</i> is typically <i>/etc/cups/passwd.md5</i>. This file contains username:encrypted_password pairs and must be readable by the CUPS daemon (<i>cupsd</i>) but ideally only writable by the root user (or the `lp` group if configured) to maintain security. Users can specify a different file using the <i>-x</i> option if necessary.


title: USAGE EXAMPLE
content:
To set a password for the 'admin' user for CUPS web access:<br><i>lppasswd -a admin</i><br><br>You will then be prompted to enter and confirm the new password. This command will update the password in the default <i>/etc/cups/passwd.md5</i> file. To remove a user's password, one typically needs to manually edit the password file or ensure the user is not defined for CUPS web access if they should no longer have it.


title: HISTORY
content:
The <i>lppasswd</i> command is an integral part of the CUPS (Common Unix Printing System) suite, which was originally developed by Easy Software Products and later acquired by Apple Inc. Its existence dates back to the early days of CUPS, providing a dedicated tool for managing the system's internal web interface authentication separate from standard operating system user management. It has remained a stable utility within the CUPS ecosystem, evolving primarily in context with CUPS server functionality and security considerations, while its core purpose of local password management for CUPS administrators has remained consistent throughout its development.


title: SYNOPSIS
content:
<b>lpq</b> [<i>-P printer</i>] [<i>-l</i>] [<i>-a</i>] [<i>-s</i>] [<i>+interval</i>] [<i>job_id ...</i>] [<i>user ...</i>]


title: PARAMETERS
content:
<b><b>-P</b> <i>printer</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the printer name whose queue should be queried.</i><br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays job information in a long, more detailed format.</i><br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows the queue status for all available printers.</i><br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Provides a brief, summary-style output.</i><br><br><b><b>+</b><i>interval</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Continuously polls and updates the queue status every 'interval' seconds.</i><br><br><b><i>job_id ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays status for specific print job IDs.</i><br><br><b><i>user ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays status for jobs submitted by specific users.</i><br><br>


title: DESCRIPTION
content:
<b>lpq</b> is a command-line utility used to examine the contents of a printer's spool queue. It displays information about jobs currently waiting to be printed, including their unique job ID, owner, size, and status. This command is historically part of the traditional BSD line printer spooling system and is widely available on Linux systems, often integrated with or provided for compatibility with the Common Unix Printing System (CUPS). It empowers users to quickly check the progress of their print jobs, ascertain printer readiness, and diagnose potential printing bottlenecks.


title: CAVEATS
content:
On modern Linux, <b>lpq</b> often interacts with the Common Unix Printing System (CUPS). Its exact behavior and available options can vary based on CUPS configuration or specific <b>lpq</b> implementation. Functionality might be limited if CUPS is not running or properly configured, or if the system uses an entirely different print spooler.


title: UNDERSTANDING OUTPUT
content:
The output typically includes the job's queue position, owner, size, and the file name(s) being printed. A 'status' column indicates if a job is active, waiting, or held. If no output appears, the queue is likely empty or no jobs match the criteria.


title: INTEGRATION WITH CUPS
content:
While conceptually rooted in BSD, modern <b>lpq</b> on Linux often functions as a client to the CUPS daemon. This means its capabilities and the interpretation of its output are dependent on the underlying CUPS configuration and server status.


title: HISTORY
content:
<b>lpq</b> traces its origins to the Berkeley Software Distribution (BSD) printing system, a foundational component of early Unix-like operating systems. It was a key utility in the <b>lpr</b>/<b>lpd</b> suite, designed for managing print jobs on network printers. While the Common Unix Printing System (CUPS) largely replaced the BSD printing model on Linux, <b>lpq</b> is retained for backward compatibility, frequently acting as a wrapper that translates traditional commands into CUPS operations.


title: SYNOPSIS
content:
<pre>lpr [OPTIONS] [FILE...]</pre><pre>lpr [-P <i>destination</i>] [-# <i>num-copies</i>] [-J <i>job-name</i>] [-o <i>option=value</i>] [<i>file</i>...]</pre>


title: PARAMETERS
content:
<b><b>-P</b> <i>destination</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the printer or class to send the job to. If not specified, the default printer is used.<br><br><b><b>-#</b> <i>num-copies</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the specified number of copies of each file.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not print the standard banner page or header for the job.<br><br><b><b>-J</b> <i>job-name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the job name, which may be displayed in the print queue.<br><br><b><b>-o</b> <i>option=value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes a specific option to the printer backend. Common options include <I>media</I>=<I>size</I>, <I>orientation</I>=<I>landscape</I>, <I>sides</I>=<I>two-sided-long-edge</I>, <I>fit-to-page</I>, etc.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the input file(s) after successfully spooling the print job. Use with caution.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the file literally, without any filtering or formatting. This is useful for printing files that are already formatted for a specific printer, such as PostScript files.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a symbolic link to the print file instead of copying it to the spool directory. This means the original file must remain accessible and unchanged until the job is printed. (Note: CUPS <code>lpr</code> always copies files by default, so <code>-s</code> may have specific behavior or be ignored depending on implementation).<br><br><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;Displays the CUPS version information and exits.<br><br>


title: DESCRIPTION
content:
<code>lpr</code> is a command-line utility used to submit print jobs to a printer or print queue. Historically, it originated from the Berkeley Software Distribution (BSD) Unix printing system, where <code>lpr</code> stood for "line printer remote." On modern Linux systems, <code>lpr</code> is typically provided by the Common Unix Printing System (CUPS) and serves as a compatibility layer or wrapper for CUPS's internal printing mechanisms. When you use <code>lpr</code>, the specified file(s) (or standard input) are sent to the CUPS spooler, which then processes them according to the printer's configuration (e.g., converting formats like PDF, PostScript, images, or plain text) and sends them to the designated printer. It offers various options to control job attributes like destination printer, number of copies, job title, and printing options.


title: CAVEATS
content:
Modern <code>lpr</code> on Linux systems relies heavily on the CUPS daemon (<code>cupsd</code>) being active and correctly configured. If CUPS is not running or printers are not set up, <code>lpr</code> will fail.<br>The behavior of <code>lpr</code> (especially regarding options like <code>-s</code> or <code>-h</code>) can differ significantly between the older BSD <code>lpr</code> implementation and the current CUPS <code>lpr</code>. This analysis focuses on the CUPS version.<br>By default, <code>lpr</code> copies the input file(s) to a spool directory. This ensures the file is available even if the original is deleted or modified before printing. The <code>-s</code> option can override this, but requires the original file to persist.


title: DEFAULT PRINTER SELECTION
content:
The default printer <code>lpr</code> uses can be determined by several factors, in order: the <code>LPDEST</code> environment variable, the <code>PRINTER</code> environment variable, or the system-wide default printer configured in CUPS (usually through <code>/etc/cups/printers.conf</code>).


title: PRINTER DISCOVERY
content:
You can list available printers configured on your system using commands like <code>lpstat -p -d</code> or <code>lpstat -a</code>.


title: RAW VS. FILTERED PRINTING
content:
By default, <code>lpr</code> (via CUPS) attempts to filter input files (e.g., converting PDF to PostScript or a printer-specific language). The <b>-l</b> (literal) option can be used to send files directly to the printer without filtering, which is useful for files already in the printer's native language or for troubleshooting.


title: HISTORY
content:
The <code>lpr</code> command originated as part of the Berkeley Software Distribution (BSD) Unix printing system in the 1980s, designed to interface with line printers. Its name, "line printer remote," reflects its initial purpose of sending jobs to printers across a network. With the rise of Linux, many systems initially adopted similar BSD-style printing systems. However, the Common Unix Printing System (CUPS) emerged in the late 1990s as a more robust, modern, and cross-platform printing solution. CUPS rapidly became the de facto standard for Unix-like operating systems, including Linux. Consequently, the <code>lpr</code> command on most contemporary Linux distributions is now a part of the CUPS suite, often being a symbolic link or a wrapper that calls the CUPS <code>lp</code> command internally, maintaining backward compatibility with older scripts and user habits while leveraging CUPS's advanced features and printer support.


title: PARAMETERS
content:
<b><i>-Pprinter</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the printer queue from which to remove jobs. If omitted, the default printer is used (usually defined by system configuration or the PRINTER environment variable).<br><br><b><i>-</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all jobs owned by the current user from the specified or default printer queue. This option is often restricted to the superuser for security reasons on some systems.<br><br><b><i>job #...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A space-separated list of one or more job numbers to be removed. Job numbers can be found by inspecting the print queue using the <b>lpq</b> command.<br><br><b><i>user ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A space-separated list of one or more usernames. This removes all jobs belonging to the specified users from the queue. This option typically requires superuser privileges.<br><br>


title: DESCRIPTION
content:
<b>lprm</b> is a command-line utility used to remove print jobs that are currently queued for printing on a line printer. It interacts with the printer spooling system, typically <i>lpr/lpd</i> (Line Printer Daemon) or CUPS (Common Unix Printing System) which often emulates <i>lpd</i> functionality.<br><br>Users can remove their own jobs by specifying job numbers, or remove all their own jobs from a queue. The superuser can remove any job from any queue, including jobs owned by other users or all jobs from a specific queue. This command is crucial for managing print queues, especially when a print job is stuck, sent incorrectly, or no longer needed, allowing for efficient control over printing resources.


title: CAVEATS
content:
<ul><li><b>Permissions:</b> Users can only remove their own print jobs unless they have superuser (root) privileges. Attempting to remove another user's job without proper permissions will result in an error.</li><li><b>Job in Progress:</b> <b>lprm</b> cannot stop a job that is already actively being printed by the printer hardware itself. It only removes jobs from the queue before they reach the printer or if they are still being spooled.</li><li><b>Spool Directory:</b> The command operates on the spool directory where print jobs are temporarily stored. Issues with this directory's permissions or disk space can affect <b>lprm</b>'s operation.</li><li><b>Network Printers:</b> For network printers, the job might be spooled on a remote server. <b>lprm</b> needs to communicate with that server, and network issues or server misconfigurations can prevent it from working correctly.</li></ul>


title: DEFAULT BEHAVIOR
content:
If no arguments are provided to <b>lprm</b> (i.e., no printer, no job number, no user, and not the '<b>-</b>' option), it will not remove any jobs. Instead, it will typically display a usage message indicating the correct syntax for the command, requiring at least one valid argument to perform an action.


title: ENVIRONMENT VARIABLES
content:
The <i>PRINTER</i> environment variable can be set by the user to specify a default printer. When this variable is set, <b>lprm</b> will operate on that printer queue by default, overriding the system's default printer definition and eliminating the need to use the <i>-P</i> option explicitly for every command.


title: HISTORY
content:
<b>lprm</b> is an integral part of the original BSD printing system, which was widely adopted across Unix-like operating systems. It was specifically designed to work with the <i>lpd</i> (Line Printer Daemon) protocol for managing networked printers. While many modern Linux distributions now use CUPS (Common Unix Printing System) as their default printing backend, <b>lprm</b> is commonly provided for backward compatibility. CUPS emulates the behavior of the traditional BSD printing commands, ensuring that existing scripts and user workflows familiar with <b>lprm</b> continue to function seamlessly. Its fundamental functionality has remained largely consistent since its inception, reflecting a core requirement for managing print queues efficiently.


title: SYNOPSIS
content:
lpstat [ <b>-E</b> ] [ <b>-H</b> ] [ <b>-U</b> <i>username</i> ] [ <b>-l</b> ] [ <b>-v</b> ] [ <b>-a</b> [<i>destination(s)</i>] ] [ <b>-c</b> [<i>class(s)</i>] ] [ <b>-d</b> ] [ <b>-p</b> [<i>destination(s)</i>] ] [ <b>-o</b> [<i>destination(s)</i>] ] [ <b>-r</b> ] [ <b>-s</b> ] [ <b>-t</b> ] [ <b>-u</b> [<i>user(s)</i>] ] [ <b>-W</b> <i>job-attribute</i> ]


title: PARAMETERS
content:
<b><b>-E</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces encryption when communicating with the CUPS server, ensuring secure transmission of data.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the hostname and port of the CUPS server being used for printing operations.<br><br><b><b>-U</b> <i>username</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate username to use for authentication with the CUPS server, useful for administrative tasks.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a <i>long</i> listing format, showing more detailed information for printers or jobs than the default output.<br><br><b><b>-v</b> [<i>destination(s)</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the device URI (Uniform Resource Identifier) for specified printers, indicating where they are physically connected or located on the network.<br><br><b><b>-a</b> [<i>destination(s)</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports whether specified printers are currently <i>accepting</i> new print jobs into their queues.<br><br><b><b>-c</b> [<i>class(s)</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the printers that are members of the specified print <i>classes</i>, which group multiple printers together.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <i>default</i> printer or print class configured for the system, which is used when no specific destination is provided.<br><br><b><b>-p</b> [<i>destination(s)</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current <i>status</i> of specified printers, including whether they are enabled, idle, or experiencing issues.<br><br><b><b>-o</b> [<i>destination(s)</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all active print <i>jobs</i> in the queue for specified destinations. If no destination is given, it lists all jobs.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the status of the CUPS <i>scheduler</i> (server), indicating if it is running and processing print requests.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a <i>summary</i> of printer status, including the default printer, scheduler status, and a list of all detected printers.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <i>all</i> available status information: scheduler status, all known destinations (printers and classes), and all active jobs.<br><br><b><b>-u</b> [<i>user(s)</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows print jobs submitted by specified <i>users</i>. If no username is given, it lists jobs for all users.<br><br><b><b>-W</b> <i>job-attribute</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the type of jobs to display based on their status. Common attributes include <i>completed</i>, <i>not-completed</i>, and <i>processing</i>.<br><br>


title: DESCRIPTION
content:
<i>lpstat</i> is a command-line utility used to display status information about the CUPS (Common Unix Printing System) printing environment.<br><br>It allows users and administrators to monitor various aspects of the printing system, including the status of printers, print classes, and individual print jobs. Users can query whether a printer is enabled and accepting jobs, retrieve reasons for a printer being unavailable, and list jobs currently in the print queue. For each job, <i>lpstat</i> typically shows the job ID, the user who submitted it, the file size, and its current status.<br><br>This command is invaluable for troubleshooting printing problems, checking job progress, and generally maintaining an overview of the printing infrastructure. It provides crucial insights into the operational state of the printing system.


title: CAVEATS
content:
<i>lpstat</i> relies on the CUPS daemon (<i>cupsd</i>) being active and accessible. If CUPS is not running or network connectivity to the CUPS server is interrupted, the command will fail or provide incomplete information.<br><br>While <i>lpstat -t</i> provides a comprehensive overview, its output can be very verbose in environments with many printers or jobs. Users typically only see their own print jobs unless they have administrator privileges, in which case they can view all jobs.


title: COMMON USE CASES
content:
<i>lpstat</i> is frequently used for quick diagnostics and monitoring of the printing system. For example, <i>lpstat -s</i> provides a concise summary of the default printer and scheduler status, giving a quick overview of the system's health.<br><br>To check a specific printer's operational state and identify potential issues, users often run <i>lpstat -p printer_name</i>. To view all active jobs currently in the print queue, <i>lpstat -o</i> is an essential command. For checking jobs submitted by a particular user, <i>lpstat -u username</i> is very helpful for both individual users and system administrators.


title: HISTORY
content:
The <i>lpstat</i> command has its origins in the traditional System V printing system (<i>lp</i>), which was prevalent in Unix-like operating systems. However, with the widespread adoption of CUPS (Common Unix Printing System) as the standard printing architecture in modern Linux and other Unix-like environments, <i>lpstat</i> was reimplemented as an integral part of the CUPS suite.<br><br>This integration ensures seamless interaction with the CUPS daemon and its advanced features, effectively replacing older, less flexible printing solutions. Its development has mirrored the evolution of printing in Unix environments, adapting to networked printing and sophisticated printer capabilities while retaining a familiar command-line interface.


title: DESCRIPTION
content:
<b>lrunzip</b> is a highly specialized utility designed for decompressing files that have been compressed using the Lempel-Ziv-Ross (LZR) algorithm. It is crucial to understand that this command is <I>not</I> a general-purpose tool for handling common <I>.zip</I> archives created by utilities like <I>zip</I> or <I>unzip</I>, nor is it for <I>.gz</I> files. Its primary use case is within contexts involving embedded systems, firmware development, or specific hardware where data is compressed with LZR for storage or transmission efficiency. The command takes a single LZR-compressed file as input and decompresses its contents, typically writing the output to a specified file or standard output. Its availability and functionality are often tied to specific vendor toolchains rather than being a standard component of general Linux distributions.


title: CAVEATS
content:
<b>Not for Standard ZIP Files:</b> <b>lrunzip</b> exclusively handles LZR-compressed data and will not work with standard <I>.zip</I> archives or other common compression formats like <I>.gz</I> or <I>.bz2</I>.<br><br><b>Niche Utility:</b> This command is highly specialized and often found as part of specific firmware development toolchains. It is typically not pre-installed on general-purpose Linux distributions.<br><br><b>Limited Interface:</b> Most implementations of <b>lrunzip</b> are very simple, accepting only input and optional output filenames without a wide range of command-line options or flags.


title: ALGORITHM SPECIFICITY
content:
The Lempel-Ziv-Ross (LZR) algorithm is a variant of the Lempel-Ziv family of data compression algorithms. While related in principle to algorithms used in <I>ZIP</I> or <I>GZIP</I>, LZR has specific characteristics that necessitate a dedicated decompression utility like <b>lrunzip</b>. It is optimized for certain data types or hardware constraints found in embedded systems.


title: USAGE CONTEXT
content:
Users are most likely to encounter <b>lrunzip</b> when working with custom firmware, device drivers, or bootloader images for specific networking equipment (e.g., routers) or other embedded devices. It is used to extract uncompressed data from firmware binaries that incorporate LZR compression.


title: HISTORY
content:
The history of <b>lrunzip</b> is not widely documented as a standalone command. It is typically developed as part of proprietary or open-source toolchains for specific hardware platforms that utilize the LZR compression algorithm, often for bootloaders or firmware images. Its development is generally tied to the needs of these specific embedded system environments rather than evolving as a general-purpose compression utility.


title: SYNOPSIS
content:
<b>lrzip</b> [<i>options</i>] [<i>files...</i>]<br><b>lrzip</b> <i>-d</i> [<i>options</i>] [<i>files...</i>]<br><b>lrzip</b> <i>-t</i> [<i>options</i>] [<i>files...</i>]<br><b>lrzip</b> <i>-l</i> [<i>options</i>] [<i>files...</i>]


title: PARAMETERS
content:
<b><b>-z</b>, <b>--compress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compress the specified files. This is the default action.<br><br><b><b>-d</b>, <b>--decompress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress the specified files.<br><br><b><b>-t</b>, <b>--test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the integrity of the compressed files without decompressing them.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the contents (e.g., uncompressed size, compression ratio) of the compressed files.<br><br><b><b>-o</b> <i>&lt;file&gt;</i>, <b>--output</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file name instead of the default.<br><br><b><b>-L</b> <i>&lt;level&gt;</i>, <b>--level</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the compression level, where 1 is fastest/least compression and 9 is slowest/most compression. A level of 0 implies the best compression.<br><br><b><b>-C</b> <i>&lt;algo&gt;</i>, <b>--compress-alg</b> <i>&lt;algo&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the compression algorithm to use (e.g., <i>LZMA</i>, <i>BZIP2</i>, <i>GZIP</i>, <i>LZO</i>, <i>LZ4</i>, <i>ZSTD</i>, <i>BROTLI</i>). Default is LZMA.<br><br><b><b>-m</b> <i>&lt;MB&gt;</i>, <b>--memory</b> <i>&lt;MB&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum memory usage for compression in megabytes. Higher values can improve compression ratio but require more RAM.<br><br><b><b>-p</b> <i>&lt;threads&gt;</i>, <b>--threads</b> <i>&lt;threads&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified number of CPU threads for compression or decompression.<br><br><b><b>-U</b>, <b>--unlink</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete the source file after successful compression or decompression.<br><br><b><b>--sparse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Handle sparse files efficiently, preserving sparse regions and reducing output size.<br><br><b><b>--recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on files within directories recursively. Note: This compresses each file individually, not the directory structure into a single archive.<br><br><b><b>--exclude</b> <i>&lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files matching the specified pattern from compression.<br><br><b><b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform an integrity check (CRC or MD5) after compression to ensure data validity.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warnings and messages during operation.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more information during operation, such as progress and statistics.<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>lrzip</b> is a highly efficient compressor designed to achieve extremely high compression ratios, especially on large files. It leverages multiple compression algorithms, primarily LZMA for its core compression engine, combined with an LZP preprocessor and optional Bzip2, Gzip, LZO, LZ4, ZSTD, or Brotli filters. This multi-algorithm approach, along with its ability to utilize multiple CPU cores and large memory pages, allows <b>lrzip</b> to deliver superior compression performance and speed, particularly for data that is difficult for other compressors to handle. It's often chosen for archiving large datasets, backups, and any scenario where maximizing disk space savings is paramount, without sacrificing decompression speed significantly.


title: CAVEATS
content:
While <b>lrzip</b> excels at high compression, particularly on large files, achieving the highest compression ratios often requires significant memory. Users should monitor memory usage, especially with the <i>--best</i> or higher <i>--level</i> options. Additionally, <b>lrzip</b> is a file compressor, not a general-purpose archiving tool like <b>tar</b>. It does not natively preserve file permissions, ownership, or directory structures within a single archive. For full directory archiving, it's typically combined with <b>tar</b> (e.g., <br><b>tar -cf - <i>dir</i> | lrzip &gt; <i>archive.lrz</i></b>). The <i>--recursive</i> option compresses individual files within directories, not the directory as a whole.


title: WORKING WITH DIRECTORIES
content:
<b>lrzip</b> operates primarily on individual files. While the <i>--recursive</i> option allows it to process files within directories, it compresses each file separately rather than bundling them into a single archive file (like a <b>.tar.lrz</b>). To archive entire directories with their structure, permissions, and ownership, <b>lrzip</b> is commonly piped with <b>tar</b>. For example, to create an archive of a directory:<br><b>tar -cf - <i>mydir</i> | lrzip -o <i>mydir.tar.lrz</i></b><br>To extract a <b>tar.lrz</b> archive:<br><b>lrzunzip -o - <i>mydir.tar.lrz</i> | tar -xf -</b>


title: COMPRESSION ALGORITHMS AND MEMORY
content:
<b>lrzip</b> supports a range of compression algorithms, controllable via the <i>--compress-alg</i> (<i>-C</i>) option. The default and generally most effective is LZMA, often combined with an LZP preprocessor. Other supported algorithms include BZIP2, GZIP, LZO, LZ4, ZSTD, and Brotli, each offering different trade-offs between compression ratio and speed. Higher compression levels (<i>-L 0</i> or <i>--best</i>) and larger dictionary sizes significantly increase memory requirements during compression. For example, compressing a large file with default LZMA settings might require hundreds of megabytes or even gigabytes of RAM depending on the file size and desired compression. Decompression, however, typically uses much less memory, making <b>lrzip</b> suitable for distribution where decompression speed and memory usage are critical.


title: HISTORY
content:
<b>lrzip</b> was developed by <i>Con Kolivas</i>, a well-known Linux kernel developer famous for his work on CPU schedulers (e.g., BFS). The project emerged from a desire to create a compressor that specifically targeted large files, offering superior compression ratios and performance compared to existing tools like <b>gzip</b> and <b>bzip2</b>, especially when combined with high-memory systems. Its design emphasizes speed during decompression and efficient use of system resources for very high compression, continuing the legacy of his earlier <i>rzip</i> project.


title: SYNOPSIS
content:
Although not a direct command, <i>"lrztar"</i> operations are commonly performed using <b>tar</b> with the <b>-I lrzip</b> option:<br><br><b>To create an lrztar archive:</b><br><b>tar -I lrzip -cvf </b><i>&lt;archive_name.tar.lrz&gt; &lt;path/to/files/or/directories&gt;...</i><br><br><b>To extract from an lrztar archive:</b><br><b>tar -I lrzip -xvf </b><i>&lt;archive_name.tar.lrz&gt;</i>


title: PARAMETERS
content:
<b><b>-c</b>, <b>--create</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new archive.<br><br><b><b>-x</b>, <b>--extract</b>, <b>--get</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files from an archive.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbosely list files processed (show progress).<br><br><b><b>-f</b>, <b>--file=</b><i>&lt;ARCHIVE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use archive file <i>&lt;ARCHIVE&gt;</i>. For <i>"lrztar"</i>, this is the <i>.tar.lrz</i> file.<br><br><b><b>-I</b>, <b>--use-compress-program=</b><i>&lt;PROGRAM&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter the archive through <i>&lt;PROGRAM&gt;</i> (here, <b>lrzip</b>). This is the key option for <i>"lrztar"</i>.<br><br><b><b>-p</b>, <b>--preserve-permissions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files preserving their original permissions (relevant for extraction).<br><br><b><b>--remove-files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove source files after adding them to the archive (use with caution).<br><br>


title: DESCRIPTION
content:
The term <i>"lrztar"</i> is not a standard, standalone Linux command. It is a colloquial or conceptual term that typically refers to the process of creating or extracting <b>TAR</b> archives that have been compressed using the <b>lrzip</b> compression utility. <br><br><b>TAR</b> (Tape ARchive) is a widely used archiving utility that bundles multiple files and directories into a single archive file, preserving file permissions, timestamps, and directory structures. It does not inherently provide compression. <br><br><b>lrzip</b> is a highly efficient and fast compressor, often surpassing <b>gzip</b>, <b>bzip2</b>, and <b>xz</b> in compression ratio and speed, especially on multi-core systems due to its support for multithreading. It is a successor to the <b>rzip</b> compressor. <br><br>When users refer to <i>"lrztar"</i>, they generally mean using <b>tar</b> with <b>lrzip</b> as its compression filter (e.g., via <b>tar -I lrzip</b>) or piping the output of <b>tar</b> to <b>lrzip</b>, to create archives with a high compression ratio. The resulting archive file typically has a <i>.tar.lrz</i> or <i>.tlrz</i> extension.


title: CAVEATS
content:
<i>"lrztar"</i> is <b>not a direct command</b>; it refers to a specific usage pattern of <b>tar</b> and <b>lrzip</b>.<br>Both <b>tar</b> and <b>lrzip</b> utilities must be installed on the system for this operation to work.<br>Decompressing an <i>.lrz</i> archive requires the <b>lrzip</b> utility.<br>While <b>lrzip</b> offers high compression, it can be slower than <b>gzip</b> for very small files due to its more complex algorithms.


title: USAGE EXAMPLES
content:
<b>1. Create an lrztar archive of a directory:</b><br><i>tar -I lrzip -cvf my_archive.tar.lrz /path/to/my_directory</i><br><br><b>2. Extract an lrztar archive:</b><br><i>tar -I lrzip -xvf my_archive.tar.lrz</i><br><br><b>3. Pipe tar output to lrzip (alternative method for creation):</b><br><i>tar -cvf - /path/to/my_directory | lrzip -o my_archive.tar.lrz</i><br><br><b>4. Decompress an .lrz file (if not a .tar.lrz archive):</b><br><i>lrzip -d my_file.lrz</i>


title: HISTORY
content:
<b>TAR</b> (Tape Archive) originated in 1979 in Unix as a utility for archiving files to magnetic tape. It became a fundamental tool for file packaging and distribution on Unix-like systems. <br><br><b>lrzip</b> is a relatively modern compression utility, developed by Con Kolivas. It emerged as a successor to <b>rzip</b>, designed to offer superior compression ratios and performance by leveraging modern CPU architectures, including multithreading. It gained popularity for its ability to achieve high compression while maintaining decent speeds, especially for large datasets where traditional compressors might struggle.


title: PARAMETERS
content:
<b><i>-d &lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the destination directory where the received archive should be untarred. If omitted, the current directory would likely be used.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing the progress of both the file transfer and the extraction process.<br><br><b><i>-z</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that the received archive is Gzip compressed (like <B>tar -z</B>).<br><br><b><i>-j</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that the received archive is Bzip2 compressed (like <B>tar -j</B>).<br><br><b><i>-J</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that the received archive is XZ compressed (like <B>tar -J</B>).<br><br><b><i>-k</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps existing files; prevents overwriting files during extraction (like <B>tar -k</B>).<br><br>


title: DESCRIPTION
content:
<b>lrzuntar</b> is <I>not a standard Linux command</I> or utility. It appears to be a conceptual combination of the <b>lrz</b> command (part of the <b>lrzsz</b> package, used for ZMODEM/YMODEM/XMODEM file transfers over serial lines or pseudo-terminals) and the <b>tar</b> command (used for archiving and extracting files).<br><br>If <b>lrzuntar</b> were to exist as a script or custom alias, its primary function would likely be to receive an archive file (e.g., a .tar, .tar.gz, or .tgz file) via a ZMODEM transfer and then automatically extract its contents into the current directory or a specified location. This would streamline a common workflow for users transferring compressed archives over legacy serial connections or similar setups where ZMODEM is still employed.<br><br>Given its non-standard nature, the exact behavior, options, and error handling would depend entirely on its implementation. Users encountering this command should verify its source or definition within their environment.


title: CAVEATS
content:
This command is <I>not a standard Linux utility</I>. Its behavior, existence, and available options depend entirely on whether it has been custom-defined as an alias, script, or executable in a specific environment. There is no official documentation for <B>lrzuntar</B> as a standalone command. Users should exercise caution and inspect its definition before use.


title: <B>COMMON USAGE SCENARIO</B>
content:
A user connects to a remote system via a serial console (e.g., using <B>minicom</B> or <B>picocom</B>) and needs to transfer a compressed archive from the remote system to their local machine. Instead of first using <B>lrz</B> to receive the .tar.gz file and then manually running <B>tar -xzf</B> on it, a custom <B>lrzuntar</B> script on the local machine could receive the file and immediately untar it, automating the process.


title: <B>IMPLEMENTATION CONSIDERATIONS</B>
content:
A typical <B>lrzuntar</B> script might look something like this in pseudocode:<br><B>TEMP_FILE=$(lrz --force-overwrite)</B><br><B>if [ $? -eq 0 ] && [ -n "$TEMP_FILE" ]; then</B><br>&nbsp;&nbsp;<B>tar -xf "$TEMP_FILE" --directory=&lt;destination_dir&gt;</B><br>&nbsp;&nbsp;<B>rm "$TEMP_FILE"</B><br><B>fi</B><br>The complexity would increase to handle various compression types (<B>-z</B>, <B>-j</B>, <B>-J</B>) or error conditions.


title: HISTORY
content:
The concept of <B>lrzuntar</B> likely stems from the common need to automate file transfer and extraction processes in environments using serial communication. <B>lrz</B> and <B>tar</B> have been fundamental tools in Unix-like systems for decades. <B>lrz</B> (part of the <B>lrzsz</B> package) emerged for reliable file transfers over serial lines, predating widespread network access. <B>tar</B> dates back to the early days of Unix for tape archiving. A hypothetical <B>lrzuntar</B> would represent a user-created convenience wrapper, combining these two classic utilities to simplify a multi-step operation into a single command.


title: PARAMETERS
content:
<b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ignore entries starting with . (dotfiles).<br><br><b><i>-l</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a long listing format, showing permissions, number of hard links, owner, group, size, and modification time.<br><br><b><i>-h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;With <i>-l</i>, print sizes in human readable format (e.g., 1K, 234M, 2G).<br><br><b><i>-R</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List subdirectories recursively.<br><br><b><i>-t</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort by modification time, newest first.<br><br><b><i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverse order while sorting.<br><br><b><i>-S</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort by file size, largest first.<br><br><b><i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List directory entries themselves, not their contents. Useful for seeing information about the directory itself.<br><br><b><i>-F</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append an indicator (one of */=@|) to entries.<br><br><b><i>-i</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the index number (inode) of each file.<br><br><b><i>-k</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print sizes in 1K blocks, overriding POSIXLY_CORRECT.<br><br><b><i>-m</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fill width with a comma separated list of entries.<br><br><b><i>-n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like <i>-l</i> but list numeric user and group IDs.<br><br><b><i>-o</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like <i>-l</i> but do not show group information.<br><br><b><i>-g</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like <i>-l</i> but do not show owner information.<br><br><b><i>-Q</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enclose entry names in double quotes.<br><br><b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the allocated size of each file, in blocks.<br><br><b><i>-u</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;With <i>-t</i>, sort by access time; with <i>-l</i>, show access time.<br><br><b><i>-X</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort alphabetically by entry extension.<br><br><b><i>-1</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List one file per line.<br><br>


title: DESCRIPTION
content:
The <i>ls</i> command is one of the most fundamental and frequently used commands in Unix-like operating systems. It is used to list the contents of directories. When executed without any arguments, <i>ls</i> displays the names of files and subdirectories in the current working directory.<br><br>With various options, <i>ls</i> can provide detailed information about files, such as their permissions, ownership, size, last modification time, and inode number. It can also sort output in different ways, display hidden files, and recursively list the contents of subdirectories. Its primary purpose is to help users navigate and understand the file system structure by showing what's inside a directory.


title: CAVEATS
content:
The exact behavior and available options of <i>ls</i> can vary slightly between different Unix-like systems (e.g., GNU <i>ls</i> vs. BSD <i>ls</i>).<br><br>Output parsing: While <i>ls</i> output is human-readable, parsing it programmatically is generally discouraged due to variability in formatting and potential issues with special characters in filenames. For scripting, <i>find -print0</i> and <i>xargs -0</i> or <i>stat</i> are preferred.


title: INTERPRETING <I>LS -L</I> OUTPUT
content:
The long listing format provided by <i>ls -l</i> offers a wealth of information:<br><ul><li>First character: file type (<i>d</i> for directory, <i>-</i> for regular file, <i>l</i> for symbolic link, etc.)</li><li>Next 9 characters: file permissions (read, write, execute for owner, group, others)</li><li>Number: number of hard links</li><li>First name: owner of the file</li><li>Second name: group owner of the file</li><li>Number: file size in bytes (or human-readable with <i>-h</i>)</li><li>Date/Time: last modification time</li><li>Last field: filename</li></ul>


title: HIDDEN FILES
content:
Files and directories whose names begin with a dot (<i>.</i>) are considered "hidden" by convention. <i>ls</i> does not show them by default. To display them, the <i>-a</i> (all) option must be used, e.g., <i>ls -a</i>.


title: HISTORY
content:
The <i>ls</i> command dates back to the earliest versions of Unix. It was one of the first utilities available in AT&T Unix, originating from the <i>list</i> command on Multics. Over time, it has evolved from a simple listing tool to a powerful command with numerous options, particularly with the GNU Core Utilities implementation, which added many features not present in traditional Unix versions. Its core functionality, however, has remained consistent: displaying directory contents.


title: SYNOPSIS
content:
<b>sar</b> [ <i>options</i> ] [ <i>interval</i> [ <i>count</i> ] ]<br><b>sar</b> [ <i>options</i> ] <b>-f</b> <i>filename</i>


title: PARAMETERS
content:
<b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report all activities. This is equivalent to specifying all available options.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report CPU utilization statistics. The <i>interval</i> and <i>count</i> parameters specify the sampling rate and number of samples.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report memory utilization statistics (e.g., free memory, used memory, buffer and cache sizes).<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report I/O and transfer rate statistics for block devices.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report activity for each block device (e.g., read/write operations per second, average queue length).<br><br><b><b>-n</b> <i>{keyword | ALL}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report network statistics. Use keywords like 'DEV' (network interfaces), 'IP', 'TCP', 'UDP', 'SOCK' (sockets), or 'ALL' for comprehensive network data.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report queue length and load averages (e.g., run queue length, number of tasks).<br><br><b><b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report task creation and context switching statistics.<br><br><b><b>-W</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report swapping activity statistics (e.g., pages swapped in/out).<br><br><b><b>-f</b> <i>filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract records from <i>filename</i>, which is a daily data file created by the <i>sadc</i> daemon or by <i>sar -o</i>.<br><br><b><b>-o</b> <i>filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the collected data in binary format to <i>filename</i>. This data can be viewed later using <i>sar -f</i>.<br><br><b><b>-s</b> <i>HH:MM:SS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the starting time of the data collection for the report (inclusive).<br><br><b><b>-e</b> <i>HH:MM:SS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the ending time of the data collection for the report (inclusive).<br><br><b><i>interval</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Time in seconds between each sample. Used for real-time data collection when no <i>filename</i> is specified.<br><br><b><i>count</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of samples to collect. Used for real-time data collection in conjunction with <i>interval</i>.<br><br>


title: DESCRIPTION
content:
<i>sar</i> (System Activity Reporter) is a powerful command-line utility for collecting, reporting, and saving system activity information. Part of the <i>sysstat</i> package, it monitors various system resources including CPU utilization, memory and swap usage, disk I/O, network activity, process statistics, and more.<br><br>It can display real-time performance data by specifying an <i>interval</i> and <i>count</i>, or analyze historical data stored in daily activity log files, usually located in <i>/var/log/sysstat</i> or <i>/var/log/sa</i>. <i>sar</i> is invaluable for system administrators and performance analysts to diagnose bottlenecks, track resource usage over time, and understand system behavior patterns. It provides a comprehensive view of system health and performance trends over time.


title: CAVEATS
content:
The command '<b>lsar</b>' is not a standard Linux command found in common distributions. This analysis assumes the user intended to inquire about the '<b>sar</b>' (System Activity Reporter) command, a widely used utility for system performance monitoring and analysis. If '<b>lsar</b>' refers to a custom script, an alias, or a command from a specific, non-standard software package, this information may not apply.


title: DAILY DATA FILES
content:
By default, <b>sar</b> collects daily activity data through the <b>sadc</b> daemon (System Activity Data Collector) and stores it in binary format in files, typically found in <i>/var/log/sysstat/saDD</i> (where DD is the day of the month). These files are usually managed by cron jobs executing <b>sa1</b> (daily data collection) and <b>sa2</b> (daily report generation) scripts. These historical data files can be later analyzed using <b>sar -f</b>.


title: CONFIGURATION
content:
The data collection frequency and retention policies for <b>sar</b> and the <b>sysstat</b> package are typically configured through files such as <i>/etc/default/sysstat</i> or <i>/etc/sysstat/sysstat</i>. These configuration files control the parameters for the cron jobs that run <b>sa1</b> (to collect data) and <b>sa2</b> (to generate daily reports), allowing administrators to tailor monitoring to their specific needs.


title: HISTORY
content:
The <b>sysstat</b> package, which includes <b>sar</b>, has a long and influential history in Unix-like systems. It originated from System V Unix's performance tools, providing a standardized suite for system monitoring. <b>sar</b> specifically became a foundational tool for system administrators to track resource utilization, diagnose performance bottlenecks, and analyze system behavior over time. It has continually evolved, incorporating new metrics and capabilities to adapt to changing hardware architectures and operating system complexities, cementing its role as an indispensable utility for system performance management.


title: PARAMETERS
content:
<b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively list attributes of directories and their contents.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all files in directories, including those starting with '.' (hidden files) and the '.' and '..' entries.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List attributes of directories themselves, rather than their contents.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <I>file's version/generation number</I>.<br><br><b><b>-j</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <I>ext3/ext4</I> journal status for files. This option is specific to these filesystems.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <I>long flag names</I> instead of single-character abbreviations (e.g., 'immutable' instead of 'i').<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <I>version information</I> for <I>lsattr</I> and exit.<br><br><b><b>files...</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more <I>files</I> or <I>directories</I> whose attributes are to be listed. If none are specified, the current directory's contents are listed.<br><br>


title: DESCRIPTION
content:
<I>lsattr</I> is a command-line utility in Linux used to list the extended attributes of files and directories on filesystems, primarily <I>ext2</I>, <I>ext3</I>, and <I>ext4</I>. These attributes, often referred to as <I>file attributes</I> or <I>i-node flags</I>, are distinct from standard file permissions and are managed by the <I>chattr</I> command. They provide a finer grain of control over how files can be accessed or modified by the kernel. For example, attributes can make a file immutable ('i'), append-only ('a'), or prevent its modification even by the root user, enhancing security and data integrity. <br><br>The output of <I>lsattr</I> shows a string of characters, where each character represents a specific attribute (e.g., 'i' for immutable, 'a' for append-only). Understanding these attributes is crucial for system administrators to manage system integrity, prevent accidental deletions, or optimize filesystem performance. It's an essential tool for auditing file properties beyond standard permissions.


title: CAVEATS
content:
<I>lsattr</I> primarily operates on <I>ext2</I>, <I>ext3</I>, and <I>ext4</I> filesystems, where these i-node attributes are natively supported and managed. While some other filesystems (like <I>XFS</I>, <I>Btrfs</I>) might expose a limited set of these attributes via compatibility layers, their behavior may vary or not be fully supported. <br><br>It's crucial to distinguish these i-node attributes from general <I>extended attributes</I> (<I>xattrs</I>) which are managed by commands like <I>getfattr</I> and <I>setfattr</I>. <I>lsattr</I> deals specifically with kernel-level file flags that control fundamental file behaviors, often related to security and integrity, rather than arbitrary user-defined metadata. Root privileges are often required to change some of these attributes, and certain attributes (like 'i' for immutable) can prevent even root from modifying or deleting a file.


title: COMMON FILE ATTRIBUTES
content:
The output of <I>lsattr</I> typically shows a string of characters, each representing a specific attribute. Below are some of the most common ones:<br><b>a</b>: <I>Append-only</I> - a file can only be opened in append mode for writing.<br><b>i</b>: <I>Immutable</I> - a file cannot be modified, deleted, renamed, or linked. Not even by the root user.<br><b>A</b>: <I>No atime updates</I> - suppresses updates to the file's last access time, useful for performance on frequently accessed files.<br><b>d</b>: <I>No dump</I> - a file will not be considered for backup by the <I>dump</I> utility.<br><b>S</b>: <I>Synchronous updates</I> - changes to the file are written to disk synchronously.<br><b>s</b>: <I>Secure deletion</I> - when the file is deleted, its blocks are zeroed out (not commonly implemented).<br><b>u</b>: <I>Undeletable</I> - a file cannot be deleted (reserved for future use, not commonly implemented).<br><b>D</b>: <I>Synchronous directory updates</I> - for directories, changes are written to disk synchronously.<br><b>e</b>: <I>Extent format</I> - file uses extents for mapping data blocks (default on <I>ext4</I>).


title: HISTORY
content:
<I>lsattr</I> is a core utility within the <I>e2fsprogs</I> package, a collection of userspace utilities for managing the <I>ext2</I>, <I>ext3</I>, and <I>ext4</I> filesystems in Linux. Its development is deeply intertwined with the evolution of these filesystems, which were primarily developed by Theodore Ts'o. As <I>ext</I> filesystems became the standard for Linux, tools like <I>lsattr</I> and <I>chattr</I> became essential for system administrators to leverage the advanced file attribute capabilities offered by the kernel, allowing for stricter control over file integrity and system security.


title: PARAMETERS
content:
<b>-i, --id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the distributor ID.<br><br><b>-d, --description</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the description of the distribution.<br><br><b>-r, --release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the release number of the distribution.<br><br><b>-c, --codename</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the codename of the distribution.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all available information (ID, Description, Release, Codename).<br><br><b>-s, --short</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all information in a short, terse format, suitable for scripts.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the <i>lsb_release</i> utility itself.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<i>lsb_release</i> is a command-line utility used to display distribution-specific information, conforming to the Linux Standard Base (LSB) specification. The LSB aims to standardize the internal structure of Linux systems, allowing third-party applications to run on a wider range of Linux distributions. This command provides crucial details about the current operating system, such as the distributor ID, release version, codename, and a descriptive string. It's particularly useful for scripts that need to identify the exact Linux distribution and its version to perform conditional actions or checks. By querying the system's LSB data, <i>lsb_release</i> helps ensure compatibility and provides a standardized way to retrieve system identification information. It is widely used in automated environments and for troubleshooting to quickly ascertain the OS specifics without parsing various system files.


title: CAVEATS
content:
The <i>lsb_release</i> command relies on the presence and correctness of the <i>lsb-release</i> package or equivalent files (e.g., <I>/etc/lsb-release</I>, <I>/etc/os-release</I>) on the system. If these files are missing, malformed, or if the distribution is not fully LSB compliant, the command may not return accurate or complete information. Its output can also be influenced by distribution-specific implementations or overrides.


title: OUTPUT FORMAT
content:
The command's output varies depending on the options used. By default or with flags like <i>--all</i>, it typically presents information in a "Key: Value" format, making it human-readable. When the <i>--short</i> option is employed, the output is condensed to a single line, often delimited by tabs or newlines, which is highly suitable for scripting and automated parsing.


title: LSB COMPLIANCE
content:
The <i>lsb_release</i> command directly reflects the information defined by the Linux Standard Base. This standard aims to ensure binary compatibility among different Linux distributions. While <i>lsb_release</i> provides this standardized information, it's important to note that a distribution's full adherence to LSB can vary. The data presented is sourced from files like <I>/etc/lsb-release</I>, which are part of the LSB specification.


title: HISTORY
content:
The <i>lsb_release</i> command is an integral part of the Linux Standard Base (LSB) project, an initiative by the Linux Foundation. The LSB was established with the primary goal of standardizing the Linux operating system, thereby reducing fragmentation and enabling software vendors to develop applications that could run on multiple LSB-compliant distributions without significant modifications. The <i>lsb_release</i> utility was created to provide a convenient and standardized way for users and scripts to query this LSB-specific information directly from the command line, offering a consistent output across various Linux distributions that adhere to the LSB specifications. Its development paralleled the evolution of the LSB itself, becoming a common tool for system identification.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show <b>all</b> block devices, including empty ones.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the <b>SIZE</b> in bytes rather than in a human-readable format.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print information about <b>discard</b> (TRIM) capabilities.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display filesystem information (<b>FSTYPE</b>, <b>LABEL</b>, <b>UUID</b>, <b>MOUNTPOINT</b>).<br><br><b>-J</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <b>JSON</b> output format.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a <b>list</b> format output rather than the default tree-like format.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display permissions, owner, and group information (<b>OWNER</b>, <b>GROUP</b>, <b>MODE</b>).<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't print a <b>header</b> line.<br><br><b>-o <<i>list</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the <b>output columns</b> to be displayed. Use <i>lsblk --help</i> for available columns.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print <b>full device paths</b> (e.g., <i>/dev/sda</i> instead of <i>sda</i>).<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <b>raw</b> output format.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print inverse dependencies for a specific device, useful for LVM or RAID setups.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display <b>version</b> information.<br><br>


title: DESCRIPTION
content:
lsblk is a utility used to list information about all available block devices on a Linux system. This includes hard drives, solid-state drives (SSDs), USB drives, CD-ROMs, RAM disks, LVM (Logical Volume Manager) volumes, and their respective partitions. It presents this information in a user-friendly, tree-like format by default, showing dependencies between devices and their partitions or sub-devices.<br><br>The command is invaluable for understanding the storage layout of a system, identifying specific devices by their name, size, or mount point, and troubleshooting disk-related issues. It gathers its information from the <i>sysfs</i> filesystem, specifically /sys/dev/block and /sys/block, providing a dynamic and accurate representation of the system's block device topology. Key columns typically displayed include <b>NAME</b>, <b>MAJ:MIN</b> (major and minor device numbers), <b>RM</b> (removable device), <b>SIZE</b>, <b>RO</b> (read-only), <b>TYPE</b> (disk, partition, lvm, etc.), and <b>MOUNTPOINT</b>. It offers numerous options to customize the output, allowing users to filter information, change the output format (e.g., list, raw, JSON), or display additional details like filesystem information or permissions.


title: CAVEATS
content:
lsblk primarily focuses on <i>local</i> block devices. While it can show mounted network filesystems if they are backed by a block device visible to the kernel (e.g., iSCSI targets once connected and registered), it does not directly list network block devices or remote storage that isn't mapped to a local device node. For detailed information on very specific device types or advanced troubleshooting, other tools like <b>fdisk</b>, <b>parted</b>, or <b>udevadm</b> might be necessary. Some details (like certain permissions) might require root privileges.


title: COMMON USE CASES
content:
<b>lsblk</b> is frequently used to:<br><ul><li>Identify newly attached USB drives or external hard drives.</li><li>Examine the partition layout of a disk before formatting or resizing.</li><li>Find the <b>UUID</b> of a filesystem for entries in /etc/fstab.</li><li>Troubleshoot disk mounting issues by checking device names and mount points.</li></ul>


title: DEFAULT OUTPUT COLUMNS
content:
By default, <b>lsblk</b> typically displays the following columns:<br><ul><li><b>NAME</b>: The device name (e.g., <i>sda</i>, <i>sr0</i>, <i>dm-0</i>).</li><li><b>MAJ:MIN</b>: Major and minor device numbers.</li><li><b>RM</b>: Removable device (1 for removable, 0 otherwise).</li><li><b>SIZE</b>: The size of the device or partition.</li><li><b>RO</b>: Read-only device (1 for read-only, 0 otherwise).</li><li><b>TYPE</b>: The type of block device (e.g., <i>disk</i>, <i>part</i>, <i>rom</i>, <i>lvm</i>).</li><li><b>MOUNTPOINT</b>: The directory where the device is mounted.</li></ul>


title: HISTORY
content:
The <b>lsblk</b> command is part of the <b>util-linux</b> project, a collection of essential Linux utilities. It was developed to provide a more structured, readable, and consistent way of listing block devices compared to older methods that often involved parsing raw kernel output from /proc/partitions or relying on less standardized tools. Its design leveraged the <i>sysfs</i> filesystem, which became the standard for kernel device information, allowing <b>lsblk</b> to offer a rich and accurate view of the block device topology. It has become an indispensable tool for system administrators and users alike due to its clarity and flexibility.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all CPUs, including offline ones. By default, only online CPUs are shown.<br><br><b><b>-b</b>, <b>--online</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show online CPUs. This is the default behavior and is useful for explicitly ensuring offline CPUs are excluded.<br><br><b><b>-c</b>, <b>--caches</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display CPU cache information, including L1d, L1i, L2, and L3 cache sizes and types.<br><br><b><b>-e</b>, <b>--extended</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show extended, columnar output. This provides a more detailed, tabular view of CPU, Core, Socket, and NUMA node relationships.<br><br><b><b>-J</b>, <b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the CPU information in JSON format, suitable for machine parsing and integration into scripts or applications.<br><br><b><b>-p</b>, <b>--parse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize the output for easy parsing by scripts, presenting information in a colon-separated key=value pair format.<br><br><b><b>-S</b>, <b>--sysroot</b> <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gather CPU information from a specified alternative system root directory instead of the live system.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for the lscpu command and exit.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message explaining the command's usage and available options, then exit.<br><br>


title: DESCRIPTION
content:
lscpu is a command-line utility that gathers and displays comprehensive information about the CPU(s) on a Linux system. It provides a human-readable output summarizing the system's CPU architecture, including the number of CPUs, cores, sockets, threads, NUMA nodes, CPU family, model, vendor ID, cache sizes, and various CPU flags (capabilities).<br><br>The data is primarily sourced from <i>/proc/cpuinfo</i> and the <i>sysfs</i> filesystem (specifically <i>/sys/devices/system/cpu/</i>). This command is invaluable for system administrators, developers, and users who need quick access to detailed hardware specifications for troubleshooting, performance tuning, or understanding system capabilities. Unlike parsing <i>/proc/cpuinfo</i> directly, lscpu presents the information in a structured and easy-to-understand format, making it a preferred tool for CPU introspection.


title: CAVEATS
content:
The information provided by lscpu is derived from the kernel's view of the CPU topology and features. While generally accurate, inconsistencies can arise if the kernel or underlying hardware abstraction layer has issues. It relies heavily on the format of <i>/proc/cpuinfo</i> and sysfs, which may have minor variations across different kernel versions or architectures.


title: DATA SOURCE
content:
lscpu primarily extracts its information from <i>/proc/cpuinfo</i>, which is a virtual file system entry containing details about the CPU, and the <i>sysfs</i> filesystem, specifically the <i>/sys/devices/system/cpu/</i> directory. These kernel-provided interfaces offer real-time details about the CPU's topology and features, allowing lscpu to present an up-to-date view of the hardware.


title: OUTPUT FLEXIBILITY
content:
Beyond its default human-readable format, lscpu offers flexible output options like JSON (<b>-J</b>) and a parse-friendly key-value pair format (<b>-p</b>). This makes it highly suitable for scripting, automated data collection, and integration into monitoring or inventory management systems, allowing programmatic access to detailed CPU specifications.


title: HISTORY
content:
lscpu is part of the <i>util-linux</i> project, a collection of essential Linux system utilities. It was developed to provide a more structured, consistent, and user-friendly way to display CPU information compared to directly parsing the varying formats of <i>/proc/cpuinfo</i> across different architectures and kernel versions. Its development aimed at standardizing CPU reporting for system introspection and management.


title: SYNOPSIS
content:
<b>lsd</b> [<i>options</i>] [<i>files...</i>]<br><br>This command provides a powerful and customizable way to list directory contents, generally following the <b>ls</b> syntax but extending it with many specific options and visual enhancements.


title: PARAMETERS
content:
<b>-l, --long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a long listing format, showing permissions, owner, size, date, etc.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ignore entries starting with '<b>.</b>'.<br><br><b>-A, --almost-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not list implied '<b>.</b>' and '<b>..</b>'.<br><br><b>-h, --human-readable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;With <b>-l</b>, print sizes in human readable format (e.g., '<b>1K</b>', '<b>234M</b>', '<b>2G</b>').<br><br><b>-t, --sort=time</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort by time modified, newest first.<br><br><b>-r, --reverse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverse order while sorting.<br><br><b>-F, --classify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append indicator (one of '<b>*/=>@|</b>') to entries.<br><br><b>-R, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List subdirectories recursively.<br><br><b>--tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurse into directories and list them as a tree structure.<br><br><b>--group-dirs {none, first, last}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control how directories are grouped in the listing output.<br><br><b>--color {always, auto, never}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When to use color in the output.<br><br><b>--icons {always, auto, never}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When to use file type icons in the output (requires Nerd Fonts).<br><br><b>--permissions {rwx, octal}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display file permissions in '<b>rwx</b>' or '<b>octal</b>' format.<br><br><b>--hyperlink</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display paths as hyperlinks (requires terminal support).<br><br><b>--header</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the header in the long listing format.<br><br>


title: DESCRIPTION
content:
<b>lsd</b> (<i>L</i>i<i>S</i>t <i>D</i>irectory) is a rewritten version of the standard <b>ls</b> command, but with many added features, colors, and icons. Built in Rust, it aims to provide a more visually appealing and informative output for directory listings.<br><br>It supports various view modes, including tree view, detailed view, and compact view. It also integrates Git status information, file permissions, and extended attributes in a user-friendly manner. <b>lsd</b> enhances readability by using distinct colors for different file types, permissions, and ownership, making it easier to parse information at a glance. It’s an excellent choice for users looking to modernize their terminal experience.


title: CAVEATS
content:
<b>lsd</b> is an external tool and needs to be installed separately, unlike <b>ls</b> which is part of GNU Coreutils on most Linux distributions. Optimal display of icons and colors requires a terminal emulator that supports <i>Nerd Fonts</i> or similar icon fonts.<br><br>While highly customizable, configuring <b>lsd</b> requires understanding its specific options, which differ from <b>ls</b>. For extremely large directories or recursive operations, its rich feature set might introduce a slight performance overhead compared to a plain <b>ls</b>.


title: CONFIGURATION FILES
content:
<b>lsd</b> can be configured using a YAML file, typically located at <b>~/.config/lsd/config.yaml</b>. This allows for persistent customization of default behaviors, such as default sorting, column display, icon usage, and color schemes, providing a highly personalized listing experience.


title: NERD FONTS REQUIREMENT
content:
To fully utilize <b>lsd</b>'s icon display capabilities, users must install a <i>Nerd Font</i> in their terminal emulator. Without a compatible font, icons may appear as broken characters or simply not display, although the command's other features (colors, formatting) will still function.


title: HISTORY
content:
<b>lsd</b> was created by <i>Peltoche</i> and first released around 2018. It was developed to address the limitations of the traditional <b>ls</b> command by leveraging modern programming paradigms and Rust's performance capabilities.<br><br>Its development was driven by the desire for a more visually appealing and informative command-line experience, incorporating features like extensive coloring, file type icons (requiring Nerd Fonts), and Git integration, which are not present in <b>ls</b>. It quickly gained popularity as a robust and eye-pleasing alternative for developers and power users.


title: PARAMETERS
content:
<b>-i [<i>address</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all network files. Can specify an address (e.g., <i>:80</i> for port 80, <i>TCP</i> for TCP connections, <i>UDP</i> for UDP, <i>@host</i> for connections to a specific host, <i>@host:port</i>).<br><br><b>-u <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects files opened by the specified <i>user</i> (username or UID). Can be a comma-separated list or preceded by '^' to exclude.<br><br><b>-p <i>PID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects files opened by the specified process ID (<i>PID</i>). Can be a comma-separated list or preceded by '^' to exclude.<br><br><b>+D <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all files and directories opened within the specified <i>directory</i> and its subdirectories recursively.<br><br><b>+L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the display of file link counts. Helpful for identifying unlinked but still open files (deleted files).<br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logically ANDs the selection options. By default, most options are ORed.<br><br><b>-c <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists files opened by commands starting with the specified <i>name</i>.<br><br><b>-d <i>FD</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists files opened with specific file descriptors (<i>FD</i>). Examples include <i>cwd</i> (current working directory), <i>txt</i> (program text), <i>mem</i> (memory-mapped file), or numeric descriptors like <i>0</i>, <i>1</i>, <i>2</i> (standard I/O), often followed by <i>r</i> (read), <i>w</i> (write), or <i>u</i> (read/write).<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the conversion of network numbers to hostnames for faster output, especially useful when DNS lookups are slow.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the conversion of port numbers to service names (e.g., 80 instead of http).<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Parent Process ID (PPID) in the output.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a terse output, listing only PIDs, suitable for scripting.<br><br>


title: DESCRIPTION
content:
The command <i>lsfd</i> is not a standard Linux command. It is highly probable that the intended command was <b>lsof</b>, which stands for "List Open Files." <br><br><b>lsof</b> is a powerful and versatile command-line utility used to obtain a comprehensive list of all open files and the processes that have opened them. This includes regular files, directories, shared libraries, network sockets, named pipes, and block or character devices. It's an essential tool for system administrators to diagnose various system issues, such as identifying processes holding a specific file, finding out which process is using a particular network port, troubleshooting "file in use" errors, or monitoring system resource usage.<br><br>It can filter results based on process ID (PID), user, command name, file type, device, network protocol, and more, making it invaluable for in-depth system analysis and troubleshooting.


title: CAVEATS
content:
Using <b>lsof</b> effectively often requires <b>root</b> privileges to list all open files on the system; otherwise, it will only show files opened by the invoking user. <br><br>The output can be extremely verbose on busy systems, making it necessary to pipe it through tools like <b>grep</b>, <b>awk</b>, or <b>less</b> for filtering and easier analysis. <br><br>It can be resource-intensive on systems with a very large number of open files.


title: UNDERSTANDING <B>LSOF</B> OUTPUT COLUMNS
content:
The default output of <b>lsof</b> presents several columns, each providing crucial information about the open file:<br><b>COMMAND</b>: The command name of the process that opened the file.<br><b>PID</b>: The Process ID of the process.<br><b>USER</b>: The user who owns the process.<br><b>FD</b>: The File Descriptor, indicating how the file is being used (e.g., <i>cwd</i> for current working directory, <i>txt</i> for program text, <i>mem</i> for memory-mapped file, or a number followed by <i>r</i> for read, <i>w</i> for write, <i>u</i> for read/write).<br><b>TYPE</b>: The type of the file (e.g., <i>REG</i> for regular file, <i>DIR</i> for directory, <i>CHR</i> for character special, <i>BLK</i> for block special, <i>FIFO</i> for named pipe, <i>SOCK</i> for socket).<br><b>DEVICE</b>: The device numbers where the file resides.<br><b>SIZE/OFF</b>: The size of the file or the offset within the file.<br><b>NODE</b>: The inode number of the file.<br><b>NAME</b>: The full path to the file, or network information (e.g., <i>IP:port->IP:port</i> for sockets).


title: COMMON USE CASES FOR <B>LSOF</B>
content:
Here are some common ways to use <b>lsof</b>:<br><b>Finding processes using a specific file:</b> <br><i>lsof /path/to/your/file</i><br><b>Finding processes using a specific network port:</b> <br><i>lsof -i :80</i> (for TCP port 80) or <i>lsof -i UDP:161</i> (for UDP port 161)<br><b>Listing all open network connections for a user:</b> <br><i>lsof -i -u username</i><br><b>Identifying deleted files still held open (potential disk space hog):</b> <br><i>lsof | grep deleted</i><br><b>Listing open files for a specific command:</b> <br><i>lsof -c sshd</i><br><b>Checking current working directories of processes:</b> <br><i>lsof -a -d cwd</i>


title: HISTORY
content:
<b>lsof</b> was originally developed by Victor A. Abell as a powerful cross-platform utility. Its development began in the early 1990s and it has since become a standard and indispensable tool across various Unix-like operating systems, including Linux, Solaris, HP-UX, AIX, and macOS. Its long history and continuous development reflect its critical role in system administration and troubleshooting.


title: PARAMETERS
content:
<b><b>-short</b>, <b>-B</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce a shorter, more concise output, summarizing main components and their bus information.<br><br><b><b>-businfo</b>, <b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show bus information in a structured tree format, useful for identifying devices by their bus addresses (e.g., PCI or USB).<br><br><b><b>-class</b> <I>CLASS</I>, <b>-C</b> <I>CLASS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show devices belonging to the specified hardware <I>CLASS</I> (e.g., 'network', 'display', 'storage', 'cpu').<br><br><b><b>-disable</b> <I>CLASS</I>, <b>-D</b> <I>CLASS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable scanning for certain hardware <I>CLASS</I>es to speed up execution or avoid issues with specific devices.<br><br><b><b>-enable</b> <I>CLASS</I>, <b>-E</b> <I>CLASS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable scanning for a certain hardware <I>CLASS</I>. Useful if a class is disabled by default or to override a previous <b>-disable</b> option.<br><br><b><b>-numeric</b>, <b>-N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display numeric IDs (e.g., PCI vendor/device IDs) instead of textual descriptions, useful for database lookups.<br><br><b><b>-json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the hardware information in JSON format, suitable for programmatic parsing and web applications.<br><br><b><b>-xml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the hardware information in XML format, commonly used for data exchange and structured documentation.<br><br><b><b>-html</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the hardware information in HTML format, making it easy to view in a web browser for detailed reports.<br><br><b><b>-quiet</b>, <b>-Q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress status messages during execution, only showing the final output.<br><br><b><b>-sanitize</b>, <b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sanitize output by hiding sensitive information like serial numbers or UUIDs, useful for sharing system configurations publicly.<br><br><b><b>-version</b>, <b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of the <i>lshw</i> utility and exit.<br><br>


title: DESCRIPTION
content:
<i>lshw</i> (list hardware) is a small but powerful command-line utility used to extract and display comprehensive information about a system's hardware configuration. It can report on a wide range of hardware components, including exact memory configuration, firmware version, mainboard details, CPU version and speed, cache setup, bus speeds, network adapters, storage devices, and more. <br><br>The tool gathers its information from various sources like the <i>/proc</i> and <i>sysfs</i> filesystems, DMI (Desktop Management Interface) tables, PCI configuration space, and USB descriptors. Its ability to output in multiple formats such as plain text, XML, HTML, and JSON makes it highly versatile for system auditing, inventory management, troubleshooting, and scripting. To obtain the most complete and accurate hardware data, especially from DMI tables, <i>lshw</i> typically requires root privileges.


title: CAVEATS
content:
For <i>lshw</i> to gather complete and accurate hardware information, especially details from DMI tables (like serial numbers, manufacturer data, and motherboard specifics), it often requires root privileges. Running it as a regular user might result in incomplete output. Additionally, the accuracy and depth of the reported information can depend on the Linux kernel's support for specific hardware components and the availability of appropriate device drivers.


title: OUTPUT FORMATS
content:
One of <i>lshw</i>'s most significant strengths is its versatility in output formats. Beyond the default human-readable plain text, it can generate XML, HTML, and JSON outputs. This makes it incredibly flexible for integration into scripts, automation tools, web-based inventory systems, or simply for generating presentable reports that can be easily shared or archived.


title: HARDWARE CLASSES
content:
<i>lshw</i> categorizes hardware into logical 'classes' (e.g., 'system', 'memory', 'cpu', 'network', 'disk', 'display'). This classification system allows users to filter the output and focus on specific types of hardware using the <b>-class</b> or <b>-C</b> option, providing a more manageable view of complex systems.


title: HISTORY
content:
<i>lshw</i> was originally developed by Alexandre Oliva, with its first release dating back to 2002. From its inception, the goal was to provide a unified and structured way to report on diverse hardware components. Its comprehensive output capabilities and support for multiple output formats quickly led to its widespread adoption across various Linux distributions, making it a standard and indispensable tool for system administrators and hardware diagnostics.


title: SYNOPSIS
content:
<i>lsinitramfs</i> [<b>-q</b>|<b>--quiet</b>] [<b>-v</b>|<b>--verbose</b>] [<b>-l</b>|<b>--list</b>] [<b>-k</b> <i>KERNEL_VERSION</i>] [<i>INITRAMFS_IMAGE</i>]


title: PARAMETERS
content:
<b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress warning messages during the operation.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display verbose messages, showing more details about the process.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List contents in a long format, similar to <i>ls -l</i>, showing permissions, ownership, and size.<br><br><b><b>-k</b> <i>KERNEL_VERSION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the kernel version for which to find and list the corresponding <i>initramfs</i> image (e.g., <i>-k 5.15.0-76-generic</i>). If omitted, the latest installed kernel's image is used.<br><br><b><i>INITRAMFS_IMAGE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The full path to the <i>initramfs</i> image file to be inspected. If this argument is omitted, <i>lsinitramfs</i> attempts to list the contents of the default or most recently created <i>initramfs</i> for the currently running or latest installed kernel.<br><br>


title: DESCRIPTION
content:
The <i>lsinitramfs</i> command is a utility used to inspect the contents of an <i>initramfs</i> (initial RAM filesystem) image.<br><br>The <i>initramfs</i> is a gzipped <i>cpio</i> archive that is loaded into RAM during the early boot process, even before the actual root filesystem is mounted. It contains essential kernel modules (like those for storage controllers, filesystems), configuration files, and scripts necessary to bring up the system to a point where the real root filesystem can be accessed and mounted.<br><br><i>lsinitramfs</i> helps system administrators and developers understand what's included in this early boot environment. It's particularly useful for debugging boot failures, verifying if specific drivers or scripts are present in the image, or simply examining the structure of the <i>initramfs</i>.<br><br>Without any arguments, it typically lists the contents of the most recently generated <i>initramfs</i> image for the current kernel. You can also specify a particular <i>initramfs</i> file or a kernel version to inspect.


title: CAVEATS
content:
The <i>lsinitramfs</i> command is typically part of the <i>initramfs-tools</i> package on Debian/Ubuntu-based systems, or similar tools on other distributions (e.g., <i>dracut</i> on Fedora/RHEL). Its availability and exact behavior might vary slightly depending on the distribution and version of these tools.<br><br>The <i>initramfs</i> image itself is often a compressed <i>cpio</i> archive. While <i>lsinitramfs</i> handles the decompression and listing, manual extraction usually involves commands like <i>unmkinitramfs</i> (if available) or a combination of <i>zcat</i>/<i>xzcat</i> and <i>cpio</i>.


title: COMMON USE CASES
content:
<ul><li><b>Debugging Boot Issues:</b> Crucial for diagnosing problems where the system fails to find or mount the root filesystem, often due to missing storage controller drivers or filesystem modules in the <i>initramfs</i>.</li><li><b>Verifying Module Inclusion:</b> Confirming that specific kernel modules (e.g., for NVMe drives, RAID controllers, or specific network interfaces) are present in the early boot environment.</li><li><b>Inspecting Customizations:</b> If custom scripts or binaries are added to the <i>initramfs</i>, <i>lsinitramfs</i> can verify their presence and location within the image.</li><li><b>Security Audits:</b> Examining the contents for any unexpected or unwanted files that might have been inadvertently included.</li></ul>


title: INTERNAL STRUCTURE OF INITRAMFS
content:
An <i>initramfs</i> image is fundamentally a gzipped (or xz-compressed, or lzma-compressed) <i>cpio</i> archive. <i>lsinitramfs</i> intelligently decompresses this archive on the fly and then lists its contents as if it were a regular directory. This structure allows the Linux kernel to directly map the image into memory and execute the <i>/init</i> program contained within it, without needing to treat it as a block device like the older <i>initrd</i>.


title: HISTORY
content:
The <i>initramfs</i> concept emerged as a successor to the <i>initrd</i> (initial RAM disk) in Linux, providing a more flexible and robust mechanism for the early boot process. The <i>initramfs-tools</i> project, which includes <i>lsinitramfs</i>, was developed to manage these new images. <i>lsinitramfs</i> became an essential debugging and inspection tool, particularly as system configurations grew more complex and reliance on early-loaded modules increased for hardware compatibility and specific boot environments (like encrypted root filesystems). Its development paralleled the widespread adoption of <i>initramfs</i> in modern Linux distributions, replacing the older <i>initrd</i> approach.


title: PARAMETERS
content:
<b><i>INITRAMFS_IMAGE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the initramfs or initrd image file to inspect. If omitted, <b>lsinitrd</b> typically tries to locate the image for the current or latest kernel.<br><br><b><i>KERNEL_VERSION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument specifying the kernel version string (e.g., '4.18.0-305.el8.x86_64') for which to find the initramfs image, if <i>INITRAMFS_IMAGE</i> is not explicitly provided.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--file &lt;initramfs_file&gt;</b>, <b>-f &lt;initramfs_file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specify the initramfs or initrd image file to inspect.<br><br><b><b>--kver &lt;kernel_version&gt;</b>, <b>-k &lt;kernel_version&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the kernel version string to locate the corresponding initramfs image.<br><br><b><b>--verbose</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide more detailed output, which may include CPIO header information or file sizes.<br><br><b><b>--debug</b>, <b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output for the <b>lsinitrd</b> script itself, useful for troubleshooting issues with the command's execution.<br><br><b><b>--show-modules</b>, <b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only the kernel modules (drivers) found within the initramfs image.<br><br><b><b>--list-files</b>, <b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly list the files and directories inside the initramfs. This is often the default behavior if no other action is specified.<br><br>


title: DESCRIPTION
content:
The <b>lsinitrd</b> command is a crucial diagnostic utility used to inspect the contents of an <i>initramfs</i> (initial RAM filesystem) or <i>initrd</i> (initial RAM disk) image.<br>These images are integral to the Linux boot process, as they provide a minimal root filesystem in RAM, containing essential kernel modules (like filesystem drivers) and scripts needed to mount the actual root filesystem from the disk.<br><br><b>lsinitrd</b> allows system administrators and developers to examine what's inside these compressed archives without actually booting the system with them. This is invaluable for troubleshooting boot failures, verifying included drivers, or understanding the exact sequence of operations before the main root filesystem is switched over. It typically works by decompressing the image on the fly and then using <b>cpio</b> to list its contents. The command can operate on a specified image file or, if no file is given, often defaults to the <i>initramfs</i> image corresponding to the currently running kernel or the latest installed kernel. Its output usually includes filenames, their permissions, and sometimes their sizes, providing a detailed view of the early boot environment.


title: CAVEATS
content:
The <b>lsinitrd</b> command relies on standard decompression utilities (like <b>gzip</b>, <b>xz</b>, <b>zstd</b>) and <b>cpio</b> being available on the system to decompress and list the contents of the initramfs.<br>It is primarily a read-only inspection tool; it cannot modify or extract files from the initramfs image directly (for extraction, tools like <b>unmkinitramfs</b> or <b>cpio</b> itself are typically used).<br>The exact set of options and their behavior might slightly vary depending on the Linux distribution and the initramfs generation utility (<b>dracut</b>, <b>mkinitramfs</b>, etc.) it's associated with.


title: HOW IT WORKS
content:
Internally, <b>lsinitrd</b> first identifies the compression format of the initramfs image (e.g., gzip, xz, zstd). It then pipes the decompressed stream to the <b>cpio</b> command, typically with the <b>-t</b> (list) and <b>-v</b> (verbose) options, to display the archive's contents.


title: IMPORTANCE IN BOOT PROCESS
content:
The <i>initramfs</i> image is crucial for the Linux kernel to successfully boot and mount the real root filesystem. It contains essential device drivers (e.g., for NVMe, SCSI, software RAID, LVM), filesystem tools, and a minimal <i>init</i> program that sets up the environment before handing control over to the actual <i>init</i> process on the disk-based root filesystem. Troubleshooting issues in this early boot stage often requires inspecting the <i>initramfs</i> contents using <b>lsinitrd</b>.


title: HISTORY
content:
The <b>lsinitrd</b> command emerged as a necessary companion to the utilities responsible for creating initial boot environments in Linux. Initially, systems used an <i>initrd</i> (initial RAM disk), a block device-based approach. Later, the more flexible <i>initramfs</i> (initial RAM filesystem), which uses a <i>tmpfs</i> (temporary file system) and a CPIO archive, became the standard. <b>lsinitrd</b> evolved alongside these changes, particularly gaining prominence with the adoption of <b>dracut</b> as a primary <i>initramfs</i> generator on many modern distributions. Its development has focused on providing a convenient, human-readable way to peek into these critical boot components, aiding in debugging and system understanding.


title: PARAMETERS
content:
<b>-b, --bytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the SIZE column in bytes rather than a human-readable format.<br><br><b>-i, --no-human-readable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A synonym for <i>--bytes</i>.<br><br><b>-J, --json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use JSON output format.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the list output format, where each lock is presented on a separate line.<br><br><b>-n, --noheadings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print a header line in the output.<br><br><b>-o, --output <list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which output columns to print. Use <i>--help</i> to see a list of all supported columns.<br><br><b>-p, --pid <pid></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display locks held by specific PIDs (comma-separated list of PIDs).<br><br><b>-r, --raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the raw output format, which might be easier for script parsing.<br><br><b>-S, --no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use a pager for the output.<br><br><b>-s, --sort <column></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort output by the specified column name.<br><br><b>-t, --truncate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Truncate output when columns are too wide, rather than wrapping.<br><br><b>-u, --no-empty-owner</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print locks with an empty owner (e.g., locks from kernel threads).<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<i>lslocks</i> is a command-line utility used to display information about all currently held file locks on the local system. It provides details such as the command holding the lock, the process ID (PID), the lock type, mode (read/write), the number of lock owners, the device and path of the locked file, and the owner of the lock.<br><br>This command is particularly useful for diagnosing issues related to file access, such as "Text file busy" errors or unresponsive applications due to resource contention. It primarily focuses on advisory and mandatory locks on local filesystems and usually requires root privileges to view locks not owned by the current user.


title: CAVEATS
content:
Requires <b>root</b> privileges when listing locks not owned by the current user.<br>Does not show locks held by network file systems (e.g., NFS).


title: UNDERSTANDING LOCK TYPES
content:
The <b>TYPE</b> column in <i>lslocks</i> output indicates the locking mechanism used. Common types include <b>FLOCK</b> (advisory locks managed by the <i>flock(2)</i> system call) and <b>POSIX</b> (locks managed by <i>fcntl(2)</i>, which can be advisory or mandatory).


title: INTERPRETING LOCK MODES
content:
The <b>MODE</b> column describes the lock's access type. <b>READ</b> indicates a shared lock, allowing multiple processes to hold a read lock simultaneously. <b>WRITE</b> indicates an exclusive lock, preventing any other process from acquiring any type of lock (read or write) on the same region.


title: THE BLOCKED/BLOCKER COLUMN
content:
The <b>BLOCKER</b> column displays the PID of the process that is blocking the current lock request, if applicable. Conversely, the <b>BLOCKED</b> column (if enabled via <i>-o</i>) would show the PID of the process being blocked by the current lock.


title: HISTORY
content:
Part of the <b>util-linux</b> project, <i>lslocks</i> was introduced to provide a dedicated and structured tool for listing file locks. Prior to its existence, this information was often harder to obtain, requiring more generic tools like <i>lsof</i> or <i>fuser</i> combined with manual interpretation. Its development aimed to offer a more direct and detailed insight into the file locking status on a Linux system.


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all user logins, including those without active sessions.<br><br><b>-b, --boot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show information about boot sessions, linking sessions to system boots.<br><br><b>-F, --failed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about failed login attempts.<br><br><b>-f, --fsid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show session filesystem ID, providing unique identifiers for filesystems involved in sessions.<br><br><b>-g, --group <group>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter output to show information for specific groups by name or GID. Multiple groups can be specified as a comma-separated list.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-i, --invert</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invert the meaning of specified columns when used with <B>--output</B>, for example, showing only non-matching data.<br><br><b>-J, --json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the results in JSON format, suitable for machine parsing.<br><br><b>-L, --last</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the last login time for each user.<br><br><b>-l, --logins</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the display of only login information, excluding session details unless explicitly requested by other options.<br><br><b>-n, --noheadings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the printing of column headers in the output.<br><br><b>-o, --output <list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a comma-separated <I>list</I> of columns to display. Use <B>--help</B> to see available column names.<br><br><b>-P, --plain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a plain output format, disabling default processing and column headers, useful for scripting.<br><br><b>-p, --port</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show information related to ports (TTYs) associated with sessions.<br><br><b>-r, --raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce raw output without any column alignment or post-processing.<br><br><b>-s, --session</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include detailed session information in the output, such as TTY, origin (FROM), and idle time.<br><br><b>-u, --user <user>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter output to show information for specific users by name or UID. Multiple users can be specified as a comma-separated list.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>--active</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only active user logins. This is the default behavior.<br><br><b>--inactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only inactive user logins.<br><br><b>--hide-empty-columns</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the display of columns that contain no data for any row.<br><br>


title: DESCRIPTION
content:
The <b>lslogins</b> command displays information about user logins and their associated sessions managed by <b>systemd</b>. It retrieves data directly from the <b>systemd</b> login manager, providing details such as user names, UIDs, GIDs, current session counts, login creation times, and last login occurrences. Unlike traditional tools that might scan /etc/passwd or /var/log/wtmp, <b>lslogins</b> focuses on users known to <b>systemd</b>, which primarily includes users with active sessions or those who have recently had sessions. By default, it lists logins with active sessions or users with a UID of 1000 or higher. Users can filter results by specific users or groups, or expand the output to include detailed session or boot information, last login times, and even failed login attempts. It supports customizable output columns and can produce output in various formats including plain text and JSON, making it versatile for both interactive use and scripting.


title: CAVEATS
content:
<b>lslogins</b> relies on the <b>systemd</b> login manager for its data. It will not list all system users, but only those known to <b>systemd</b>'s current or past sessions. Therefore, it may not provide a complete list of all users on a system, especially those without any interactive sessions. The information provided is dynamic and reflects the state managed by <b>systemd</b>, which means it might differ from information gathered by traditional tools that parse static log files.


title: DEFAULT OUTPUT COLUMNS
content:
By default, <b>lslogins</b> outputs columns such as <b>USER</b>, <b>UID</b>, <b>GID</b>, <b>SESS</b> (session count), <b>STATE</b>, <b>LOGIN</b> (creation time), and <b>LTIME</b> (last login time). The exact columns can vary based on the version and system configuration, but these are generally included to provide a concise overview of login information.


title: EXIT STATUS
content:
The command returns an exit status of <b>0</b> upon successful completion, indicating that the command ran without errors. An exit status of <b>1</b> signifies that <b>lslogins</b> encountered an error during its execution. This standard behavior is useful for scripting and error handling in automated tasks.


title: HISTORY
content:
The <b>lslogins</b> command is a relatively recent addition to the suite of Linux utilities, introduced as part of the <b>util-linux</b> project in version <b>2.36</b>. Its development reflects the growing reliance on <b>systemd</b> for managing login sessions and user activity on modern Linux systems. It provides a more integrated and structured way to query login information directly from the <b>systemd</b> login manager compared to older tools that often parse log files or specific pseudo-terminals. Its inclusion in <b>util-linux</b> signifies its role as a standard utility for login information retrieval in <b>systemd</b>-centric environments.


title: DESCRIPTION
content:
The <b>lsmod</b> command is a utility used in Linux to display the status of currently loaded kernel modules. <br><br>It provides a clear, human-readable list of all modules that are presently active in the kernel, along with their size, usage count, and a list of other modules that depend on them. <br><br>This information is crucial for system administrators and developers to understand the current configuration of the kernel, diagnose issues, or verify that specific hardware drivers or kernel features are loaded and operational. <br><br>The data presented by <b>lsmod</b> is directly sourced from the <i>/proc/modules</i> file, which is a virtual file system entry maintained by the kernel itself, providing real-time information about its loaded components.


title: CAVEATS
content:
The <b>lsmod</b> command only displays modules that are currently loaded into the kernel's memory. It does not list all available modules on the system or modules that might be compiled into the kernel directly. <br><br>Its output is primarily designed for human readability, though it can be parsed by scripts. <br><br>The command relies on the existence and accessibility of the <i>/proc/modules</i> file, which provides the underlying data. <br><br>While generally robust, inconsistencies or corruption in this virtual file could impact <b>lsmod</b>'s operation.


title: OUTPUT FORMAT
content:
The output of <b>lsmod</b> typically consists of several columns:<br><b>Module</b>: The name of the kernel module.<br><b>Size</b>: The memory size, in bytes, that the module occupies in the kernel.<br><b>Used by</b>: The number of other modules that are currently using this module. A value of 0 means no other modules are directly dependent on it.<br><b>Used by (list)</b>: A comma-separated list of other modules that depend on this specific module. If the 'Used by' count is 0, this column will be empty.


title: DATA SOURCE
content:
The information displayed by <b>lsmod</b> is derived directly from the <i>/proc/modules</i> virtual file. This file is a kernel-maintained interface that provides a textual representation of all currently loaded kernel modules and their attributes. <b>lsmod</b> simply parses and formats the contents of this file for user-friendly display.


title: HISTORY
content:
The concept of dynamically loadable kernel modules has been a fundamental part of the Linux kernel's design since its early versions, allowing for a more flexible and modular kernel. <br><br>The <b>lsmod</b> command is part of the <i>module-init-tools</i> (or historically <i>modutils</i>) package, which provides a suite of utilities for managing Linux kernel modules. <br><br>Over time, as the kernel evolved and module management became more sophisticated (e.g., handling dependencies, aliases, and blacklisting), <b>lsmod</b> remained a simple, essential tool for quickly inspecting the current state of loaded modules. Its core functionality of reading <i>/proc/modules</i> has remained consistent, reflecting the stable interface provided by the kernel.


title: SYNOPSIS
content:
<i>lsof</i> [<i>options</i>] [<i>names</i>]<br><br><i>Common Invocation Examples:</i><br>- <i>lsof</i> - List all open files.<br>- <i>lsof -i</i> - List all network connections.<br>- <i>lsof -p PID</i> - List files opened by a specific process ID.<br>- <i>lsof /path/to/file</i> - List processes opening a specific file.


title: PARAMETERS
content:
<b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes list selections to be <i>AND</i>ed. By default, selections are <i>OR</i>ed.<br><br><b><i>-c COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the listing of files for processes executing the <i>COMMAND</i>.<br><br><b><i>-d FD</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the listing of files for the specified file descriptor(s) (e.g., <i>0,1,2,txt,cwd,mem,rtd</i>).<br><br><b><i>-i [addresses]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the listing of files for Internet protocol (IP) addresses. Can specify IP address, hostname, or port (e.g., <i>:80, @192.168.1.1, TCP:22</i>).<br><br><b><i>-n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the conversion of network numbers to host names for network files. Speeds up output.<br><br><b><i>-P</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the conversion of network port numbers to port names for network files. Speeds up output.<br><br><b><i>-p PID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the listing of files for the specified process ID(s).<br><br><b><i>-r [N]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Repeats <i>lsof</i> command every <i>N</i> seconds. Default is 15 seconds.<br><br><b><i>-t</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces terse output, suitable for piping to other commands. Only PIDs are displayed.<br><br><b><i>-u USER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the listing of files for the specified user(s) (name or UID).<br><br><b><i>+D DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for all open instances of files or directories within the specified <i>DIRECTORY</i> and its subdirectories.<br><br><b><i>+L</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the file link count (i.e., the number of hard links to a file).<br><br><b><i>-F fmt</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format fields. Useful for scripting and custom parsing.<br><br>


title: DESCRIPTION
content:
<i>lsof</i> (short for <i>list open files</i>) is a powerful command-line utility used to display information about files opened by processes on a Unix-like system. It can identify which files are currently being used by which processes, including regular files, directories, block special files, character special files, shared libraries, named pipes, Internet sockets, and UNIX domain sockets.<br><br>This command is invaluable for system administrators, developers, and security analysts for various tasks: troubleshooting "file in use" errors, identifying processes accessing specific resources (e.g., a mounted disk, a network port), debugging application behavior, or investigating potential security breaches. <i>lsof</i> provides a detailed snapshot of file and network activity, making it a critical tool for system introspection and resource management.


title: CAVEATS
content:
<i>lsof</i> often requires <i>root</i> privileges to access comprehensive information about all processes and their open files, especially those belonging to other users or kernel-level resources. Running it as a non-root user may result in incomplete or restricted output.<br><br>The output can be very verbose, requiring careful filtering (often with <i>grep</i>) to find specific information. On systems with a large number of open files, <i>lsof</i> can take a significant amount of time to execute and consume considerable system resources during its run.


title: <I>UNDERSTANDING LSOF OUTPUT COLUMNS</I>
content:
<i>lsof</i> output is typically structured into several columns, each providing specific details:<br><b>COMMAND</b>: The name of the command associated with the process.<br><b>PID</b>: The process ID.<br><b>TID</b>: The thread ID (if <i>lsof</i> supports and <i>-t</i> is used).<br><b>USER</b>: The user ID or login name of the process owner.<br><b>FD</b>: The file descriptor number of the file (e.g., <i>cwd</i> for current working directory, <i>txt</i> for program text, <i>mem</i> for memory-mapped file, <i>0, 1, 2</i> for stdin, stdout, stderr, or a numeric descriptor).<br><b>TYPE</b>: The type of the node associated with the file (e.g., <i>REG</i> for regular file, <i>DIR</i> for directory, <i>CHR</i> for character special file, <i>FIFO</i> for FIFO pipe, <i>SOCK</i> for socket, <i>IPv4</i> for IPv4 socket).<br><b>DEVICE</b>: The device numbers where the file resides.<br><b>SIZE/OFF</b>: The size of the file or the offset used by the process.<br><b>NODE</b>: The inode number of the local file or the protocol/address of a network file.<br><b>NAME</b>: The name of the mount point and file system, or the file name itself, or a network connection.


title: <I>COMMON USAGE SCENARIOS</I>
content:
<i>lsof</i>'s versatility allows for many practical applications:<br>- <b>Finding processes using a specific file or directory:</b> <i>lsof /var/log/syslog</i> or <i>lsof +D /mnt/data</i><br>- <b>Identifying processes listening on a specific port:</b> <i>lsof -i :8080</i> or <i>lsof -i TCP:443</i><br>- <b>Listing all network connections by a user:</b> <i>lsof -u root -i</i><br>- <b>Killing processes holding a file open:</b> <i>kill -9 $(lsof -t /path/to/file)</i><br>- <b>Finding deleted but still open files:</b> <i>lsof | grep deleted</i> (Useful for troubleshooting disk space issues where files are deleted but their space isn't freed because a process still holds them open).


title: HISTORY
content:
<i>lsof</i> was originally developed by <i>Victor A. Abell</i>. Its development began in the late 1980s and has since become a standard and indispensable utility across various Unix-like operating systems, including Linux, macOS, FreeBSD, and Solaris. It filled a critical gap in system introspection by providing a unified way to list all open file descriptors and the corresponding files, significantly aiding in debugging, resource management, and security analysis.


title: SYNOPSIS
content:
lspath [ <b>-H</b> ] [ <b>-l</b> <i>DeviceName</i> ] [ <b>-P</b> <i>ParentName</i> ] [ <b>-s</b> <i>Status</i> ] [ <b>-a</b> <i>Attribute</i>=<i>Value</i> ] [ <b>-p</b> <i>PathID</i> ]


title: PARAMETERS
content:
<b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a header row above the output columns, providing descriptive labels for each field such as <i>path_id</i>, <i>path_status</i>, <i>parent</i>, and <i>child</i>.<br><br><b><b>-l</b> <i>DeviceName</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>logical device name</i> (e.g., <i>hdisk0</i>, <i>cd0</i>) for which to list paths. This option filters the output to show paths only for the specified device.<br><br><b><b>-P</b> <i>ParentName</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>parent device name</i> (e.g., a host bus adapter like <i>fscsi0</i> or <i>vhost0</i>) for which to list paths. This filters paths based on the adapter they are connected through.<br><br><b><b>-s</b> <i>Status</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output to display only paths with a specific <i>status</i>. Common statuses include <i>enabled</i>, <i>disabled</i>, <i>active</i>, <i>passive</i>, and <i>failed</i>.<br><br><b><b>-a</b> <i>Attribute</i>=<i>Value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters paths based on a specific <i>attribute</i> and its corresponding <i>value</i> (e.g., <i>connection=0000000000000000</i>). This allows for highly granular filtering based on various path properties.<br><br><b><b>-p</b> <i>PathID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information for a specific <i>path ID</i>. Each path is assigned a unique identifier, and this option allows querying details for that specific path.<br><br>


title: DESCRIPTION
content:
The <b>lspath</b> command displays detailed information about the configured paths to devices on IBM Power Systems (AIX and Linux on Power). This is particularly important in environments where devices, such as disk LUNs, are accessible via multiple physical paths, a common setup in Storage Area Network (SAN) configurations. It provides insights into the status of each path (e.g., <i>enabled</i>, <i>disabled</i>, <i>failed</i>), the parent adapter through which the path is established, and other path-specific attributes. By listing these paths, <b>lspath</b> helps system administrators monitor the health, redundancy, and overall connectivity of storage devices, which is essential for ensuring high availability and optimal performance in enterprise IT infrastructures.


title: CAVEATS
content:
The <b>lspath</b> command is primarily associated with IBM Power Systems, specifically AIX and Linux on Power distributions. It is <i>not</i> a standard command found on generic x86 Linux distributions.<br>It typically requires root privileges or appropriate sudo permissions to execute effectively and retrieve comprehensive device path information.<br>The exact output format and available options might vary slightly depending on the specific Power Linux distribution and the installed version of the <i>powerpc-utils</i> or <i>devices.mpio</i> package.


title: COMMON USAGE SCENARIOS
content:
<b>lspath</b> is frequently used to diagnose connectivity issues to SAN-attached storage, verify multipathing configurations, and monitor the health of redundant paths. For instance, running <i>lspath -l hdisk0 -s failed</i> can quickly identify any failed paths leading to a specific disk, aiding in proactive problem resolution.<br>Another common use case is to inspect all paths associated with a particular Fibre Channel adapter using <i>lspath -P fscsi0</i>.


title: PATH STATES
content:
Understanding the various path states displayed by <b>lspath</b> is crucial for proper system administration. Common states include: <br><i>enabled</i>: The path is configured and ready for use.<br><i>disabled</i>: The path is configured but has been intentionally taken offline or is not currently in use.<br><i>active</i>: The path is currently being used to transmit I/O operations.<br><i>passive</i>: The path is a standby path, ready to take over if an active path fails.<br><i>failed</i>: The path is unreachable, broken, or otherwise unusable for I/O operations.


title: HISTORY
content:
The <b>lspath</b> command originated within IBM's AIX operating system, where it was developed to manage and display information about multiple paths to devices, a crucial capability with the widespread adoption of Storage Area Networks (SANs). As Linux gained prominence on IBM Power Systems, utilities with similar functionalities, including <b>lspath</b>, were developed and integrated into packages like <i>powerpc-utils</i> and <i>devices.mpio</i>. This porting effort ensured that administrators could leverage comparable device path management capabilities in the Linux on Power environment, maintaining consistent administration paradigms across IBM's enterprise server platforms.


title: PARAMETERS
content:
<b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be <I>verbose</I> - show detailed information about all devices. Multiple <b>-v</b> options increase the verbosity level (e.g., <b>-vv</b>, <b>-vvv</b>).<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show kernel drivers handling each device and kernel modules capable of handling it.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show PCI vendor and device codes as <I>numeric IDs</I> instead of looking them up in the PCI ID list.<br><br><b><b>-nn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show both <I>numeric IDs</I> and their human-readable names.<br><br><b><b>-s</b> [<I>domain</I>:]<I>bus</I>:<I>device</I>.<I>function</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only devices in the specified <I>slot</I>. For example, <b>-s 00:01.0</b>.<br><br><b><b>-d</b> [<I>vendor</I>]:[<I>device</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only devices with the specified <I>vendor</I> and <I>device</I> IDs. For example, <b>-d 10de:</b> for all NVIDIA devices or <b>-d :0001</b> for devices with device ID 0001.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a <I>tree-like diagram</I> of PCI devices, illustrating their hierarchy.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a <I>hex dump</I> of the first 64 bytes of the device's PCI configuration space. Use <b>-xx</b> to dump the full configuration space.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <I>machine readable</I> output. Options like <b>-mm</b> and <b>-Q</b> provide even more structured output suitable for parsing by scripts.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always show PCI domain numbers. (PCI domains group multiple PCI buses, common in large systems with more than 256 buses).<br><br><b><b>-i</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified <I>file</I> as an alternative PCI ID list instead of the default <b>/usr/share/hwdata/pci.ids</b> or similar.<br><br>


title: DESCRIPTION
content:
<b>lspci</b> is a powerful utility for displaying comprehensive information about all PCI buses and devices present in the system. It enumerates hardware connected via the Peripheral Component Interconnect (PCI) bus, including modern PCI Express (PCIe) devices. The command reveals critical details such as vendor and device IDs, subsystem IDs, revision numbers, device classes (e.g., network controller, display controller, storage controller), and various capabilities (e.g., PCIe, power management, MSI-X). This information is invaluable for system administrators, developers, and users for tasks like hardware identification, troubleshooting, driver installation, and verifying system configurations. By default, <b>lspci</b> provides a concise summary, but it offers numerous options to control the verbosity, including showing kernel driver information, hexadecimal dumps of configuration registers, and machine-readable formats. It primarily queries the <i>/sys</i> filesystem on modern Linux systems to gather its data.


title: CAVEATS
content:
Accessing full device information, especially configuration registers, often requires root privileges. Without them, <b>lspci</b> might show incomplete details or fail to list certain devices. The accuracy of human-readable names depends on the <b>pci.ids</b> database, which should be kept up-to-date (e.g., using <b>update-pciids</b>). In virtualized environments, <b>lspci</b> might present virtualized devices rather than the underlying physical hardware.


title: PCI ID DATABASE
content:
<b>lspci</b> relies on a database, typically located at <i>/usr/share/hwdata/pci.ids</i> or <i>/usr/share/pci.ids</i>, to translate numeric vendor and device IDs into human-readable names. This file contains a comprehensive list of known PCI devices, vendors, and subsystems. It needs periodic updates to recognize new hardware.


title: DATA SOURCES
content:
On Linux, <b>lspci</b> primarily gathers information from the <i>/sys/bus/pci/devices</i> filesystem, which is populated by the kernel's PCI subsystem. For older kernels or specific configurations, it might fall back to reading from <i>/proc/bus/pci</i> or directly accessing I/O ports for configuration space, although the <i>/sys</i> interface is preferred and more robust.


title: PCIE SUPPORT
content:
<b>lspci</b> fully supports PCI Express (PCIe) devices, including their specific capabilities (e.g., Advanced Error Reporting - AER, Active State Power Management - ASPM, Resizable BAR) and the extended configuration space that PCIe devices utilize.


title: HISTORY
content:
The <b>lspci</b> command is a core component of the <i>pciutils</i> package, a suite of utilities designed for inspecting and manipulating PCI devices. Its development began to provide Linux users with a standardized way to query PCI hardware, which is fundamental for system configuration and troubleshooting. As PCI technology evolved from its initial standard to PCI-X and then to PCI Express, <b>lspci</b> has been consistently updated to support new capabilities, configuration register layouts, and bus structures, ensuring its relevance for modern PCI-based hardware. Its primary data source shifted from direct hardware access or the <i>/proc</i> filesystem to the more structured <i>/sys</i> filesystem on contemporary Linux kernels, enhancing stability and integration.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;As <b>lspgpot</b> is not a standard, publicly documented command, no specific parameters or options are available for description. Any parameters it might accept would be entirely dependent on its custom implementation.<br><br>


title: DESCRIPTION
content:
The command <b>lspgpot</b> is <i>not recognized</i> as a standard Linux command or utility available in common Linux distributions (e.g., Debian, Ubuntu, CentOS, Fedora) via their official package repositories or `man` pages.<br><br>It is highly probable that <b>lspgpot</b> is either:<br><i>1.</i> A custom script or internal tool specific to a particular environment or project.<br><i>2.</i> A typo for another common Linux command or a combination of standard commands.<br><i>3.</i> An obscure or deprecated utility not widely documented in public resources.<br><br>Without specific context or documentation from its source, its precise functionality, syntax, and parameters cannot be accurately determined or described.


title: CAVEATS
content:
This command is <i>not found</i> in standard Linux command sets. Attempting to execute it in a typical Linux environment will almost certainly result in a 'command not found' error. Its existence and behavior are solely dependent on its specific deployment within a custom or private system.


title: POSSIBLE ORIGIN/INTERPRETATION
content:
If this command is encountered in a specific context, its name might speculatively suggest a combination of operations. For example, 'ls' often implies 'list', 'pg' could relate to 'PostgreSQL' or 'page', and 'pot' might refer to 'Portable Object Template' files (used for localization) or 'pot files' (in password cracking contexts). However, any interpretation remains purely speculative without its accompanying documentation.


title: HISTORY
content:
There is no publicly available historical information, development context, or usage evolution for <b>lspgpot</b> due to its non-standard and unrecognized nature.


title: SYNOPSIS
content:
<b>lss16toppm</b> [<i>-width &lt;width&gt;</i>] [<i>-height &lt;height&gt;</i>] [<i>-scale &lt;scale&gt;</i>] [<i>-maxval &lt;maxval&gt;</i>] [<i>-minval &lt;minval&gt;</i>] [<i>-auto</i>] [<i>-colorspec &lt;channel&gt;</i>] [<i>-x</i>] [<i>-y</i>] [<i>-z</i>] [<i>-alpha</i>] [<i>-rawbits</i>] [<i>-verbose</i>] [<i>-version</i>] [<i>inputfile</i>]


title: PARAMETERS
content:
<b><i>-width &lt;width&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired width of the output image in pixels.<br><br><b><i>-height &lt;height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired height of the output image in pixels.<br><br><b><i>-scale &lt;scale&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A floating-point value to scale the 16-bit intensity values before converting to 8-bit. Useful for manual adjustment.<br><br><b><i>-maxval &lt;maxval&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly sets the maximum 16-bit input value that will map to 255 (or 65535 with <I>-rawbits</I>).<br><br><b><i>-minval &lt;minval&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly sets the minimum 16-bit input value that will map to 0.<br><br><b><i>-auto</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically determines the minimum and maximum 16-bit intensity values from the input data to optimize scaling, preventing clipping and maximizing contrast.<br><br><b><i>-colorspec &lt;channel&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines which specific data channel from the Leica raw stream (e.g., <I>R</I>ed, <I>G</I>reen, <I>B</I>lue, <I>I</I>ntensity, <I>C</I>olor, <I>X</I>-coordinate) is used for the output image's brightness.<br><br><b><i>-x</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts the X-axis coordinate mapping, flipping the image horizontally.<br><br><b><i>-y</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts the Y-axis coordinate mapping, flipping the image vertically.<br><br><b><i>-z</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts the Z-axis coordinate mapping, useful for specific viewing orientations.<br><br><b><i>-alpha</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a PGM (Portable Graymap) image with a maxval of 65535, intended to be used as an alpha channel for transparency in other applications.<br><br><b><i>-rawbits</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces a PGM (Portable Graymap) image with a maxval of 65535, preserving the original 16-bit data depth without scaling down to 8-bit, for full precision.<br><br><b><i>-verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints informational messages about the conversion process, such as detected min/max values or scaling factors, to standard error.<br><br><b><i>-version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <I>Netpbm</I> package and then exits.<br><br>


title: DESCRIPTION
content:
<I>lss16toppm</I> is a specialized command-line utility from the <I>Netpbm</I> image processing toolkit. It is designed to convert raw 16-bit data streams generated by Leica ScanStation 3000 or 2900 laser scanners into standard Portable Pixmap (PPM) or Portable Graymap (PGM) image formats.<br><br>The input data typically contains intensity readings, which <I>lss16toppm</I> transforms into brightness values for the output image. By default, it scales the 16-bit intensity values (0-65535) down to 8-bit (0-255) for standard PPM output. However, it can also preserve the 16-bit depth by outputting a PGM with a maxval of 65535, useful for applications requiring higher precision.<br><br>The command allows users to specify image dimensions, scaling behavior, and even which specific data channel (e.g., Red, Green, Blue, Intensity, Color, X-coordinate) from the raw stream should be used to form the output image.


title: CAVEATS
content:
The command requires input data to be in the specific raw 16-bit format generated by Leica ScanStation 3000/2900 devices. It cannot process arbitrary raw image data. The command expects a specific structure for the input data, often including intensity, X, Y, Z, and Color components. Misconfigured input or non-standard Leica data will likely lead to incorrect or corrupt output.<br><br>Output is always to standard output; redirect to a file for saving (e.g., <I>lss16toppm input.lss > output.ppm</I>).


title: STANDARD I/O BEHAVIOR
content:
If no <I>inputfile</I> is specified, <I>lss16toppm</I> reads raw data from standard input (<I>stdin</I>). The converted image is always written to standard output (<I>stdout</I>), making it suitable for piping with other <I>Netpbm</I> commands or redirecting to a file. For example, <I>cat rawdata.lss | lss16toppm -width 640 -height 480 > image.ppm</I>.


title: INTEGRATION WITH NETPBM TOOLS
content:
Since <I>lss16toppm</I> outputs standard <I>PPM</I> or <I>PGM</I> format, its output can be easily piped into other <I>Netpbm</I> utilities for further processing. This includes operations such as converting to other common image formats (e.g., PNG, JPEG), resizing, or applying various image manipulations using tools like <I>pnmtojpeg</I>, <I>pnmtopng</I>, or <I>pamscale</I>.


title: HISTORY
content:
<I>lss16toppm</I> is part of the extensive <I>Netpbm</I> image processing toolkit, a collection of graphics utilities that originated in the late 1980s. While the core <I>Netpbm</I> project has a long history, this specific utility was developed to address the specialized need of converting proprietary raw data from Leica ScanStation laser scanners, reflecting the toolkit's adaptability to various niche image processing tasks and its continuous evolution to support new formats and hardware.


title: PARAMETERS
content:
<b>-g, --generic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the associated SCSI generic (sg) device name, e.g., <i>/dev/sg0</i>.<br><br><b>-G, --gbytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For storage devices, shows the capacity in Gibibytes (GiB) instead of bytes.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message and exits.<br><br><b>-H, --hosts</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists SCSI host adapters only, without showing individual SCSI devices.<br><br><b>-k, --kname</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the kernel device name (e.g., <i>sda</i>) or sg device name (e.g., <i>sg0</i>), which is the default behavior.<br><br><b>-L, --lun</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the LUN field in hexadecimal format.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs device attributes one per line, useful for scripting or detailed inspection.<br><br><b>-p, --protection</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows protection information (DIF/DIX) for devices that support it.<br><br><b>-P, --parse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses the output of the <i>lsscsi</i> command itself, intended for internal use or complex scripting.<br><br><b>-r, --raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the raw SCSI peripheral device type code (e.g., 0 for disk, 5 for CD/DVD).<br><br><b>-s, --size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For storage devices, shows their capacity in bytes.<br><br><b>-S, --scsifs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the older <i>/proc/scsi/scsi</i> file system for device information, primarily for compatibility with older kernels. Defaults to <i>sysfs</i>.<br><br><b>-t, --tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays devices in a tree-like format, showing the host and device hierarchy.<br><br><b>-T, --transport</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows transport specific information for SCSI devices (e.g., SAS address, iSCSI details).<br><br><b>-U, --unit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes the LUN as part of the peripheral device name (e.g., <i>sda[0]</i>).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, displaying additional details such as kernel driver and device node paths.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <b>lsscsi</b> command and exits.<br><br><b>-w, --wwn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the World Wide Name (WWN) for devices that provide it, typically for Fibre Channel or SAS devices.<br><br>


title: DESCRIPTION
content:
The <b>lsscsi</b> command lists SCSI devices (or hosts) connected to the system. It queries the Linux <i>sysfs</i> file system (typically mounted at <i>/sys</i>) to gather detailed information about each device. This includes the SCSI host adapter, channel, target ID, and LUN (Logical Unit Number), often represented as <i>[H:C:T:L]</i>. For each device, it typically displays the vendor, product, revision, device type (e.g., disk, CD/DVD, tape, processor), and the associated block device name (e.g., <i>/dev/sda</i>) or SCSI generic (<i>sg</i>) device name (e.g., <i>/dev/sg0</i>). <br><br><b>lsscsi</b> is an invaluable tool for system administrators to quickly inventory and verify the presence and configuration of SCSI-based storage, optical drives, or other SCSI peripherals. Its output helps in understanding the SCSI topology, identifying specific hardware components, and correlating them with their respective device nodes in the <i>/dev</i> directory. It can also show devices that are not yet 'ready' or are currently in a state of flux.


title: CAVEATS
content:
<b>lsscsi</b> primarily relies on the Linux <i>sysfs</i> file system for information. If <i>sysfs</i> is not properly mounted (typically at <i>/sys</i>) or if device information is incomplete within <i>sysfs</i>, <b>lsscsi</b>'s output may be limited or inaccurate. On very old kernel versions where <i>sysfs</i> support might be limited, the <i>--scsifs</i> option might be necessary to query <i>/proc/scsi/scsi</i>. The command only reports detected devices; it does not perform any device discovery or configuration.


title: OUTPUT FORMAT
content:
The default output of <b>lsscsi</b> typically displays columns for host, channel, target, and LUN (e.g., <i>[H:C:T:L]</i>), followed by the vendor, product, revision, SCSI device type (e.g., disk, CD/DVD), and the associated kernel device name (e.g., <i>/dev/sda</i> or <i>/dev/sr0</i>). Other options can alter or add to these columns.


title: USAGE EXAMPLES
content:
To list all SCSI devices with their block device names: <i>lsscsi</i><br>To list all SCSI devices with their SCSI generic device names: <i>lsscsi -g</i><br>To list only SCSI host adapters: <i>lsscsi -H</i><br>To show device capacity: <i>lsscsi -s</i><br>To show devices in a tree-like format: <i>lsscsi -t</i>


title: HISTORY
content:
<b>lsscsi</b> is part of the <i>sg3_utils</i> package, a suite of utilities for sending SCSI commands. It was developed by Doug Gilbert. Its primary purpose was to provide a more structured and user-friendly way to list SCSI devices on Linux systems, moving beyond direct parsing of the older <i>/proc/scsi/scsi</i> interface to leverage the more robust and standardized <i>sysfs</i> file system (introduced around Linux 2.6). It became a de-facto standard for quickly inventorying SCSI hardware due to its simple syntax and clear output.


title: SYNOPSIS
content:
<b>lstopo</b> [<i>OPTION</i>]... [<i>&lt;output filename&gt;</i>]<br><br>Examples:<br><b>lstopo</b><br><b>lstopo</b> <b>--output</b> <i>topology.pdf</i><br><b>lstopo</b> <b>--of</b> <i>svg</i> > <i>topology.svg</i><br><b>lstopo</b> <b>--input</b> <i>system.xml</i>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose messages.<br><br><b><b>-s</b>, <b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable verbose messages.<br><br><b><b>-p</b>, <b>--physical</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display physical indexes (e.g., socket IDs, core IDs as seen by the hardware).<br><br><b><b>-l</b>, <b>--logical</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display logical indexes (default behavior).<br><br><b><b>-c</b>, <b>--cpuset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show CPU set information for each object.<br><br><b><b>--no-caches</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show any caches.<br><br><b><b>--no-io</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show I/O devices and bridges.<br><br><b><b>--no-numa</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show NUMA nodes.<br><br><b><b>--merge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Merge identical PUs and Caches.<br><br><b><b>--input</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load topology from the specified XML file instead of discovering it from the system.<br><br><b><b>--output</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the output to the specified file. The format is inferred from the file extension.<br><br><b><b>--of</b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format explicitly (e.g., 'txt', 'pdf', 'png', 'svg', 'xml').<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report program version and exit.<br><br>


title: DESCRIPTION
content:
<b>lstopo</b> is a command-line tool that displays the hierarchical topology of a system. It leverages the <i>hwloc</i> (Hardware Locality) library to discover and present detailed information about processing units, NUMA nodes, caches, and I/O devices. The command provides a comprehensive view of how these components are interconnected, showing their physical and logical relationships.<br><br>This visualization is crucial for understanding the underlying hardware architecture, which is vital for optimizing application performance, especially in parallel computing and High-Performance Computing (HPC) environments. <b>lstopo</b> can output the topology in various formats, including plain text, graphical representations (e.g., PDF, PNG, SVG), and XML, allowing for flexible analysis and integration into other tools. It helps users identify CPU sets, understand memory locality, and diagnose potential performance bottlenecks related to hardware layout.<br><br>By providing insights into the system's architecture, <b>lstopo</b> assists developers and system administrators in making informed decisions regarding process placement, memory allocation, and thread affinity, thereby maximizing hardware utilization and application efficiency.


title: CAVEATS
content:
<b>lstopo</b> relies on the underlying operating system and hardware for topology discovery. Its accuracy can sometimes vary depending on the kernel version, specific hardware configurations, or virtualization environment. In virtualized settings, the displayed topology reflects the virtual hardware presented to the guest, not necessarily the physical host.<br><br>Graphical output formats (like PDF, PNG, SVG) require the presence of specific libraries (e.g., Cairo, X11) at compile time and runtime. If these dependencies are not met, only text-based output might be available or the command may fail for graphical formats.


title: OUTPUT FORMATS
content:
<i>lstopo</i> is highly versatile in its output options. Besides the default textual representation, it can generate graphical outputs like <b>PNG</b>, <b>PDF</b>, and <b>SVG</b> files, which are excellent for documentation and visual analysis. It also supports <b>XML</b> output, allowing programmatic parsing of the topology data, and interactive <b>X11</b> display for live viewing. The output format is typically inferred from the output filename's extension or explicitly specified using `<b>--of</b>`.


title: USE CASES
content:
Understanding system topology via <i>lstopo</i> is crucial for:<br><b>Performance Optimization</b>: Pinning processes/threads to specific cores or NUMA nodes for optimal cache and memory access.<br><b>Resource Management</b>: Allocating resources efficiently in virtualized environments or container orchestrators.<br><b>Debugging</b>: Identifying performance bottlenecks caused by poor hardware affinity.<br><b>System Documentation</b>: Generating clear diagrams of server hardware configurations.<br><br>It's widely used in HPC clusters, cloud environments, and any scenario where hardware-aware programming is beneficial.


title: HISTORY
content:
<b>lstopo</b> is a core utility of the <i>hwloc</i> (Hardware Locality) project, which originated from efforts within the French national research institute <i>INRIA</i> and <i>Bordeaux University</i>. The project's primary goal was to provide a portable and robust way for applications to discover and exploit hardware locality, particularly in the context of High-Performance Computing (HPC) and parallel programming.<br><br>It evolved from earlier, less portable projects like <i>libtopology</i> and <i>PLPA</i> (Portable Linux Processor Affinity). <i>hwloc</i> was designed to be independent of specific operating systems or architectures, offering a unified API and set of tools for various Unix-like systems and Windows. <b>lstopo</b> quickly became the flagship visualization tool for the <i>hwloc</i> library, demonstrating its capabilities to users through clear and comprehensive graphical and text representations of system topology. Its development has focused on improving accuracy, adding support for new hardware features (like CXL, more cache types, I/O devices), and expanding output format options.


title: PARAMETERS
content:
<b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show verbose details for all devices. This includes configuration descriptors, interfaces, endpoints, and class information. Useful for in-depth analysis.<br><br><b>-s [[bus]:[devnum]], --sysfs [[bus]:[devnum]]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only devices for a specific bus and/or device number. For example, <code>-s 001:003</code> lists device 3 on bus 1. <code>-s 002:</code> lists all devices on bus 2.<br><br><b>-t, --tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show USB devices in a hierarchical tree-like format, reflecting their connection topology. This helps visualize the USB hub and device relationships.<br><br><b>-d vendor:product, --device vendor:product</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only devices with the specified vendor and product IDs. These IDs are usually in hexadecimal format (e.g., <code>1234:5678</code>).<br><br><b>-D device, --dump device</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the contents of the device descriptor for the specified device file (e.g., <code>/dev/bus/usb/001/003</code>). This requires root privileges and provides raw descriptor data.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information for the <b>lsusb</b> utility.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
The <b>lsusb</b> command is a utility in Linux used to display information about the USB (Universal Serial Bus) controllers and attached devices. It queries the kernel's USB device tree, typically by reading the `/sys/bus/usb/devices` directory, to provide a comprehensive list of all detected USB devices.<br><br>For each device, <b>lsusb</b> provides details such as the bus number, device number, unique ID (combining vendor and product IDs), and a descriptive name. This information is invaluable for system administrators and users alike when troubleshooting hardware issues, verifying device recognition, identifying specific USB peripherals, or diagnosing driver problems. It helps in understanding which devices are connected, their capabilities, and how the system perceives them, without needing to physically inspect each port.


title: CAVEATS
content:
While <b>lsusb</b> generally provides accurate information, some detailed operations, like dumping raw device descriptors (using <code>-D</code>), may require root privileges. The human-readable names for vendor and product IDs are resolved using the <code>/usr/share/hwdata/usb.ids</code> or similar files; if this file is missing or outdated, only hexadecimal IDs will be shown.


title: INTERPRETING OUTPUT
content:
The default output of <b>lsusb</b> typically presents each device on a new line with the format: <code>Bus <i>NNN</i> Device <i>NNN</i>: ID <i>VVVV</i>:<i>PPPP</i> <i>Device Name</i></code>.<br><br><ul><li><b>Bus <i>NNN</i></b>: Refers to the USB bus number.</li><li><b>Device <i>NNN</i></b>: Represents the device number on that specific bus.</li><li><b>ID <i>VVVV</i>:<i>PPPP</i></b>: Is the unique Vendor ID (<i>VVVV</i>) and Product ID (<i>PPPP</i>) assigned by the USB Implementers Forum (USB-IF). These hexadecimal IDs are used to identify the device and its manufacturer.</li><li><b><i>Device Name</i></b>: A human-readable description of the device, resolved from the <i>usb.ids</i> file.</li></ul>


title: THE USB.IDS FILE
content:
<b>lsusb</b> relies on the <code>/usr/share/hwdata/usb.ids</code> file (or a similar path depending on the distribution) to translate numerical Vendor and Product IDs into human-readable names. This file is a comprehensive list of known USB vendor and device IDs. It's periodically updated, and keeping it current ensures that <b>lsusb</b> can display meaningful names for newly released hardware.


title: HISTORY
content:
The <b>lsusb</b> command is part of the <i>usbutils</i> package, which provides various utilities for managing USB devices on Linux. Its development has closely tracked the evolution of the Linux kernel's USB subsystem. Initially, it might have relied on parsing the <code>/proc/bus/usb</code> filesystem, but modern versions primarily query the <code>/sys</code> filesystem, which is the standard interface for kernel objects. This shift improved robustness and provided more consistent access to device information.


title: PARAMETERS
content:
<b>-help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the <I>lsyncd</I> version and exit.<br><br><b>-log <I>FILE</I>, -L <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the log file.<br><br><b>-log-level <I>LEVEL</I>, -l <I>LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging verbosity (e.g., <I>error</I>, <I>warning</I>, <I>notice</I>, <I>info</I>, <I>debug</I>).<br><br><b>-daemon, -d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <I>lsyncd</I> as a background daemon process.<br><br><b>-pidfile <I>FILE</I>, -p <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the process ID to the specified file.<br><br><b>-config <I>FILE</I>, -c <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Lua configuration file to use. This is mandatory for operation.<br><br><b>-delay <I>SECONDS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the default <I>delay</I> setting from the config file, waiting this many seconds before <I>rsync</I>ing.<br><br><b>-dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run, simulating synchronization without making actual changes.<br><br><b>-no-daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent <I>lsyncd</I> from daemonizing, useful for debugging.<br><br><b>-syslog</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Send log messages to syslog instead of a file or stdout.<br><br>


title: DESCRIPTION
content:
<I>lsyncd</I> is a lightweight daemon that provides real-time file synchronization between local directories and remote hosts. It efficiently monitors local filesystem changes using <I>inotify</I> events (on Linux) or <I>fsevents</I> (on macOS) and then leverages <I>rsync</I> as its underlying transfer mechanism to propagate those changes. This makes it an ideal solution for live mirroring, continuous backups, and maintaining synchronized data across servers with minimal latency. Its core strength lies in its event-driven nature, avoiding the overhead of frequent polling, and its flexibility, which is primarily configured through a powerful Lua scripting interface. It's designed for simple setup and high performance, making it popular for replicating web content, logs, or other critical data.


title: CAVEATS
content:
<I>lsyncd</I> relies on <I>inotify</I> limits for watched files/directories, which may need tuning for very large file trees. It requires <I>rsync</I> to be installed and accessible on both the local and remote systems. Initial synchronization of large datasets is often best handled by a separate, one-time <I>rsync</I> command, as <I>lsyncd</I> is designed for incremental changes. Its Lua-based configuration, while powerful, can have a learning curve. Care must be taken with <I>rsync</I> options, especially regarding file deletions, to ensure desired behavior.


title: CONFIGURATION FILE
content:
<I>lsyncd</I>'s behavior is almost entirely defined by a Lua-scripted configuration file. This file specifies source directories, destination hosts, <I>rsync</I> parameters, SSH settings, logging options, and rules for what to include or exclude during synchronization. This powerful scripting capability allows for highly customized mirroring setups.


title: HOW IT WORKS
content:
At its core, <I>lsyncd</I> establishes watches on directories using the <I>inotify</I> API (or <I>fsevents</I> on macOS). When the kernel notifies <I>lsyncd</I> of changes (e.g., file creation, modification, deletion, move), it collects these events. After a configurable <I>delay</I> (to batch multiple rapid changes), <I>lsyncd</I> executes an <I>rsync</I> command, passing the detected changes and specified options to efficiently synchronize the local and remote locations.


title: HISTORY
content:
<I>lsyncd</I> emerged as a pragmatic solution to real-time file synchronization challenges. It was conceived to be lightweight and efficient by combining existing, robust Linux primitives: <I>inotify</I> for event detection and <I>rsync</I> for data transfer. This approach avoids the resource intensity of polling-based synchronization tools and the complexity of full-blown distributed file systems. The use of Lua for configuration provided a flexible and powerful way to define synchronization tasks, making it adaptable to various scenarios since its early development.


title: SYNOPSIS
content:
<b>ls</b> [<i>OPTION</i>]... [<i>FILE</i>]...<br><i>Note:</i> <b>lt</b> is typically an alias for <b>ls -lt</b>.


title: PARAMETERS
content:
<b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a long listing format, showing detailed information (permissions, owner, size, time, etc.).<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by modification time, with the newest entries listed first.<br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ignore entries starting with '.' (hidden files and directories).<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>-l</b>, print human readable sizes (e.g., 1K, 234M, 2G).<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverse the order of sorting.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List directories themselves, rather than their contents.<br><br><b>--time-style=<i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show times in the specified format (e.g., 'full-iso' for YYYY-MM-DD HH:MM:SS.NNNNNNNNN +ZZZZ).<br><br>


title: DESCRIPTION
content:
The command <b>lt</b> is not a standard standalone Linux command. Instead, it is most frequently encountered as a user-defined alias for the <br><b>ls -lt</b> command. The <b>ls</b> utility is one of the most fundamental commands in Linux, used to list the contents of directories. When combined with the <b>-l</b> and <b>-t</b> options, its behavior is specifically modified:<br><b>-l</b> (long format): Displays detailed information about each file or directory, including permissions, number of hard links, owner, group, size, and last modification time.<br><b>-t</b> (sort by time): Sorts the output by modification time, with the newest files or directories appearing first.<br><br>Therefore, when you execute <b>lt</b>, you are typically invoking <b>ls -lt</b>, which provides a detailed, time-sorted list of files and directories in the current working directory, or a specified path. This alias is popular among users who frequently need to see recently modified files quickly. It's a convenience shortcut rather than a distinct command.


title: CAVEATS
content:
The primary caveat for <b>lt</b> is that it is not a standard Linux command. Its functionality relies entirely on a user-defined alias, typically set in shell configuration files like <b>.bashrc</b> or <b>.zshrc</b>. Therefore, <b>lt</b> may not be available on all systems, or it might perform a different action if a user has defined it differently. Always confirm its definition with <b>alias lt</b> or <b>type lt</b> if its behavior is unexpected. Relying on <b>ls -lt</b> directly ensures portability across different environments.


title: DEFINING THE ALIAS
content:
To create the <b>lt</b> alias yourself, you can add the following line to your shell's configuration file (e.g., <b>~/.bashrc</b> for Bash, <b>~/.zshrc</b> for Zsh):<br><b>alias lt='ls -lt'</b><br>After adding the line, you need to either open a new terminal session or source the configuration file (e.g., <b>source ~/.bashrc</b>) for the alias to take effect.


title: HISTORY
content:
The history of the <b>ls</b> command dates back to the early days of Unix. It was one of the first commands developed for the AT&T Unix operating system. The <b>-l</b> (long format) and <b>-t</b> (sort by time) options have been integral parts of <b>ls</b> for a very long time, providing essential ways to view file system contents. The concept of creating shell aliases like <b>lt</b> for frequently used command combinations (like <b>ls -lt</b>) emerged with the development of more advanced shells such as <b>csh</b>, <b>ksh</b>, <b>bash</b>, and <b>zsh</b>, allowing users to customize their command-line environment for efficiency and personal preference.


title: SYNOPSIS
content:
<b>ltrace</b> [<i>options</i>] [<i>command</i> [<i>arguments</i>]]<br><b>ltrace</b> [<i>options</i>] <b>-p</b> <i>pid</i>


title: PARAMETERS
content:
<b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Count library calls and print a summary report upon exit, including the time spent in each call.<br><br><b><b>-e</b> <i><expr></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A qualifying expression that specifies which library calls to trace or exclude. <i><expr></i> can use <b>+</b> (trace), <b>-</b> (do not trace), or specific function patterns (e.g., <b>+memcpy</b>, <b>-strlen</b>).<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Trace child processes as they are created by <b>fork()</b>, <b>vfork()</b>, or <b>clone()</b>.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the instruction pointer (program counter) at the time of the library call.<br><br><b><b>-l</b> <i><library></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Trace calls only from a specific library. <i><library></i> can be a library name (e.g., <b>libc.so.6</b> or <b>libpthread</b>).<br><br><b><b>-o</b> <i><filename></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirect the trace output to the specified <i><filename></i> instead of standard error.<br><br><b><b>-p</b> <i><pid></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attach to an already running process with the given process ID (<i><pid></i>).<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print a relative timestamp (in microseconds) showing the time elapsed since the beginning of the trace.<br><br><b><b>-s</b> <i><size></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the maximum string <i><size></i> (in bytes) to print. Longer strings will be truncated with '...'.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display system calls in addition to library calls, similar to <i>strace</i>'s output.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print an absolute timestamp for each line of output, showing the current time of day.<br><br><b><b>-T</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the time spent in each library call, from its entry to its return. This time is printed on the call's return line.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of <i>ltrace</i> and exit.<br><br><b><b>-x</b> <i><syscall_expr></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A qualifying expression for system calls to trace or exclude. Similar to <b>-e</b>, but specifically for syscalls (e.g., <b>+open</b>, <b>-read</b>).<br><br>


title: DESCRIPTION
content:
<i>ltrace</i> is a powerful diagnostic and debugging utility for Linux that intercepts and records dynamic library calls made by a user-space process. It provides insights into a program's runtime behavior by displaying the library function names, their arguments, and return values.<br><br>While similar to <i>strace</i>, which traces system calls, <i>ltrace</i> focuses on the higher-level library functions (e.g., <i>libc</i>, <i>libpthread</i>, etc.). This makes it invaluable for understanding how a program interacts with shared libraries, debugging issues related to incorrect library usage, reverse engineering binaries, or analyzing unexpected program behavior without access to source code. It can also trace signals delivered to a process.


title: CAVEATS
content:
Using <i>ltrace</i> can introduce significant performance overhead to the traced process, potentially slowing it down considerably. It typically requires appropriate permissions (e.g., root privileges or <b>CAP_SYS_PTRACE</b> capability) to attach to or launch processes. Some highly optimized or obfuscated binaries might behave unexpectedly or resist tracing with <i>ltrace</i>. It is primarily effective for dynamically linked executables; tracing statically linked binaries is more complex or not fully supported.


title: OUTPUT FORMAT
content:
The typical output of <i>ltrace</i> displays the name of the library function called, followed by its arguments enclosed in parentheses. Upon the function's return, an equals sign (<b>=</b>) is printed, followed by the function's return value. For example: <b>read(0, "hello\n", 6) = 6</b>. String arguments are often displayed in a human-readable format, and pointers or complex data structures are summarized.


title: USAGE SCENARIOS
content:
<i>ltrace</i> is widely used for diagnosing issues like segmentation faults (e.g., by observing incorrect arguments to library functions), identifying missing or incorrect library dependencies, understanding the behavior of closed-source or third-party applications, reverse engineering unknown binaries to analyze their functionality (e.g., network operations, file access, cryptographic calls), and analyzing software for security vulnerabilities by observing API calls.


title: HISTORY
content:
<i>ltrace</i> was originally developed by Juan Cespedes in the late 1990s as a complementary tool to <i>strace</i>, aiming to provide a higher-level view of program execution by focusing on library calls rather than raw system calls. It quickly became a standard utility on Linux distributions, filling a crucial gap in debugging and analysis toolkits. The project has undergone continuous development and maintenance, evolving to support new Linux kernel features, architectures, and addressing various tracing complexities.


title: SYNOPSIS
content:
<b>lua</b> [<i>options</i>] [<i>script</i> [<i>args</i>]]<br><b>lua</b> [<i>options</i>] -<b>e</b> "<i>chunk</i>" [<i>args</i>]<br><b>lua</b> [<i>options</i>] -<b>l</b> <i>file</i> [<i>args</i>]<br><b>lua</b> [<i>options</i>] -


title: PARAMETERS
content:
<b>-e <i>chunk</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the given <i>chunk</i> of Lua code specified as a string.<br><br><b>-l <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads and executes the specified Lua <i>file</i> before processing other arguments. Useful for libraries.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enters interactive mode (REPL) after executing <i>script</i> or <i>chunk</i>, if any.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information about the Lua interpreter to standard output.<br><br><b>-E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores environment variables like <i>LUA_PATH</i> and <i>LUA_CPATH</i> when searching for modules.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops processing options. All subsequent arguments are passed to the script as literal arguments.<br><br><b>-</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads Lua code from standard input. If no script is provided, it enters interactive mode.<br><br><b><i>script</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the Lua script file to be executed.<br><br><b><i>args</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments passed to the Lua script, accessible within the script via the global <i>arg</i> table.<br><br>


title: DESCRIPTION
content:
The <b>lua</b> command is the official interpreter for the Lua programming language. Lua is a powerful, efficient, and lightweight scripting language designed primarily for embedding in applications. It's known for its small footprint, high performance, and simple C API, making it an excellent choice for a wide range of uses, including game development, web applications, embedded systems, and general scripting. When invoked, the <b>lua</b> command reads and executes Lua source code, either from a specified file, from standard input, or from a string provided on the command line. It provides a flexible and fast environment for running Lua programs.


title: CAVEATS
content:
The functionality and available modules of the <b>lua</b> command depend on how Lua was compiled and installed on the system. Behavior might differ slightly between major Lua versions (e.g., Lua 5.1 vs. Lua 5.4). Scripts may fail if required modules are not found in the <i>LUA_PATH</i> or <i>LUA_CPATH</i>, or if those variables are ignored with the <b>-E</b> option.


title: INTERACTIVE MODE
content:
If no script file or <b>-e</b> <i>chunk</i> is provided, or if the <b>-i</b> option is used, the <b>lua</b> command enters an interactive mode (REPL: Read-Eval-Print Loop) where users can type Lua code directly and see the immediate results.


title: ENVIRONMENT VARIABLES
content:
The <b>lua</b> command respects environment variables such as <i>LUA_PATH</i> and <i>LUA_CPATH</i>, which define the search paths for Lua modules and C modules, respectively. These can be overridden or ignored using the <b>-E</b> option for predictable script execution.


title: EXIT STATUS
content:
The <b>lua</b> command typically exits with a status of 0 upon successful execution of a script or interactive session. A non-zero exit status usually indicates an error during parsing, compilation, or runtime execution of the Lua code within the interpreter.


title: HISTORY
content:
Lua was created in 1993 by Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes at PUC-Rio, Brazil. Initially designed for extending applications, it gained popularity for its embeddability, speed, and small size. Major versions have been released over time, with Lua 5.0 (2003), 5.1 (2006), 5.2 (2012), 5.3 (2015), and 5.4 (2020) introducing new features and improvements while maintaining its core philosophy. Its usage expanded significantly, particularly in game development (e.g., Roblox, World of Warcraft add-ons) and embedded systems, due to its efficiency and ease of integration.


title: PARAMETERS
content:
<b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the bytecode of the compiled Lua source file(s) to standard output, without generating an output file. This is useful for inspecting the compiled code.<br><br><b><b>-o</b> <i>&lt;output&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file for the compiled bytecode. If this option is not provided, the default output file name is '<i>luac.out</i>'.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses the input file(s) only for syntax errors. No bytecode is generated, and no output file is created. This option is useful for quick syntax checking.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Strips debug information (e.g., line numbers, local variable names) from the compiled bytecode. This can slightly reduce the file size and provide minor obfuscation, making decompilation harder.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the Lua compiler (<i>luac</i>) to standard output.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose version information, including details about the Lua core and its build configuration.<br><br><b><b>-</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads input from standard input (stdin) instead of a specified file. This allows piping content directly to <i>luac</i>.<br><br><b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Signals the end of command-line options. Any arguments following '<b>--</b>' are treated as filenames, even if they begin with a hyphen.<br><br>


title: DESCRIPTION
content:
luac is the official Lua compiler, a utility program included with the Lua distribution. Its primary function is to compile Lua source code files into a binary representation known as Lua bytecode. This bytecode can then be executed by the <i>lua</i> interpreter.<br><br>Compiling scripts into bytecode offers several advantages: it can improve startup performance by skipping the parsing phase, subtly obfuscate source code from casual viewing (though it's not strong encryption), and allow for pre-distribution of compiled code. While Lua is primarily an interpreted language, luac facilitates a compile-then-run workflow, especially useful for larger applications or embedded systems where resource optimization is crucial.


title: CAVEATS
content:
While <i>luac</i> compiles source code to bytecode, this bytecode is not truly secure and can often be decompiled using various tools. Additionally, Lua bytecode is generally not portable across different architectures or even different builds of Lua with varying integer or float sizes. This means bytecode compiled on one system might not run on another if their Lua Virtual Machine (VM) configurations differ significantly.


title: CROSS-PLATFORM CONSIDERATIONS
content:
Lua bytecode is specific to the Lua VM version and the architecture on which it was compiled (e.g., endianness, size of <i>int</i> and <i>float</i> types). For maximum portability, it is generally recommended to distribute Lua source code and compile it on the target system, or to ensure that the target system's Lua environment closely matches the compilation environment.


title: HISTORY
content:
Lua was first created in 1993 by Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes at PUC-Rio, Brazil. From its early versions, <i>luac</i> has been an integral part of the Lua distribution, providing a compile-time tool for preparing Lua scripts. Its inclusion reflects Lua's design philosophy of being a lightweight, embeddable language where pre-compilation can be beneficial for performance and resource-constrained environments. Over the years, <i>luac</i> has evolved alongside the Lua language, adapting to new bytecode formats and language features while maintaining its core functionality.


title: SYNOPSIS
content:
<b>luajit</b> [<i>options</i>] [<i>script</i> [<i>args</i>]]<br><b>luajit</b> -e "<i>chunk</i>" [<i>args</i>]<br><b>luajit</b> -l <i>file</i> [<i>args</i>]<br><b>luajit</b> -b [<i>options</i>] <i>infile</i> [<i>outfile</i>]


title: PARAMETERS
content:
<b>-e <I>chunk</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the given Lua <I>chunk</I> string.<br><br><b>-l <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads and executes the Lua <I>file</I>.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables bytecode dumping or loading mode. Used with other options to specify format (e.g., <b>-t</b> for text, <b>-c</b> for C source). If no output file is specified, it writes to standard output.<br><br><b>-b -t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps bytecode in a human-readable text format.<br><br><b>-b -c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps bytecode as C source code, which can be compiled directly into a C program.<br><br><b>-b -a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends the output to the specified output file instead of overwriting it, when used with <b>-b</b>.<br><br><b>-b -n <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the C array name for bytecode dumps in C source format (<b>-b -c</b>).<br><br><b>-b -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes debug information (e.g., line numbers, local variable names) in bytecode dumps.<br><br><b>-j <I>opt=val</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets JIT compiler options. Common options include: <b>on</b>/<b>off</b> (enable/disable JIT), <b>hotloop=N</b> (minimum iterations for a loop to be considered hot), <b>opt=level</b> (optimization level 0-9), <b>dump</b> (dump generated machine code), <b>trace</b> (dump trace assembly), <b>mcode=N</b> (max machine code size in KB).<br><br><b>-O <I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the JIT optimization level (0-9). This is a shorthand for <b>-j opt=level</b>.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information for LuaJIT, including the Lua version it supports and the JIT version.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with common command-line options and their usage.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Signals the end of command-line options. All subsequent arguments are treated as script arguments, even if they start with a hyphen.<br><br><b><I>script</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the Lua script file to be executed by LuaJIT.<br><br><b><I>args</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments passed to the Lua script. These arguments are typically accessible within the script via the global `arg` table.<br><br>


title: DESCRIPTION
content:
<i>luajit</i> is a Just-In-Time (JIT) compiler and extended interpreter for the <I>Lua</I> programming language. It is designed for maximum performance while maintaining compatibility with the Lua 5.1 language specification and C API. <br><br>Unlike standard Lua interpreters, LuaJIT dynamically compiles frequently executed code sections (hot loops) into machine code at runtime, significantly boosting execution speed. It also includes powerful non-standard extensions like the <I>Foreign Function Interface</I> (FFI) for direct interaction with C libraries and data structures, and the <I>bitop</I> library for bitwise operations. <br><br>LuaJIT is widely used in performance-critical applications, including game development, web services (e.g., OpenResty), scientific computing, and embedded systems, where its speed and low memory footprint are highly valued.


title: CAVEATS
content:
LuaJIT is primarily compatible with Lua 5.1 and does not fully support all features introduced in later Lua versions (5.2, 5.3, 5.4), such as `goto` statements, bitwise operators (unless using the bundled `bitop` library explicitly), or newer additions to the standard library. Its JIT tracing benefits are most pronounced for long-running processes with hot loops and consistent data types, and less so for very short-lived scripts or code with highly polymorphic types.


title: FOREIGN FUNCTION INTERFACE (FFI)
content:
A significant non-standard extension in LuaJIT, FFI allows Lua programs to directly call external C functions and access C data structures without writing C binding code. This dramatically simplifies integration with C libraries and enables high-performance interactions, blurring the lines between Lua and C and avoiding marshalling overhead.


title: BYTECODE COMPILATION AND EMBEDDING
content:
LuaJIT provides robust tools for compiling Lua source code into its internal bytecode format (<b>-b</b> option). This bytecode can then be executed directly, or even dumped into a text or C source file. This feature is valuable for distributing applications, obfuscating code, or embedding Lua scripts directly into C/C++ executables without needing the original source files present at runtime.


title: HISTORY
content:
LuaJIT was originally created by Mike Pall, with initial development starting in the late 2000s and the first public release around 2009. Its primary goal was to provide Lua with performance comparable to C, leveraging advanced JIT compilation techniques, particularly trace-based JIT. It quickly gained popularity for its speed and efficient resource usage, becoming a cornerstone in various high-performance systems and games (e.g., OpenResty, Torch). While core development has slowed in recent years, it remains a highly influential and widely deployed runtime.


title: PARAMETERS
content:
<b>-output-directory=<I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Place all output files (PDF, log, etc.) in the specified <I>DIR</I>.<br><br><b>-jobname=<I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <I>NAME</I> for all output files, instead of the input file's base name (e.g., <I>NAME</I>.pdf, <I>NAME</I>.log).<br><br><b>-interaction=<I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the interaction mode. Common modes include <b>batchmode</b> (no user interaction), <b>nonstopmode</b> (don't pause for errors), <b>scrollmode</b> (don't pause for errors, print less), and <b>errorstopmode</b> (pause on errors, default).<br><br><b>-shell-escape</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable the execution of external commands via <b>\write18</b> or Lua's <b>os.execute</b>. This is a security risk and should be used with caution.<br><br><b>-no-shell-escape</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable the execution of external commands. This is the default and recommended for security.<br><br><b>-draftmode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process the document quickly, skipping image inclusion and some complex operations. Useful for quick compilation checks.<br><br><b>-file-line-error</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print error messages in a standard <I>file:line:error</I> format, which is useful for integration with text editors and IDEs.<br><br><b>-halt-on-error</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit immediately upon encountering the first error during compilation.<br><br><b>-recorder</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write a <b>.fls</b> file (file list) that records all files opened for input and output during compilation. Useful for tracking dependencies.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of lualatex and exit.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief usage message and exit.<br><br>


title: DESCRIPTION
content:
lualatex is a typesetting engine for LaTeX documents, part of the TeX Live and MiKTeX distributions. It is built upon LuaTeX, which combines the powerful <I>Lua scripting language</I> directly into the TeX engine. This integration allows users to extend TeX's capabilities with arbitrary Lua code, enabling highly customized typesetting, advanced macro programming, and dynamic content generation. <br><br>lualatex natively supports <I>Unicode (UTF-8)</I> input and <I>OpenType fonts</I>, providing superior typographic control and simplifying multilingual document creation compared to older TeX engines. It typically outputs PDF files directly. Its flexibility makes it a preferred choice for complex documents requiring features like microtypography, advanced graphics integration, and programmatic document manipulation that are difficult or impossible with traditional LaTeX.


title: CAVEATS
content:
<I>Performance:</I> Can be slower than <b>pdflatex</b> for very large or complex documents due to the overhead of the Lua interpreter.<br><I>Memory Usage:</I> May consume more memory, especially with large Lua scripts or complex font setups.<br><I>Package Compatibility:</I> While largely compatible, some older LaTeX packages designed for <b>latex</b> or <b>pdflatex</b> might not work perfectly or require specific adjustments.<br><I>Debugging:</I> Debugging Lua code within <b>lualatex</b> can be more complex than debugging traditional TeX macros.


title: <I>KEY ADVANTAGES:</I>
content:
<b>Lua Integration:</b> Allows for powerful programmatic control over typesetting, macro development, and dynamic content generation directly within the TeX engine.<br><b>Native Unicode (UTF-8) Support:</b> Simplifies multilingual document creation without needing complex input encoding packages.<br><b>OpenType Font Support:</b> Direct access to advanced typographic features (ligatures, stylistic sets, etc.) provided by OpenType fonts, without external utilities.<br><b>Microtypography:</b> Enhanced control over character spacing, protrusion, and expansion for better justification and overall appearance.


title: HISTORY
content:
lualatex emerged as part of the LuaTeX project, which began development around 2006 as a successor to pdfTeX. The primary goal was to build a TeX engine with modern features like Unicode support, OpenType font capabilities, and, most importantly, direct integration of the <I>Lua scripting language</I>. This integration allows for powerful extensibility and programmatic control over the typesetting process, moving beyond the limitations of TeX's macro language. lualatex specifically refers to using the LuaTeX engine to process LaTeX documents, leveraging the LaTeX format alongside LuaTeX's advanced features. It has gained significant traction in the LaTeX community for its flexibility and power, especially for complex typographic tasks and dynamic document generation.


title: PARAMETERS
content:
<b><b>-V</b> or <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version number and exits.<br><br><b><b>-h</b> or <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message and exits.<br><br><b><b>-v</b> or <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose diagnostic messages during operation.<br><br><b><b>-t</b> or <b>--transparent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Acts as a transparent filter; no character set conversion is performed. Useful for debugging character flow.<br><br><b><b>-p</b> or <b>--pretend-terminal</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not attempt to adjust the terminal settings (e.g., character mapping) but still performs character set conversion.<br><br><b><b>-l</b> <I>locale</I> or <b>--locale=</b><I>locale</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the locale name to use for character set conversions. Overrides the system locale environment variables.<br><br><b><b>-c</b> or <b>--character-sets</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of all supported character sets and exits.<br><br><b><b>-k</b> <I>codeset</I> or <b>--keyboard=</b><I>codeset</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character set of the keyboard input. This is what <b><code>luit</code></b> expects from the user's keyboard.<br><br><b><b>-s</b> <I>codeset</I> or <b>--screen=</b><I>codeset</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character set of the screen output. This is what the terminal emulator expects to display.<br><br><b><b>-i</b> <I>codeset</I> or <b>--input=</b><I>codeset</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character set of the program's input (what <b><code>luit</code></b> receives from the wrapped program's standard output).<br><br><b><b>-o</b> <I>codeset</I> or <b>--output=</b><I>codeset</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character set of the program's output (what <b><code>luit</code></b> sends to the wrapped program's standard input).<br><br><b><b>-e</b> <I>encoding</I> or <b>--encoding=</b><I>encoding</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Deprecated</I>. This option is superseded by the more granular <b>-l</b>, <b>-k</b>, <b>-s</b>, <b>-i</b>, and <b>-o</b> options.<br><br><b><b>-g</b> <I>codeset</I> or <b>--display-codeset=</b><I>codeset</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character set for display output, functionally similar to <b>-s</b>.<br><br><b><b>-m</b> <I>codeset</I> or <b>--mouse-codeset=</b><I>codeset</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character set for mouse reporting (e.g., coordinates sent by mouse events).<br><br><b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A special argument that indicates the end of <b><code>luit</code></b>'s options. All arguments following <b><code>--</code></b> are treated as the command to be executed by <b><code>luit</code></b>.<br><br>


title: DESCRIPTION
content:
<b><code>luit</code></b> (Locale un-independent terminal) is a character set filter that allows X terminals (like xterm) to support different locales and encodings beyond the traditional Latin-1 or ASCII. It translates data between the locale's character set (e.g., UTF-8, EUC-JP) and the terminal's character set (usually ISO-8859-1 or UCS-2 for xterm). This is crucial for displaying non-Latin scripts (like Japanese, Chinese, Korean) or characters outside the basic ASCII range correctly in terminals that might not natively understand those encodings.<br><br>Typically, <b><code>luit</code></b> is invoked as a wrapper around another command, such as <b><code>xterm</code></b>, like <code><b>luit</b> <I>-l</I> <I>zh_CN.GBK</I> <b>--</b> <I>xterm</I></code>. It intercepts the input and output streams, performing character set conversions on the fly. This ensures that what you type is correctly interpreted by the application, and what the application outputs is correctly displayed by your terminal. Without <b><code>luit</code></b>, an older <b><code>xterm</code></b> might display garbled text when an application tries to output characters from a different character set. Modern <b><code>xterm</code></b> versions often have better native UTF-8 support, reducing the explicit need for <b><code>luit</code></b> in many common scenarios, but it remains valuable for specific legacy setups or fine-grained control over encoding.


title: CAVEATS
content:
<b><code>luit</code></b> relies heavily on correct locale configuration. If the system's <b><code>LANG</code></b> or <b><code>LC_CTYPE</code></b> environment variables are not set appropriately, <b><code>luit</code></b> might not function as expected or might choose an incorrect default encoding.<br><br>Modern versions of <b><code>xterm</code></b> (and most other popular terminal emulators like <b><code>Gnome Terminal</code></b>, <b><code>Konsole</code></b>, <b><code>Alacritty</code></b>, <b><code>kitty</code></b>) have robust native UTF-8 support built-in. In such environments, <b><code>luit</code></b> is often unnecessary when the primary goal is to display UTF-8 content, as the terminal itself handles the encoding. Its primary utility now lies in situations where a specific non-UTF-8 encoding is required, or with older terminal emulators that lack full Unicode support.


title: TYPICAL USAGE
content:
<b><code>luit</code></b> is almost always used as a wrapper for another command. A common invocation is:<br><code><b>luit</b> <I>-l</I> <I>zh_CN.UTF-8</I> <b>--</b> <I>xterm</I></code><br>This command starts <b><code>xterm</code></b> with <b><code>luit</code></b> handling the character set conversion to and from UTF-8, assuming the locale is Chinese (Simplified, UTF-8). The <b><code>--</code></b> argument is crucial as it tells <b><code>luit</code></b> that all subsequent arguments are part of the command to be executed, not options for <b><code>luit</code></b> itself. This allows <b><code>luit</code></b> to manage the character encoding layer between your shell/applications and the terminal's display.


title: HISTORY
content:
<b><code>luit</code></b> was developed as part of the X.Org project to address a long-standing limitation of X terminals: their inability to handle multiple character sets beyond the default ISO-8859-1 or ASCII. Early <b><code>xterm</code></b> versions lacked native support for complex encodings like Japanese, Chinese, or Korean. <b><code>luit</code></b> filled this gap by acting as a transparent proxy, converting character streams between the application's locale encoding and the terminal's native encoding. This allowed users to display and input characters from various languages in <b><code>xterm</code></b> environments that otherwise wouldn't support them. Its development was crucial for internationalization within the X Window System.


title: PARAMETERS
content:
<b><b>&lt;DEVICE&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block device to be formatted (e.g., <i>/dev/sdb1</i>). <B>Warning:</B> All data on this device will be erased.<br><br><b><b>-y</b>, <b>--verify-passphrase</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts the user to enter the passphrase twice to verify correctness.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output messages, useful for scripting.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, providing more details about the operation.<br><br><b><b>-d</b>, <b>--key-file</b> &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the passphrase from the specified file instead of prompting interactively.<br><br><b><b>--type</b> &lt;type&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the LUKS header type, either <i>luks1</i> or <i>luks2</i>. Default is <i>luks2</i> for modern systems.<br><br><b><b>--cipher</b> &lt;cipher_spec&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the encryption cipher and mode (e.g., <i>aes-xts-plain64</i>). Default varies by system and LUKS version.<br><br><b><b>--hash</b> &lt;hash_alg&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the password hashing algorithm (e.g., <i>sha256</i>, <i>sha512</i>). Used for PBKDF.<br><br><b><b>--iter-time</b> &lt;milliseconds&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the desired time for PBKDF (Password-Based Key Derivation Function) computations. Higher values increase passphrase security but take longer to process.<br><br><b><b>--pbkdf</b> &lt;alg&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the PBKDF algorithm to use (e.g., <i>pbkdf2</i>, <i>argon2id</i>). <i>argon2id</i> is the default for LUKS2 and recommended for security.<br><br><b><b>--uuid</b> &lt;UUID&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a specific UUID to the LUKS volume.<br><br><b><b>--label</b> &lt;label&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a textual label to the LUKS volume (LUKS2 only).<br><br>


title: DESCRIPTION
content:
<i>luksformat</i> is not a standalone Linux command but refers to the process of initializing a block device for <B>LUKS (Linux Unified Key Setup)</B> encryption. This critical operation is primarily performed by the <B>cryptsetup</B> utility, specifically using the <i>cryptsetup luksFormat</i> subcommand.<br><br>The process sets up the LUKS header on the specified device, which includes essential metadata for managing encrypted data. It securely stores a master key, along with configurable key slots for user passphrases or key files. Each key slot holds an encrypted version of the master key, allowing multiple methods to unlock the volume.<br><br>Formatting with LUKS is a <B>destructive operation</B>; it overwrites all existing data on the device and cannot be undone. It is the fundamental first step before an encrypted volume can be opened (<i>cryptsetup luksOpen</i>), a filesystem created on it (e.g., <i>mkfs.ext4</i>), and data stored securely.


title: CAVEATS
content:
<b><i>luksformat</i> is not a standalone command:</b> The actual tool for LUKS formatting is <i>cryptsetup luksFormat</i>. Rely on <i>cryptsetup</i> documentation for the most accurate and up-to-date information.<br><br><b>Data Loss:</b> This operation is irreversibly destructive. Ensure you have selected the correct device, as formatting the wrong device will result in permanent data loss.<br><br><b>Passphrase Security:</b> A strong, unique passphrase or a secure key file is paramount for the security of your encrypted data. Weak passphrases can be brute-forced.<br><br><b>PBKDF Iteration Time:</b> The <i>--iter-time</i> parameter directly impacts security. A longer iteration time makes brute-forcing passphrases more difficult. It's crucial to balance security with acceptable unlock times.<br><br><b>Header Backup:</b> Consider backing up the LUKS header (<i>cryptsetup luksHeaderBackup</i>) for disaster recovery, as a corrupted header can render data irrecoverable.


title: LUKS HEADER
content:
The LUKS header is stored at the beginning of the encrypted device and contains all critical metadata, including encryption parameters (cipher, mode, key size), key slots information, and checksums. Its integrity is vital; if the header is corrupted or lost without a backup, the data on the device becomes irrecoverable.


title: KEY SLOTS
content:
LUKS supports multiple key slots (up to 8 in LUKS1, more flexible in LUKS2), allowing different passphrases or key files to unlock the same volume. Each slot contains a uniquely encrypted copy of the master key. This allows for scenarios like having both a passphrase and a key file, or multiple users with their own passphrases.


title: PBKDF (PASSWORD-BASED KEY DERIVATION FUNCTION)
content:
LUKS utilizes PBKDFs (like PBKDF2 or Argon2id) to derive the actual encryption key from a user's passphrase. These functions are intentionally computationally intensive (requiring significant time and/or memory) to thwart brute-force attacks against the passphrase. <B>Argon2id</B> (default for LUKS2) is generally recommended over PBKDF2 for its superior resistance against both GPU-based and custom hardware attacks due to its memory-hardness.


title: HISTORY
content:
The <B>LUKS (Linux Unified Key Setup)</B> specification was created by Clemens Fruhwirth in 2004, providing a standard, platform-independent on-disk format for encrypted volumes. The <B>cryptsetup</B> utility was developed as the primary tool to implement this specification, effectively superseding older, non-standardized disk encryption methods that lacked a consistent header.<br><br>The <i>luksFormat</i> subcommand has been a core component of <B>cryptsetup</B> since its early versions, tasked with initializing LUKS volumes. Over time, LUKS evolved from LUKS1 to LUKS2, introducing significant improvements such as the Argon2id PBKDF, flexible key slots, and enhanced metadata storage. <B>cryptsetup</B> continuously adapted to support these advancements. While <i>luksformat</i> itself is not a distinct binary, the conceptual action it represents has been fundamental to disk encryption on Linux since LUKS's inception, consistently performed by the <i>cryptsetup luksFormat</i> command.


title: SEE ALSO
content:
cryptsetup(8), cryptsetup-luksOpen(8), cryptsetup-luksClose(8), cryptsetup-luksAddKey(8), cryptsetup-luksRemoveKey(8), mkfs(8), mount(8)


title: SYNOPSIS
content:
<I>lvchange</I> [OPTIONS] <I>LogicalVolumePath</I> [ <I>LogicalVolumePath</I>... ]<br><br><I>lvchange</I> [OPTIONS] <I>VolumeGroupName</I>/<I>LogicalVolumeName</I> [ <I>VolumeGroupName</I>/<I>LogicalVolumeName</I>... ]


title: PARAMETERS
content:
<b><b>-a</b>, <b>--activate</b> {y|n|l|L|r|R}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the activation state of the logical volume. 'y' (default) activates, 'n' deactivates, 'l' activates locally, 'L' activates on a specific host, 'r' activates in read-only mode, 'R' activates read-only locally.<br><br><b><b>-p</b>, <b>--permission</b> {r|rw}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the logical volume's permission to read-only ('r') or read-write ('rw').<br><br><b><b>-r</b>, <b>--readahead</b> {<sectors>|Auto}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the read-ahead sector count for the logical volume. 'Auto' uses the system default.<br><br><b><b>-s</b>, <b>--sync</b> {y|n}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls whether outdated mirrored/RAID images are synchronized. 'y' synchronizes, 'n' disables.<br><br><b><b>-C</b>, <b>--contiguous</b> {y|n}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets or clears the contiguous allocation policy. 'y' requires contiguous physical extents, 'n' allows non-contiguous. (Less commonly used for existing LVs).<br><br><b><b>--cachemode</b> {writethrough|writeback}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the cache mode for a cache logical volume.<br><br><b><b>--cachepolicy</b> <PolicyName></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the cache policy for a cache logical volume.<br><br><b><b>--metadatasignature</b> {y|n}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables the metadata signature for the LV.<br><br><b><b>-K</b>, <b>--setactivationskip</b> {y|n}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets or clears the activation skip flag for the logical volume. If set, the LV will not be activated during boot.<br><br><b><b>-k</b>, <b>--cleansnapshot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the snapshot's invalid original volume, typically used after an unexpected shutdown.<br><br><b><b>--addtag</b> <Tag></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a tag to the logical volume for organizational purposes.<br><br><b><b>--deltag</b> <Tag></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a tag from the logical volume.<br><br><b><b>--refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refreshes the kernel's device mapper table for the logical volume, useful after certain metadata changes.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays verbose runtime information, showing more details about the command's execution.<br><br><b><b>-y</b>, <b>--yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assumes 'yes' to all questions; useful for scripting and non-interactive operations.<br><br><b><b>-n</b>, <b>--noudevsync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables udev synchronization. Use with extreme caution as it can lead to inconsistent device states.<br><br>


title: DESCRIPTION
content:
The <I>lvchange</I> command is a crucial utility within the Logical Volume Manager (LVM) framework in Linux, designed to modify the attributes of existing logical volumes (LVs) without altering their size. Unlike commands like <I>lvextend</I> or <I>lvreduce</I>, which resize logical volumes, <I>lvchange</I> focuses on metadata and operational parameters. <br><br>Common uses include activating or deactivating logical volumes (making them available or unavailable to the system), setting read/write permissions, adjusting read-ahead settings, managing cache modes for cached LVs, setting data synchronization parameters for RAID or mirrored LVs, or modifying various other flags. It can be applied to individual logical volumes or to all logical volumes within a specified volume group or on the system. Proper use of <I>lvchange</I> is essential for managing the operational state and performance characteristics of LVM-based storage.


title: CAVEATS
content:
Changing activation state for a logical volume that contains a mounted filesystem can lead to data corruption or system instability. Always unmount filesystems before deactivating LVs. <br><br>Using <b>-n</b> (<b>--noudevsync</b>) can be dangerous as it bypasses udev notifications, potentially leading to inconsistent device states if not handled carefully. <br><br>Modifying attributes like <I>readahead</I> might not immediately reflect changes for mounted filesystems without remounting or refreshing the kernel's device mapper table.


title: ACTIVATION STATES
content:
The activation options (<b>-a</b>) are critical for controlling access to LVM logical volumes. 'y' typically activates on all nodes in a cluster (if LVM is configured for clustering), while 'l' activates only locally. 'r' provides read-only access, which is useful for data recovery or consistency checks without risking writes.


title: PERMISSIONS AND OWNERSHIP
content:
<I>lvchange</I> requires root privileges to execute, as it modifies fundamental storage configurations. Misconfigurations can lead to data inaccessibility or system boot failures, emphasizing the need for careful use.


title: HISTORY
content:
The <I>lvchange</I> command is an integral part of the Logical Volume Manager (LVM) framework, which was first introduced in Linux 2.4 kernels to provide flexible disk management capabilities. As LVM evolved, <I>lvchange</I> gained functionalities to support new features such as snapshots, mirroring (RAID LVs), thin provisioning, and caching. Its role has remained consistent: to manage the operational attributes and state of logical volumes, adapting to new storage technologies and management paradigms within the LVM ecosystem.


title: SEE ALSO
content:
<I>lvm</I>(8), <I>lvcreate</I>(8), <I>lvdisplay</I>(8), <I>lvremove</I>(8), <I>lvextend</I>(8), <I>lvreduce</I>(8), <I>vgchange</I>(8), <I>pvchange</I>(8)


title: SYNOPSIS
content:
<b>lvconvert</b> [<i>OPTIONS</i>] <i>LogicalVolume[Path]</i><br><br><i>Common usages:</i><br><b>lvconvert --type mirror -m &lt;N&gt;</b> <i>LogicalVolumePath</i><br><b>lvconvert --type snapshot -s -n &lt;SnapshotName&gt;</b> <i>OriginLogicalVolumePath</i><br><b>lvconvert --merge</b> <i>SnapshotLogicalVolumePath</i><br><b>lvconvert --type cache --cachepool &lt;CachePoolName&gt;</b> <i>LogicalVolumePath</i><br><b>lvconvert --repair</b> <i>LogicalVolumePath</i>


title: PARAMETERS
content:
<b><b>--alloc</b> <i>&lt;Policy&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the allocation policy (e.g., <i>contiguous</i>, <i>anywhere</i>, <i>cluster</i>) for allocating physical extents.<br><br><b><b>--cachepool</b> <i>&lt;LV_path|LV_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an existing cache pool logical volume to convert an LV into a cached volume.<br><br><b><b>--discards</b> <i>{discard|nopassdown}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control discard behavior for thin pools, either passing discards down to the underlying physical volume or not.<br><br><b><b>-m</b> <i>&lt;N&gt;</i>, <b>--mirrors</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert to a mirrored LV with N additional mirror images. Setting <i>N=0</i> removes all mirrors.<br><br><b><b>--merge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Merge a snapshot logical volume back into its origin. The snapshot LV is removed after a successful merge.<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;Specify the name for a new logical volume, typically used when creating a snapshot.<br><br><b><b>-s</b>, <b>--snapshot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new snapshot of the specified origin logical volume.<br><br><b><b>--splitmirrors</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Split off N images of a mirrored LV to create a new, independent logical volume.<br><br><b><b>--repair</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Repair a mirrored or RAID logical volume that has detected failures (e.g., missing physical volumes).<br><br><b><b>--thinpool</b> <i>&lt;LV_path|LV_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an existing thin pool logical volume for thin LV conversion or management.<br><br><b><b>--type</b> <i>{mirror|snapshot|cache|thin|raidN}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target logical volume type for the conversion (e.g., to create a mirror, snapshot, or cache LV).<br><br><b><b>--yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'yes' to all questions; bypasses interactive confirmation prompts.<br><br>


title: DESCRIPTION
content:
lvconvert is a crucial utility within the Logical Volume Manager (LVM) framework, designed to alter the characteristics or layout of existing logical volumes (LVs). It empowers system administrators to transform an LV's structure without necessarily affecting its underlying data. Common operations include converting a standard logical volume into a mirrored volume, enabling high availability, or removing mirrors to reclaim physical extents. It's also extensively used for managing snapshots: creating new point-in-time copies of LVs for backup or testing, and subsequently merging these snapshots back into their origin volumes. Furthermore, lvconvert facilitates the integration of caching layers to improve performance, and the management of thin provisioning, allowing for flexible storage allocation. Its versatility makes it indispensable for adapting storage configurations to evolving requirements, ensuring data integrity and optimizing performance within LVM-managed environments.


title: CAVEATS
content:
Requires sufficient free physical extents in the volume group for operations like adding mirrors or creating snapshots.<br>Merging snapshots (<b>--merge</b>) can be a lengthy process and may temporarily degrade performance; ensure sufficient system resources.<br>Incorrect use of <b>lvconvert</b> (e.g., merging the wrong snapshot) can lead to data loss or corruption. Always back up critical data before major LVM operations.<br>Operations like adding mirrors or converting to cached LVs consume physical storage space.<br>Repairing mirrored/RAID LVs requires the faulty physical volumes to be addressed or replaced.


