# CommandSection

title: DESCRIPTION
content:
The <I>tc-sfb</I> command configures the Stochastic Fair Blue (SFB) queuing discipline, an advanced Active Queue Management (AQM) mechanism for Linux Traffic Control. SFB is designed to prevent network congestion by proactively dropping or marking packets before queues become full. Unlike simpler mechanisms that treat all traffic uniformly, SFB maintains multiple internal 'cells' or 'bins' organized within a hash table. Each cell monitors the queueing behavior of a subset of network flows. When congestion is detected within a specific cell (i.e., its queue depth or rate exceeds a threshold), SFB probabilistically drops or marks packets belonging to flows mapped to that cell. This per-cell monitoring helps in isolating the impact of congested or misbehaving flows, preventing them from negatively affecting other, well-behaved flows. It is a more sophisticated variant of Random Early Detection (RED) and incorporates concepts from the Blue algorithm, aiming for improved fairness and responsiveness to network congestion.


title: CAVEATS
content:
<I>tc-sfb</I> is considered a more experimental queuing discipline compared to widely adopted ones like FQ-CoDel or HTB. Its effectiveness heavily depends on proper tuning of its numerous parameters, which can be complex and network-specific. While designed for fairness and congestion avoidance, it might introduce higher CPU overhead due to its per-cell state management and hashing operations, especially on systems handling a very large number of concurrent flows. It is primarily suitable for active queue management (AQM) and congestion prevention rather than strict bandwidth guarantees or hard prioritization.


title: HOW SFB ACHIEVES FAIRNESS
content:
SFB uses a hash function to map incoming packets to one of many internal 'cells' or 'bins' (determined by the <B>scell_log</B> parameter). Each cell effectively manages a small sub-queue and maintains its own state (e.g., queue depth, token bucket usage). By monitoring and reacting to congestion at the granularity of these cells, SFB can identify and penalize flows (or groups of flows) that are contributing disproportionately to congestion without affecting other, well-behaved flows that map to different cells. This isolation is key to its fairness properties and its ability to prevent a single 'rogue' flow from monopolizing bandwidth.


title: CONGESTION DETECTION AND PACKET MARKING/DROPPING
content:
For each cell, SFB tracks its current queue depth and the rate of traffic passing through it using token buckets. When a cell's queue depth exceeds its configured threshold (<B>max_depth</B>) or its rate indicates congestion, SFB calculates a dropping probability based on the severity of congestion and its configured <B>p_log</B> and <B>e_log</B> parameters. Packets are then probabilistically dropped or, if supported, marked with Explicit Congestion Notification (ECN) to signal congestion to endpoints. This allows endpoints to proactively reduce their transmission rate, helping to mitigate congestion before it leads to severe packet loss.


title: HISTORY
content:
Stochastic Fair Blue (SFB) emerged as an advanced queuing discipline aiming to overcome limitations of earlier active queue management (AQM) algorithms like Random Early Detection (RED). While RED improved upon simple tail-drop by proactively dropping packets, it struggled with fairness among different flows and could be sensitive to bursty traffic. SFB incorporates concepts from the 'Blue' algorithm, which dynamically adjusts congestion thresholds, and introduces a stochastic element via hashing to map flows to distinct queue 'cells'. This design allows for more granular congestion control, isolating misbehaving flows and enhancing fairness, making it a notable evolution in network queue management strategies.


title: SYNOPSIS
content:
<b>tc qdisc [ add | change | replace ] dev <I>DEV</I> root | parent <I>CLASSID</I> sfq [ limit <I>PACKETS</I> ] [ flows <I>NUMBER</I> ] [ depth <I>PACKETS</I> ] [ quantum <I>BYTES</I> ] [ perturb_period <I>SECONDS</I> ] [ divisor <I>NUMBER</I> ]<br>tc qdisc show dev <I>DEV</I></b>


title: PARAMETERS
content:
<b>limit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Maximum number of packets the qdisc can hold in total. Default is 128.</i><br><br><b>flows</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Maximum number of flows to hash to. This parameter is deprecated; use 'divisor' instead. Default is 128.</i><br><br><b>depth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Maximum number of packets a single sub-queue (hash bucket) can hold. Default is 128.</i><br><br><b>quantum</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Number of bytes a flow is allowed to send before SFQ moves to the next flow. Default is 1514 bytes (one Ethernet MTU). This value should be at least the interface's MTU.</i><br><br><b>perturb_period (or perturb)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Interval in seconds after which the hashing algorithm is re-seeded to redistribute flows and mitigate hash collisions. A value of 0 disables this feature. Default is 10 seconds.</i><br><br><b>divisor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The number of hash buckets available for flows. A larger number (preferably an integer power of two) reduces the chance of hash collisions. Default is 1024; maximum is 65536.</i><br><br>


title: DESCRIPTION
content:
<i>tc-sfq</i> implements the <I>Stochastic Fairness Queueing</I> (SFQ) queue discipline. It is designed to ensure that each active network flow receives a fair share of the available bandwidth, preventing any single flow from monopolizing the outgoing link. SFQ achieves this by classifying packets into a large number of independent sub-queues based on a hash of their header fields (e.g., source/destination IP addresses, port numbers, protocol). When the device is ready to send a packet, it round-robins through these sub-queues, sending one packet from each. This approach mimics true fair queueing without the high computational overhead, hence "stochastic." To mitigate the problem of hash collisions (where different flows map to the same sub-queue), SFQ periodically perturbs its hashing algorithm, causing flows to be re-assigned to different sub-queues. While SFQ excels at fairness, it does not provide any prioritization capabilities. It is a simple yet effective qdisc for general-purpose traffic shaping where overall fairness is desired over specific QoS guarantees.


title: CAVEATS
content:
SFQ provides excellent fairness but <B>does not support prioritization</B> of specific types of traffic. All flows are treated equally. Hash collisions, although mitigated by the <I>perturb_period</I> mechanism, can still temporarily cause unfairness if a large number of flows collide into the same bucket. SFQ is also <B>not suitable for single-flow scenarios</B> where the primary goal is strict rate limiting or complex QoS, as it is designed for distributing bandwidth among multiple competing flows.


title: FLOW IDENTIFICATION
content:
SFQ identifies "flows" by hashing various fields from the packet header, typically including source and destination IP addresses, TCP/UDP port numbers, and the protocol type. This means that, for example, a single TCP connection would be considered one flow.


title: SUB-QUEUES
content:
SFQ maintains a set of internal sub-queues (also known as hash buckets). When a packet arrives, its flow is determined, and the packet is enqueued into the corresponding sub-queue. The scheduler then cycles through these sub-queues in a round-robin fashion, sending one packet from each active sub-queue in turn. This mechanism ensures that no single flow can monopolize the queue.


title: HISTORY
content:
The Stochastic Fairness Queueing (SFQ) algorithm was proposed by Sally Floyd and Van Jacobson in 1993, building upon earlier fair queueing concepts. It was designed to provide a practical and efficient approximation of true fair queueing, which can be computationally intensive. SFQ was one of the early fair queueing disciplines integrated into the Linux kernel's traffic control framework, providing a robust solution for ensuring network fairness in environments where multiple flows compete for limited bandwidth without requiring complex configuration.


title: SEE ALSO
content:
tc(8): <i>Linux traffic control utility.</i>, tc-qdisc(8): <i>General information about traffic control queueing disciplines.</i>, tc-fq_codel(8): <i>Fair Queueing Controlled Delay. A more modern fair queueing algorithm.</i>, tc-htb(8): <i>Hierarchical Token Bucket. For hierarchical bandwidth allocation and prioritization.</i>, tc-prio(8): <i>Priority queueing.</i>


title: SYNOPSIS
content:
tc qdisc add dev <I>DEV</I> root | parent <I>QDISC_HANDLE</I> [ handle <I>QDISC_HANDLE</I> ] <I>QDISC_KIND</I> [ <I>OPTIONS</I> ] <br>    <b>stab</b> [ <b>overhead</b> <I>BYTES</I> ] [ <b>mpu</b> <I>BYTES</I> ] [ <b>rtab</b> <I>FILE</I> ] [ <b>ttab</b> <I>FILE</I> ]


title: PARAMETERS
content:
<b><b>overhead</b> <I>BYTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an amount in <I>BYTES</I> to be added to the reported size of each packet. This is typically used to account for Layer 2 protocol headers (e.g., Ethernet header, VLAN tags) or other encapsulations that contribute to the actual on-wire packet size but are not included in the IP layer size reported by the kernel.<br><br><b><b>mpu</b> <I>BYTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the Minimum Packet Unit. If a packet's size, after <B>overhead</B> has been added, is less than <I>BYTES</I>, its size is effectively treated as <I>BYTES</I>. This option helps in accurately accounting for network media's minimum frame sizes, such as the 64-byte minimum for Ethernet.<br><br><b><b>rtab</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Designates a file that contains the size table entries for received (incoming) packets. Each line in the file should consist of two space-separated numbers: a size threshold and the corresponding <I>classid</I>. Packets are assigned the <I>classid</I> of the first entry whose size threshold is greater than or equal to the packet's effective size.<br><br><b><b>ttab</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <B>rtab</B>, but specifies the size table entries for transmitted (outgoing) packets. This allows for different size-based classifications for ingress and egress traffic flows.<br><br>


title: DESCRIPTION
content:
The <B>tc-stab</B> functionality, described by this man page, allows for attaching a 'size table' (<B>stab</B>) to a queuing discipline (<B>qdisc</B>) configured with the <B>tc</B> (traffic control) command. This feature enables flexible packet classification based on their size, potentially adjusted by overhead and minimum packet unit settings. The size table can be defined to map specific packet size ranges to distinct <I>classids</I>, which can then be utilized by <B>tc</B> filters (such as <B>u32</B> filters) to apply different traffic management rules. This is particularly useful for implementing differentiated services based on packet sizes, for instance, prioritizing small interactive packets over larger bulk data transfers.


title: CAVEATS
content:
The availability and functionality of the <B>stab</B> feature depend on kernel support and the specific <B>qdisc</B> being used. Not all <B>qdisc</B>s may fully utilize or support the <B>stab</B> data internally. While it primarily provides packet size information to <B>tc</B> filters (like <B>u32</B>) for classification, some <B>qdisc</B>s (e.g., <B>fq_codel</B>) might use this information directly for their internal logic.


title: SIZE TABLE FILE FORMAT
content:
The files specified by <B>rtab</B> and <B>ttab</B> should contain entries in a simple format, with each line specifying a size threshold and a corresponding <I>classid</I>. For example:<br>0 1:1<br>500 1:2<br>1500 1:3<br>In this example, a packet with an effective size from 0 up to 499 bytes would be assigned <I>classid</I> 1:1. A packet from 500 up to 1499 bytes would get <I>classid</I> 1:2, and packets 1500 bytes and larger would receive <I>classid</I> 1:3.


title: EXAMPLE USAGE
content:
To add <B>stab</B> data to an <B>htb</B> <B>qdisc</B> on device <B>eth0</B> with an overhead of 14 bytes and a minimum packet unit of 64 bytes, you would use a command similar to:<br>tc qdisc add dev eth0 root handle 1: htb stab overhead 14 mpu 64<br>This configures the <B>qdisc</B> to use the specified <B>stab</B> parameters for its packet size calculations.


title: HISTORY
content:
The <B>stab</B> functionality is an integral part of the <B>iproute2</B> suite's <B>tc</B> (traffic control) tools for Linux. It has evolved alongside the capabilities of the Linux kernel's networking stack, providing more granular control over traffic shaping and classification. Its development aligns with the ongoing efforts to enhance network performance and quality of service through sophisticated packet management.


title: SYNOPSIS
content:
<b>tc qdisc add dev</b> <i>DEV</i> <b>root | parent</b> <i>CLASSID</i> <b>[ handle</b> <i>MINOR</i><b>:] tbf [ rate</b> <i>RATE</i> <b>] [ burst</b> <i>BYTES</i> <b>] [ peakrate</b> <i>RATE</i> <b>] [ mtu</b> <i>BYTES</i> <b>] [ minburst</b> <i>BYTES</i> <b>] [ latency</b> <i>TIME</i> <b>] [ limit</b> <i>PACKETS</i> <b>|</b> <i>BYTES</i> <b>] [ overhead</b> <i>BYTES</i> <b>] [ linklayer</b> <i>TYPE</i> <b>] [ avpkt</b> <i>BYTES</i> <b>] [ action</b> <i>ACTION</i> <b>]</b>


title: PARAMETERS
content:
<b><b>dev</b> <i>DEV</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network device (e.g., <i>eth0</i>) to which the TBF qdisc should be attached.<br><br><b><b>root</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches the TBF qdisc as the root (main) qdisc for the device.<br><br><b><b>parent</b> <i>CLASSID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches the TBF qdisc to an existing class (e.g., <i>1:1</i>) of another qdisc (like HTB or PRIO).<br><br><b><b>handle</b> <i>MINOR</i><b>:</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a handle (identifier) to the TBF qdisc, which can be used to refer to it later (e.g., <i>1:</i> or <i>20:</i>).<br><br><b><b>rate</b> <i>RATE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The committed rate at which tokens are generated, effectively the average speed of traffic shaping. Can be specified in bits/bytes per second (e.g., <i>1mbit</i>, <i>512kbit</i>, <i>10mbyte</i>).<br><br><b><b>burst</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum size of the token bucket, defining how much data can be sent in a single burst. Should be at least <i>mtu</i>. Also known as the 'buffer' or 'maxburst'.<br><br><b><b>peakrate</b> <i>RATE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional secondary rate at which tokens can be generated if the bucket is not full, allowing for bursts above the committed <b>rate</b> up to this peak limit. This is controlled by a second internal TBF instance.<br><br><b><b>mtu</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum transfer unit, or the largest packet size that TBF will account for in its calculations. This value should be consistent with the actual network MTU. Can be specified as <i>minburst</i>.<br><br><b><b>minburst</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A variant of <b>burst</b>. The minimum amount of bytes to keep in the bucket. Helps avoid 'starvation' in low-rate scenarios. Typically set to a value around the device's actual MTU.<br><br><b><b>latency</b> <i>TIME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum amount of time a packet can be held in the TBF queue before it is dropped. Specifies the maximum delay a packet can experience due to insufficient tokens (e.g., <i>50ms</i>, <i>1s</i>).<br><br><b><b>limit</b> <i>PACKETS</i> <b>|</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum number of bytes or packets that can be queued within the TBF instance before packets are dropped. If exceeded, new packets are dropped. This prevents excessive memory usage or unbounded delays.<br><br><b><b>overhead</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An amount of bytes to add to each packet's actual size for accounting, useful for compensating for layer 2 or other protocol overheads not included in the IP packet size.<br><br><b><b>linklayer</b> <i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the link layer type for more accurate accounting. Options include <i>ethernet</i>, <i>atm</i>, <i>adsl</i>, or <i>none</i>. Defaults to <i>ethernet</i> if not specified.<br><br><b><b>avpkt</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Average packet size. Used internally for calculations when <b>overhead</b> or <b>linklayer</b> is specified. Not typically set by the user directly unless very precise tuning is required.<br><br><b><b>action</b> <i>ACTION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an action to be performed on packets matching certain criteria. Actions can modify, drop, or redirect packets.<br><br>


title: DESCRIPTION
content:
The <b>tc-tbf</b> command is part of the Linux <b>traffic control</b> (<b>tc</b>) utility, implementing the <b>Token Bucket Filter</b> (TBF) queuing discipline. It's used for precisely shaping outbound network traffic by controlling the rate at which data is sent.<br><br>The TBF works on the principle of a 'bucket' filled with 'tokens' at a steady rate. Each byte of data transmitted consumes a token. If there are tokens available, the packet is sent immediately. If the bucket is empty, the packet is held until enough tokens accumulate. If tokens arrive faster than they can be consumed, the bucket fills up to a specified maximum capacity (burst size). Any further tokens generated are discarded until space becomes available.<br><br>This mechanism ensures that traffic never exceeds the configured rate (<b>rate</b>), while allowing for short bursts of data (<b>burst</b>) up to a certain limit, preventing abrupt drops and making the traffic flow smoother. It's particularly useful for rate-limiting applications, VPN tunnels, or ensuring fair bandwidth allocation.


title: CAVEATS
content:
The <b>TBF</b> qdisc is designed for traffic shaping (delaying packets to meet a rate), not strictly for dropping excess traffic instantly. If <b>latency</b> or <b>limit</b> parameters are not set appropriately, packets might be delayed indefinitely or dropped unexpectedly. Careful tuning of <b>rate</b>, <b>burst</b>, and <b>latency</b> is crucial for optimal performance. While <b>peakrate</b> allows for temporary bursts, it introduces a second bucket and can complicate tuning if not fully understood.


title: WORKING PRINCIPLE OF TOKEN BUCKET FILTER
content:
The TBF operates with two key components: a 'bucket' of a specific size and a 'token generator'. Tokens are continuously added to the bucket at a defined <b>rate</b>. Each byte of data requires one token to be transmitted. If a packet arrives and there are enough tokens in the bucket, the tokens are consumed, and the packet is transmitted immediately. If the bucket is empty, the packet is queued, waiting for tokens to accumulate. If the bucket becomes full, newly generated tokens are discarded. This ensures that the long-term average transmission rate never exceeds the specified <b>rate</b>, while the <b>burst</b> parameter allows for temporary peaks in traffic, absorbing variations in data arrival.


title: HISTORY
content:
The Token Bucket Filter concept has been a cornerstone of network traffic management and quality of service (QoS) for decades, predating its inclusion in Linux. Within the Linux kernel's <b>traffic control</b> (<b>tc</b>) framework, <b>TBF</b> was one of the earliest and most fundamental queueing disciplines implemented, providing a robust and widely understood mechanism for rate limiting. Its development has focused on refinement and integration with other <b>tc</b> components, remaining a core tool for shaping traffic on network interfaces.


title: PARAMETERS
content:
<b><I>script-file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to a Tcl script file to execute. If this argument is omitted, <b>tclsh</b> enters interactive mode, prompting for commands.<br><br><b><I>arg</I> ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional arguments passed to the Tcl script when executed. These arguments are accessible within the script via the global Tcl variables <I>argv</I> (a list of arguments) and <I>argc</I> (the count of arguments).<br><br><b>-encoding <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character encoding used for reading the <I>script-file</I>. For example, <I>-encoding utf-8</I> ensures the script is read using UTF-8 encoding.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces interpretation of the first non-option argument as a script file, even if it begins with a hyphen (<B>-</B>), preventing it from being treated as another option.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <b>tclsh</b> to run in interactive mode, even if a script file is provided on the command line. This can be useful for debugging a script interactively after it has run.<br><br><b>-norc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the loading of the user's Tcl resource file (typically <I>~/.tclshrc.tcl</I> or <I>~/.tclrc</I>) upon startup. This is useful for clean, default environments.<br><br><b>-rcfile <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative resource file to load instead of the default user resource file. The specified <I>file</I> must be a valid path to a Tcl script that will be sourced at startup.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Equivalent to <I>-i</I>. Forces <b>tclsh</b> to run in interactive mode.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the end of command-line options. All subsequent arguments are treated as the script file and its arguments, even if they begin with hyphens. This is useful for passing arguments that might otherwise be interpreted as options.<br><br>


title: DESCRIPTION
content:
<b>tclsh</b> is the standard interactive shell and script interpreter for the Tcl (Tool Command Language) scripting language. It provides a command-line interface where users can type Tcl commands and see the results immediately, or it can be used to execute Tcl scripts from a file. <b>tclsh</b> is primarily designed for console-based applications, system administration tasks, and scripting automation, lacking the graphical user interface capabilities found in its counterpart, <I>wish</I> (the Windowing Shell). It's a foundational component for developing Tcl-based applications and utilities, offering a robust environment for text processing, network scripting, and system interaction.


title: CAVEATS
content:
<b>tclsh</b> provides a console-only environment. It does not support graphical user interface (GUI) elements or windowing toolkits directly. For Tcl applications requiring a GUI, the <I>wish</I> (Windowing Shell) interpreter, which includes the Tk toolkit, must be used instead. Additionally, while Tcl is highly portable, script behavior can sometimes differ subtly across various operating systems or Tcl versions.


title: MODES OF OPERATION
content:
<b>tclsh</b> can operate in two primary modes:<br><br>1.  <B>Interactive Mode:</B> When invoked without a script file (or with <I>-i</I>/<I>-t</I>), <b>tclsh</b> presents a prompt (typically <I>%</I>) where users can type Tcl commands directly. Each command is executed upon pressing Enter, and the result is displayed. This mode is excellent for testing commands, learning Tcl, and quick one-off tasks.<br><br>2.  <B>Script Mode:</B> When invoked with a script file path, <b>tclsh</b> reads and executes the commands from the specified file. The shell typically exits after the script finishes execution, unless explicitly instructed to remain open or an error occurs. This mode is used for running full-fledged Tcl programs and automation scripts.


title: STANDARD I/O AND EXIT STATUS
content:
<b>tclsh</b> interacts with the user and the system through standard input (<I>stdin</I>), standard output (<I>stdout</I>), and standard error (<I>stderr</I>). Commands like <I>puts</I> write to <I>stdout</I>, while error messages and debugging information are typically sent to <I>stderr</I>. In interactive mode, <I>stdin</I> is used to read user input. In script mode, <I>stdin</I> can be used by the script to read data, for example, via the <I>gets</I> command. Upon exiting, <b>tclsh</b> returns an exit status code to the operating system, indicating success (typically 0) or failure (non-zero).


title: HISTORY
content:
Tcl was created by John Ousterhout while he was a professor at the University of California, Berkeley, and was first released in 1988. It was designed to be easily embedded into applications, providing a powerful scripting language for command and control. <b>tclsh</b>, as the core Tcl interpreter, has been a fundamental part of the Tcl distribution since its inception, serving as the primary way to interact with and execute Tcl scripts from the command line, enabling a wide range of system administration and automation tasks.


title: SYNOPSIS
content:
<b>tcpd</b> <i>program</i> [<i>argument ...</i>]<br>While <b>tcpd</b> is a command, it is rarely executed directly by users. Its primary use is as an intermediary process, configured within network superserver configurations (like <b>inetd.conf</b> or <b>xinetd</b> service definitions), to wrap and protect actual service daemons.


title: PARAMETERS
content:
<b>program</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The full path to the actual network service daemon executable that <b>tcpd</b> will wrap and potentially execute.<br><br><b>[argument ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments that will be passed directly to the <i>program</i> once <b>tcpd</b> permits the connection and executes the service daemon.<br><br>


title: DESCRIPTION
content:
<b>tcpd</b> is a network service wrapper that enhances the security of services typically invoked by superservers like <b>inetd</b> or <b>xinetd</b>. When a service is configured to use <b>tcpd</b>, <b>tcpd</b> intercepts incoming connection requests. It then consults two access control files, <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i>, to determine whether the connection should be permitted or denied. If the connection is allowed, <b>tcpd</b> executes the actual service daemon; otherwise, it terminates the connection. All access attempts, whether granted or denied, are logged to the system's <b>syslog</b> facility. This centralized mechanism provides granular control over which hosts can access specific services and offers valuable auditing capabilities, making it an essential component for host-based access control.


title: CAVEATS
content:
<b>tcpd</b> relies entirely on its configuration files (<i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i>); misconfigurations can lead to unintended access or denial of service.<br>It only protects services explicitly configured to use it, typically those invoked by superservers like <b>inetd</b> or <b>xinetd</b>, and does not provide protection for standalone daemons.<br>While still valuable, modern Linux systems often use more comprehensive firewall solutions (e.g., <b>firewalld</b>, <b>nftables</b>) for network-wide access control, complementing or sometimes superseding TCP Wrappers for primary filtering.


title: CONFIGURATION FILES (HOSTS.ALLOW AND HOSTS.DENY)
content:
The behavior of <b>tcpd</b> is governed by two files: <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i>. These files contain rules in the format <code>daemon_list : client_list [ : option ]</code>. <b>tcpd</b> first checks <i>hosts.allow</i>; if a match is found, access is granted. If no match is found, it then checks <i>hosts.deny</i>; if a match is found, access is denied. If no match is found in either file, access is typically granted by default, though this can vary by system configuration.<br>The <code>daemon_list</code> specifies which services the rule applies to, and <code>client_list</code> specifies which hosts or networks are affected.


title: LOGGING BEHAVIOR
content:
A key feature of <b>tcpd</b> is its comprehensive logging. Every connection attempt, whether permitted or denied, is logged via the <b>syslog</b> facility, usually to the <code>auth.info</code> or <code>daemon.info</code> log level. This provides administrators with an auditable trail of who attempted to access services, from where, and whether the attempt was successful, which is invaluable for security monitoring and incident response.


title: HISTORY
content:
<b>tcpd</b>, also known as TCP Wrappers, was developed by Wietse Venema in the early 1990s as a robust and flexible host-based access control system for network services. It rapidly gained widespread adoption across Unix-like operating systems due to its simplicity, effectiveness, and the ability to add a layer of security without modifying the service binaries themselves. It became a de-facto standard for enhancing the security of services, particularly in conjunction with the <b>inetd</b> superserver, and played a significant role in early internet security practices before the proliferation of dedicated firewall technologies.


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show rules that would always be matched by the <i>ALLOW</i> section of <i>hosts.allow</i>, effectively ignoring subsequent rules.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the <i>hosts.allow</i> and <i>hosts.deny</i> files found in the current directory instead of the default <i>/etc/</i> location.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show rules that would always be matched by the <i>DENY</i> section of <i>hosts.deny</i>, effectively ignoring subsequent rules.<br><br><b><b>-j</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate the old <i>tcp_wrappers</i> behavior where <i>hosts.allow</i> was checked before <i>hosts.deny</i>. The default behavior checks <i>hosts.deny</i> first.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not perform name lookups (e.g., DNS, NIS). This can speed up the check but will not detect issues related to hostname or netgroup resolution.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce verbose output, showing more details about the checks being performed and the rules being processed.<br><br>


title: DESCRIPTION
content:
<i>tcpdchk</i> is a utility included with the <i>tcp_wrappers</i> package. Its primary function is to analyze the <i>hosts.allow</i> and <i>hosts.deny</i> access control files to identify potential problems, inconsistencies, or vulnerabilities in their configuration.<br>It can detect issues such as syntax errors, unreachable rules, overlapping rules, or rules that could lead to unexpected access denials or grants. The tool reads the configuration files, simulates the access control logic, and reports any issues found, helping system administrators maintain secure and correct network service access policies. It is crucial for ensuring that <i>tcp_wrappers</i>-aware services behave as expected.


title: CAVEATS
content:
<i>tcpdchk</i> only checks the syntax and logic of <i>hosts.allow</i> and <i>hosts.deny</i>. It does not verify if <i>tcp_wrappers</i> is actually integrated with specific services (e.g., via <i>xinetd</i> or compiled into daemons).<br>It relies on the current system's DNS/NIS/NIS+ resolution for hostnames and netgroups unless the <b>-n</b> option is used. The <i>hosts.allow</i> and <i>hosts.deny</i> files are typically located in <i>/etc</i>, but this can be overridden with the <b>-d</b> option.<br>Note that <i>tcp_wrappers</i> is an older mechanism; many modern Linux systems prioritize kernel-level firewalls (like <i>iptables</i>, <i>nftables</i>, <i>firewalld</i>) for primary network access control.


title: CONFIGURATION FILES
content:
<i>tcpdchk</i> primarily interacts with the <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i> files. The <b>-d</b> option allows specifying alternative paths for these configuration files.


title: USAGE CONTEXT
content:
This command is typically employed by system administrators to audit and troubleshoot network access control rules for services that are configured to use <i>tcp_wrappers</i> for security.


title: HISTORY
content:
<i>tcpdchk</i> is an integral part of the <i>tcp_wrappers</i> package, originally developed by Wietse Venema in the early 1990s. <i>tcp_wrappers</i> was designed to add host-based access control to network services without requiring modifications to the service binaries.<br><i>tcpdchk</i> emerged as a vital diagnostic tool to assist administrators in debugging and verifying their <i>hosts.allow</i> and <i>hosts.deny</i> configurations, ensuring the correct application of security policies.<br>While still present in many Linux distributions, the direct use of <i>tcp_wrappers</i> for new services has somewhat diminished, largely due to the emergence of more comprehensive kernel-level firewalls and centralized network access control mechanisms.


title: PARAMETERS
content:
<b><i>service</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the network service to test (e.g., <i>sshd</i>, <i>vsftpd</i>). This name must match entries in <i>/etc/hosts.allow</i> or <i>/etc/hosts.deny</i>.<br><br><b><i>client</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The client hostname or IP address (e.g., <i>example.com</i>, <i>192.168.1.100</i>) to test access for.<br><br><b><i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing verbose output about how the rules are parsed and matched. This is useful for understanding the decision-making process.<br><br><b><i>-i infile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate configuration file to use instead of the default <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i>. This allows testing new rules before deploying them system-wide.<br><br><b><i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>tcpdmatch</i> to perform a reverse DNS lookup on the client IP address. By default, <i>tcpdmatch</i> might use the IP directly or rely on the system's name resolution configuration.<br><br>


title: DESCRIPTION
content:
<i>tcpdmatch</i> is a diagnostic tool used to test and debug access control rules configured for TCP Wrappers services. It simulates the behavior of the <i>tcpd</i> daemon (or applications linked with <i>libwrap</i>) by evaluating the rules defined in <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i> against a specified service and client combination. <br><br>This command does not actually connect to a service but rather processes the access control files, reporting whether access would be granted or denied based on the rules. It provides valuable insights into why a connection might be allowed or blocked, making it an essential utility for system administrators troubleshooting network service access issues controlled by TCP Wrappers. Its output clearly indicates which rule was matched, helping to pinpoint misconfigurations.


title: CAVEATS
content:
<i>tcpdmatch</i> only simulates the decision-making process of TCP Wrappers; it does not guarantee that the actual service will behave identically if other factors (like firewall rules or service-specific configurations) are at play. TCP Wrappers only protect services that have been compiled with support for <i>libwrap</i>. Many modern systems and services increasingly rely on other access control mechanisms (e.g., firewalls, Systemd socket activation rules, or application-level authentication) rather than TCP Wrappers, making its relevance less universal than in the past.


title: RULE EVALUATION ORDER
content:
When evaluating access, TCP Wrappers (and thus <i>tcpdmatch</i>) first checks the rules in <i>/etc/hosts.allow</i>. If a match is found that grants access, the process stops, and access is allowed. If no match is found in <i>hosts.allow</i>, then <i>/etc/hosts.deny</i> is checked. If a match is found in <i>hosts.deny</i>, access is denied. If no match is found in either file, access is implicitly granted (default-allow policy for services not explicitly denied).


title: COMMON USE CASES
content:
Beyond basic testing, <i>tcpdmatch</i> is invaluable for:<br> - Validating new or modified TCP Wrappers rules before deploying them to production.<br> - Troubleshooting 'access denied' errors reported by users or logs, by simulating the exact client/service combination.<br> - Understanding the precedence of rules when multiple entries might apply to a given host or service.


title: HISTORY
content:
<i>tcpdmatch</i> is part of the original TCP Wrappers package developed by Wietse Venema in the early 1990s. This suite of tools was designed to provide a simple, host-based access control mechanism for services typically launched by <i>inetd</i> or <i>xinetd</i>, or services compiled with <i>libwrap</i>. It quickly became a standard security feature on many Unix-like operating systems before the widespread adoption of more complex firewall solutions.


title: SYNOPSIS
content:
<b>tcpflow</b> [<I>options</I>] [<I>BPF_filter_expression</I>]<br><br>Examples:<br><b>tcpflow</b> -i eth0 -o /var/tmp/flow "port 80 and host example.com"<br><b>tcpflow</b> -r capture.pcap -F json "tcp and port 443"


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze connections further, e.g., decode HTTP streams where possible.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print flows to standard output instead of creating individual files.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debugging output, showing more internal information.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude specific connections based on criteria (e.g., exclude based on port or host).<br><br><b>-F <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for the flow data. Options include <i>raw</i>, <i>xml</i>, and <i>json</i>.<br><br><b>-i <interface></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the network interface to capture packets from (e.g., eth0, wlan0).<br><br><b>-J</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in JSON format. This is an alias for <i>-F json</i>.<br><br><b>-o <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output directory where the reassembled flow files will be saved.<br><br><b>-r <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read packets from a <i>pcap</i> file instead of capturing from a live interface.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Strip non-printable characters from the output, replacing them with dots or spaces.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, displaying more information about the capture process.<br><br><b>-X</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in XML format. This is an alias for <i>-F xml</i>.<br><br><b><I>BPF_filter_expression</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A Berkeley Packet Filter expression to filter the captured traffic (e.g., '<i>port 80</i>', '<i>host 192.168.1.1</i>').<br><br>


title: DESCRIPTION
content:
<b>tcpflow</b> is a powerful command-line utility for network analysis that captures TCP traffic and reassembles the data streams based on their TCP sequence numbers. Unlike tools like <b>tcpdump</b> which display raw packet headers and payloads, <b>tcpflow</b> reconstructs the entire conversation, writing each direction of a TCP connection to a separate file. For instance, an HTTP request and its corresponding response would be saved into distinct files, making it straightforward to analyze application-layer data.<br><br>This tool is invaluable for tasks such as network forensics, debugging client-server interactions, extracting files or content from network traffic, and monitoring specific protocol flows. It supports BPF (Berkeley Packet Filter) syntax for precise traffic filtering and can process either live network captures or existing <i>.pcap</i> files. Output can be raw binary, human-readable ASCII, or structured formats like XML and JSON for automated processing.


title: CAVEATS
content:
<b>Large Output Files:</b> Depending on traffic volume, <b>tcpflow</b> can generate a large number of files or very large single output files, potentially consuming significant disk space quickly.<br><b>Memory Usage:</b> Processing very high-volume traffic or large PCAP files can consume substantial system memory, especially when reassembling many concurrent streams.<br><b>Stateless Protocol Limitations:</b> <b>tcpflow</b> is specifically designed for TCP streams. It does not reassemble or process UDP or other stateless protocols.<br><b>Encrypted Traffic:</b> While it can capture encrypted traffic (e.g., HTTPS), it cannot decrypt it without external tools or prior SSL key extraction. The reassembled streams will contain encrypted data.


title: OUTPUT FILE NAMING CONVENTION
content:
<b>tcpflow</b> names its output files using a standard convention like <i>source_ip.source_port-destination_ip.destination_port</i>. Each direction of a conversation is saved separately, often with an appended sequence number if multiple flows occur between the same endpoints. This structured naming simplifies post-analysis and automation.


title: PRACTICAL USE CASES
content:
Commonly used for extracting files transferred over HTTP, analyzing email traffic (SMTP/POP3/IMAP), debugging custom application protocols, or identifying data exfiltration by reconstructing network conversations. It provides the actual application-layer data without needing to manually piece together packets.


title: INTEGRATION WITH OTHER TOOLS
content:
The ability to output in structured XML or JSON formats makes <b>tcpflow</b> highly integratable with scripting languages (Python, Perl) and other analysis tools for automated processing, data mining, and further analysis pipelines.


title: HISTORY
content:
<b>tcpflow</b> was originally developed by Jeremy Elson. Its development aimed to fill a gap between raw packet capture tools like <b>tcpdump</b> and full-fledged protocol analyzers, by providing an easy way to reconstruct and save the actual data exchanged over TCP connections. It has been maintained and improved over the years, incorporating features like structured output formats (XML, JSON) to facilitate automated analysis. While not as widely known as <b>tcpdump</b> or <b>Wireshark</b>, it remains a valuable specialized tool in the network analyst's toolkit due to its unique stream reassembly capabilities.


title: PARAMETERS
content:
<b>-i <interface></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the network <I>interface</I> for live packet capture (e.g., eth0, wlan0).</i><br><br><b>-r <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Read packets from a specified pcap-format dump <I>file</I> instead of live capture.</i><br><br><b>-C <size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the maximum capture <I>size</I> (in bytes) for each TCP stream before truncating.</i><br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display reassembled data in hexadecimal format (raw byte dump).</i><br><br><b>-d <mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the data display <I>mode</I>. Common modes include 'c' (client data), 's' (server data), 'b' (both), 'h' (hexadecimal, similar to -x).</i><br><br><b>-F <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Output the reassembled session data to a specified <I>file</I> rather than standard output.</i><br><br><b>-E <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Extract files (e.g., HTTP objects, FTP transfers) found within the TCP streams into the specified <I>directory</I>.</i><br><br><b>-A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Automatically detect and extract HTTP and FTP files found within sessions. This implies <B>-E</B> and uses a default directory if none is specified.</i><br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use absolute TCP sequence numbers in the output, which can be useful for debugging low-level TCP issues.</i><br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable verbose output, displaying more details about packet processing and session state.</i><br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display the help message and exit.</i><br><br>


title: DESCRIPTION
content:
<b>tcpick</b> is a command-line tool designed for tracking and reassembling TCP streams from live network traffic or from pre-recorded pcap files. Unlike simpler packet sniffers, <b>tcpick</b> focuses on reconstructing the entire conversation between two endpoints, displaying the data exchanged by client and server in a human-readable format. It can show TCP flags, sequence numbers, and even automatically extract files (like HTTP objects or FTP transfers) from the captured sessions, making it invaluable for network debugging, security analysis, and forensic investigations where understanding application-layer data flow is crucial. It leverages the <i>libpcap</i> library for packet capture and filtering.


title: CAVEATS
content:
<b>tcpick</b> requires root privileges or appropriate capabilities to capture packets live from network interfaces. <br>While effective for TCP stream reassembly, it is not as feature-rich or actively developed as general-purpose network analyzers like Wireshark/Tshark. <br>Reassembly can be incomplete if packets are lost or if the capture starts mid-session. <br>Performance can be an issue on high-traffic networks due to its in-memory reassembly.


title: FILTERING EXPRESSIONS
content:
<b>tcpick</b> supports the same powerful packet filtering syntax as <b>tcpdump</b>, based on the <i>libpcap</i> library. This allows users to narrow down the captured traffic to specific hosts, ports, protocols, or a combination (e.g., <I>host 192.168.1.1 and port 80</I> or <I>tcp port 22</I>). This is crucial for focusing analysis on relevant sessions.


title: LIVE VS. OFFLINE ANALYSIS
content:
The command can operate in two primary modes: <br>1. <b>Live Capture:</b> Using the <B>-i</B> option to monitor network traffic in real-time. <br>2. <b>Offline Analysis:</b> Using the <B>-r</B> option to process packets from a previously saved pcap <I>file</I>. This allows for retrospective analysis without affecting network performance.


title: HISTORY
content:
<b>tcpick</b> emerged as a specialized tool to complement basic packet capture utilities like <b>tcpdump</b>, focusing specifically on the complex task of TCP stream reassembly. Its development aimed to provide a deeper insight into the application-layer data exchanged within TCP sessions, which <b>tcpdump</b> did not natively offer in a user-friendly way. While its core functionality remains highly valuable for specific use cases, its active development might have slowed down compared to more comprehensive network analysis suites.


title: SYNOPSIS
content:
<b>tcpkill</b> [<i>-i interface</i>] [<i>-r file</i>] [<i>-a</i>] [<i>-l</i>] [<i>-v</i>] [<i>expression</i>]


title: PARAMETERS
content:
<b><i>-i &lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to listen on and inject packets from (e.g., eth0, wlan0).<br><br><b><i>-r &lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads packets from a <b>pcap</b>-compatible capture file instead of a live network interface. In this mode, no packets are injected.<br><br><b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Kills all connections matching the specified <i>expression</i>. By default, <b>tcpkill</b> only kills the first matching connection it finds and then exits.<br><br><b><i>-l</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits killing to connections where either the source or destination IP address is local to the machine running <b>tcpkill</b>. Requires a local subnet or IP to be part of the filter <i>expression</i>.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about connections being killed.<br><br><b><i>expression</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A <b>pcap</b>-filter expression (e.g., 'host 192.168.1.1 and port 80') used to select which TCP connections to target. If no expression is provided, <b>tcpkill</b> attempts to kill the first TCP connection it sees.<br><br>


title: DESCRIPTION
content:
<b>tcpkill</b> is a powerful command-line utility designed to forcibly terminate active TCP connections. Part of the <b>dsniff</b> suite of network auditing tools, it operates by injecting spoofed TCP RST (reset) or FIN (finish) packets into an ongoing TCP stream. When <b>tcpkill</b> identifies a connection matching its specified filter criteria, it constructs and sends these control packets to both the client and server ends of the communication. This action causes the applications on both sides to believe the connection has been gracefully closed or abruptly reset, effectively disrupting the data flow.<br><br>Commonly used in network testing, penetration testing, or for administrative purposes to clear stale or unwanted connections, <b>tcpkill</b> requires root privileges to perform packet capturing and injection. It leverages <b>libpcap</b> for packet filtering, allowing users to specify precise criteria using standard <b>tcpdump</b>-like expressions to target specific hosts, ports, or protocols. Its ability to disrupt network services makes it a potent tool for demonstrating network vulnerabilities or managing network flow, though it must be used with caution due to its disruptive nature.


title: CAVEATS
content:
Using <b>tcpkill</b> requires <b>root privileges</b>. Improper use can severely disrupt legitimate network services and should be exercised with extreme caution. It may not be effective against all types of connections, especially those employing strong sequence number randomization or operating over encrypted tunnels where initial handshake information is not visible. Since it actively injects packets, it's an intrusive tool and can be detected by network intrusion detection systems.


title: PACKET FILTERING
content:
<b>tcpkill</b> relies on <b>libpcap</b> for its packet filtering capabilities. This means the <i>expression</i> argument follows the same syntax as <b>tcpdump</b>, allowing for highly specific targeting of connections based on IP addresses, ports, protocols, and other TCP/IP header fields.


title: OPERATION MODES
content:
By default, <b>tcpkill</b> operates in an active mode, listening on a live network interface and injecting forged TCP RST/FIN packets. However, with the <i>-r</i> option, it can operate in a passive, offline mode, processing a saved packet capture file without any network injection. This is useful for analysis or testing filter expressions.


title: HISTORY
content:
<b>tcpkill</b> is a component of the <b>dsniff</b> suite of network analysis and penetration testing tools, originally developed by Dug Song. The <b>dsniff</b> project gained prominence in the late 1990s and early 2000s, providing a collection of tools for passive and active network security auditing. <b>tcpkill</b> specifically addresses the need to disrupt TCP streams, a common technique in network security assessments to test resilience or clear network paths. Its design reflects the network security landscape of its time, though it remains a relevant tool for certain tasks today.


title: PARAMETERS
content:
<b><b>-i</b> <i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to send the packets out of. For example, <b>eth0</b> or <b>enp0s3</b>.<br><br><b><b>-c</b> <i>&lt;cachefile&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a cache file generated by <b>tcpprep</b>, which contains flow and index information crucial for performance and accurate replay.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Truncates packets during replay, ensuring they are no larger than the configured MTU of the output interface. This helps prevent fragmentation issues.<br><br><b><b>-l</b> <i>&lt;loops&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loops the replay of the <b>pcap</b> file(s) for a specified number of times. Use <b>0</b> for infinite looping.<br><br><b><b>-p</b> <i>&lt;speed&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the playback speed. Can be a factor (e.g., <b>1.0</b> for original, <b>0.5</b> for half, <b>10</b> for 10x), or a specific throughput like <b>100MBPS</b> or <b>10KBITS</b>.<br><br><b><b>--stats</b> <i>&lt;interval&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints detailed statistics every specified number of seconds during the replay process, showing packets sent, bytes, and drops.<br><br><b><b>--srcip</b> <i>&lt;ip_rewrite&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rewrites the source IP addresses of packets. Can be a single IP, a range (e.g., <b>192.168.1.0/24</b>), or a file containing a list of IPs.<br><br><b><b>--dstip</b> <i>&lt;ip_rewrite&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rewrites the destination IP addresses of packets, similar to <b>--srcip</b>.<br><br><b><b>-e</b> <i>&lt;dst_mac&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rewrites the destination MAC address of all packets to the specified address. Useful when targeting a specific device.<br><br><b><b>-E</b> <i>&lt;src_mac&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rewrites the source MAC address of all packets to the specified address.<br><br>


title: DESCRIPTION
content:
<i>tcpreplay</i> is a powerful utility within the <b>tcpreplay</b> suite designed to replay previously captured network traffic, stored in <b>pcap</b> files, onto a live network interface. It is an invaluable tool for network engineers, security professionals, and developers for a variety of tasks including network performance testing, simulating real-world network traffic for intrusion detection system (IDS) and firewall testing, and replicating network issues for troubleshooting. The command offers extensive control over the replay process, allowing users to adjust playback speed, loop traffic, and rewrite MAC and IP addresses to fit the target network environment. For optimal performance and accurate statistics, especially in high-throughput scenarios, <i>tcpreplay</i> often works in conjunction with <b>tcpprep</b>, which pre-processes the <b>pcap</b> files to create a cache for efficient packet injection.


title: CAVEATS
content:
Using <i>tcpreplay</i> typically requires root privileges due to its need to send raw network packets. Performance can be heavily influenced by hardware capabilities, network interface drivers, and the complexity/size of the <b>pcap</b> files; packet drops may occur if the system cannot keep up with the desired replay speed. It is highly recommended to pre-process <b>pcap</b> files with <b>tcpprep</b> for optimal replay accuracy and performance, especially for large files or high-speed scenarios. MAC and IP address rewriting is a common requirement to match the target network environment, so proper configuration is crucial.


title: USE CASES AND APPLICATIONS
content:
<i>tcpreplay</i> is widely used for:<br>1. <b>IDS/Firewall Testing</b>: Simulating real attacks or benign traffic to test security devices' detection and prevention capabilities.<br>2. <b>Network Performance Benchmarking</b>: Stress testing network devices and infrastructure with realistic traffic loads to assess their capacity and stability.<br>3. <b>Troubleshooting and Reproduction</b>: Recreating specific network conditions or problems captured in a <b>pcap</b> file to diagnose issues in a controlled environment.<br>4. <b>Forensic Analysis</b>: Replaying traffic to analyze network behavior or malicious activity in a isolated setup without affecting live systems.


title: PERFORMANCE OPTIMIZATION
content:
For high-speed replay, consider:<br>1. Using a cache file generated by <b>tcpprep</b> with the <b>-c</b> option, which provides flow and index information for faster processing.<br>2. Employing specialized packet injection methods like <b>netmap</b> or <b>PF_RING</b> if your kernel and network card support them, as they bypass parts of the kernel's networking stack for higher throughput.<br>3. Ensuring the output network interface is capable of handling the desired speed without packet drops, and that the CPU has sufficient power to process the packets.


title: HISTORY
content:
The <i>tcpreplay</i> suite, including <i>tcpreplay</i> itself, was originally developed by Aaron Turner in the early 2000s. It was designed to provide a robust and high-performance solution for network traffic replay, addressing needs in network security testing, performance benchmarking, and forensics. Over the years, it has evolved with features like cache files (via <b>tcpprep</b>) for efficient processing, support for various packet injection methods (e.g., netmap, PF_RING), and extensive packet rewriting capabilities, solidifying its role as a go-to tool for network traffic simulation.


title: PARAMETERS
content:
<b><I>hostname</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target hostname or IP address to trace the route to.<br><br><b>[<I>port</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>: The TCP destination port to use for probe packets. If not specified, the command typically defaults to a common port like 80 (HTTP) or 443 (HTTPS).<br><br><b><b>-p</b> <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies the TCP destination port for probes. This overrides the positional <I>port</I> argument if both are given.<br><br><b><b>-f</b> <I>first_ttl</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial Time-To-Live (TTL) value for the first outgoing probe packet. This allows you to start tracing from a specific hop number, skipping initial hops.<br><br><b><b>-m</b> <I>max_ttl</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of hops (maximum TTL) that <b>tcptraceroute</b> will probe. The default value is typically 30 hops.<br><br><b><b>-q</b> <I>num_probes</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of probe packets to send for each Time-To-Live (TTL) setting at each hop. The default is usually 3 probes.<br><br><b><b>-w</b> <I>timeout</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the time (in seconds) to wait for a response to a probe packet. If no response is received within this time, an asterisk (*) is displayed. Default is typically 3-5 seconds.<br><br><b><b>-s</b> <I>source_ip</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the source IP address to use for outgoing probe packets. Useful on systems with multiple network interfaces or IP addresses.<br><br><b><b>-i</b> <I>interface</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface through which to send probe packets.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to resolve IP addresses to hostnames. This speeds up the tracing process by displaying only numerical IP addresses.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the tracing process, including sent and received packet details.<br><br>


title: DESCRIPTION
content:
<b>tcptraceroute</b> is a command-line utility designed to trace the network path to a destination by sending TCP SYN packets. Unlike the traditional <b>traceroute</b> command which primarily uses UDP or ICMP probes, <b>tcptraceroute</b>'s method is particularly effective for diagnosing connectivity issues in environments where firewalls might block UDP or ICMP traffic but permit TCP on specific ports (e.g., 80 for HTTP, 443 for HTTPS).<br><br>It operates by sending TCP SYN packets with an incrementally increasing Time-To-Live (TTL) value. Each intermediate router (hop) that receives a packet with a TTL of 1 decrements it to 0 and sends back an ICMP Time Exceeded message, revealing its IP address. When the probe reaches the destination host, it typically responds with a TCP SYN-ACK, indicating successful arrival. This functionality enables network administrators to pinpoint where network traffic is being blocked or misrouted, helping to identify bottlenecks, routing problems, or firewall restrictions affecting TCP-based services.


title: CAVEATS
content:
<ul><li><b>Root Privileges:</b> <b>tcptraceroute</b> typically requires root privileges or appropriate capabilities (e.g., CAP_NET_RAW) to create raw sockets for sending SYN packets and listening for ICMP Time Exceeded messages.</li><li><b>Firewall Blocking:</b> While designed to bypass firewalls, firewalls at intermediate hops or the destination can still block ICMP Time Exceeded messages or the final TCP SYN-ACK response, leading to incomplete traces or asterisk (*) entries.</li><li><b>Rate Limiting:</b> Some routers or network devices may implement rate limiting on ICMP messages, which can make the output appear unreliable or cause timeouts.</li><li><b>Asymmetric Routing:</b> The return path for packets might differ from the outbound path. <b>tcptraceroute</b> only reveals the forward path, which can be misleading if routing is asymmetric.</li><li><b>Permission Denied:</b> If you encounter 'Permission denied' errors, ensure you are running the command with sufficient privileges (e.g., using <b>sudo</b>).</li></ul>


title: EXAMPLE USAGE
content:
To trace the path to example.com using TCP port 443 (HTTPS), sending only one probe per hop, and not resolving IP addresses to hostnames:<br><b><I>tcptraceroute -p 443 -q 1 -n example.com</I></b><br><br>To start tracing from the 5th hop and limit the total trace to 20 hops towards google.com:<br><b><I>tcptraceroute -f 5 -m 20 google.com</I></b><br><br>To specify a source IP address for the trace:<br><b><I>tcptraceroute -s 192.168.1.100 myremotehost.com</I></b>


title: HISTORY
content:
The standard <b>traceroute</b> utility, introduced in 1987, became a fundamental tool for network diagnostics. However, as network security evolved, firewalls increasingly blocked the UDP and ICMP packets that <b>traceroute</b> traditionally uses. This growing need for a diagnostic tool capable of traversing stricter firewall rules led to the development of utilities like <b>tcptraceroute</b>. While its specific historical timeline is less broadly documented than <b>traceroute</b> itself, <b>tcptraceroute</b> emerged as an essential alternative for network administrators and security professionals, leveraging standard TCP SYN packets on common ports (like HTTP/S) to bypass filters and provide a more accurate route assessment in contemporary filtered network environments.


title: PARAMETERS
content:
<b><I>-b</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a "break" from option processing, useful for scripts that might confuse option parsing.<br><br><b><I>-c <I>argument</I></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads commands from the first <I>argument</I> (which must be a single string) instead of from a file or standard input.<br><br><b><I>-e</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits immediately if a command exits with a non-zero status.<br><br><b><I>-f</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a "fast" shell, not executing the user's <b>.tcshrc</b> or <b>.cshrc</b> startup files.<br><br><b><I>-l</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Acts as a login shell. This implies reading <b>.login</b> and <b>.logout</b> files.<br><br><b><I>-m</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the user's <b>.tcshrc</b> (or <b>.cshrc</b>) in any case for the current user, even if not sourcing from a terminal.<br><br><b><I>-n</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses commands but does not execute them. Useful for syntax checking scripts.<br><br><b><I>-q</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode. Suppresses the shell prompt and some startup messages.<br><br><b><I>-s</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads commands from standard input. This is the default if no arguments are given and not a tty.<br><br><b><I>-v</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <b>verbose</b> shell variable before executing commands, printing command input lines.<br><br><b><I>-V</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <b>verbose</b> shell variable before executing the <b>.tcshrc</b> file.<br><br><b><I>-x</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <b>echo</b> shell variable before executing commands, printing commands after history substitution and aliasing.<br><br><b><I>-X</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <b>echo</b> shell variable before executing the <b>.tcshrc</b> file.<br><br><b><I>-y</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes the shell to not load <b>.tcshrc</b> or <b>.cshrc</b> if it cannot find a home directory. (Often default behavior).<br><br><b><I>-Y</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes the shell to load <b>.tcshrc</b> or <b>.cshrc</b> even if it cannot find a home directory. (Rarely used).<br><br><b><I>-D<I>name</I>[=<I>value</I>]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets an environment variable named <I>name</I> to <I>value</I>. If <I>value</I> is omitted, it sets the variable to an empty string.<br><br>


title: DESCRIPTION
content:
The <b>tcsh</b> command is an enhanced, backward-compatible version of the C shell (<b>csh</b>). It serves as an interactive command language interpreter and a command execution environment. Originally derived from <b>csh</b>, <b>tcsh</b> gained prominence by adding crucial interactive features that its predecessor lacked, most notably command-line editing (borrowing from the TENEX C shell, hence the 't' in <b>tcsh</b>), programmable word completion, and spell checking for commands and filenames. It supports a robust history mechanism, job control, aliases, and directory stack management, making it a powerful choice for interactive use. While it can be used for scripting, its non-POSIX compliant C-like syntax and differences in I/O handling often make it less preferred than <b>bash</b> or <b>sh</b> for complex scripts.


title: CAVEATS
content:
<b>tcsh</b>'s syntax differs significantly from POSIX-compliant shells like <b>sh</b> or <b>bash</b> (e.g., variable assignment with <b>set</b>, different <b>if</b>/<b>for</b>/<b>while</b> syntax, and specific handling of logical operators <b>&&</b>/<b>||</b>). This can lead to non-portable scripts and a steeper learning curve for users accustomed to Bourne-style shells. It's generally less suitable for robust system scripting due to these differences and its idiosyncratic handling of standard error.


title: INTERACTIVE FEATURES
content:
<b>tcsh</b> provides powerful interactive features including flexible command-line editing (supporting both Emacs and vi keybindings), comprehensive history substitution, a rich aliasing mechanism, robust job control for managing background processes, and a directory stack for easy navigation between frequently used directories. Its programmable completion allows for smart auto-completion of commands, filenames, and arguments based on context.


title: STARTUP FILES
content:
When <b>tcsh</b> starts, it reads several startup files. For interactive shells, it typically sources <b>~/.tcshrc</b> (or <b>~/.cshrc</b> if <b>.tcshrc</b> isn't found). For login shells, it also reads <b>~/.login</b> and executes commands in <b>~/.logout</b> upon exit. System-wide configuration can be set in <b>/etc/csh.cshrc</b> and <b>/etc/csh.login</b>.


title: HISTORY
content:
<b>tcsh</b> emerged as an evolution of the original C shell (<b>csh</b>), developed at the University of California, Berkeley. <b>csh</b> introduced innovations like job control and command history, but lacked advanced interactive features. In 1983, Ken Greer added command-line editing capabilities, derived from the TENEX operating system's C shell (thus the 't'), creating <b>tcsh</b>. Over time, further enhancements like programmable completion and spell checking were integrated, making <b>tcsh</b> a popular interactive shell, especially on BSD-derived systems and, historically, macOS.


title: SYNOPSIS
content:
<b>tdbbackup</b> [<I>-v</I>] <I>source_tdb_file</I> <I>destination_backup_file</I><br><b>tdbbackup</b> [<I>-v</I>] <I>-s source_tdb_file</I> <I>-d destination_backup_file</I>


title: PARAMETERS
content:
<b><I>source_tdb_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the TDB file to be backed up. This can be provided as a positional argument.<br><br><b><I>destination_backup_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path where the consistent backup copy will be saved. This can be provided as a positional argument.<br><br><b><b>-s</b> <I>source_tdb_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the TDB file to be backed up, using an explicit option.<br><br><b><b>-d</b> <I>destination_backup_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path where the consistent backup copy will be saved, using an explicit option.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the backup process to standard output.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with command usage and available options, then exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>tdbbackup</b> version information to standard output and exits.<br><br>


title: DESCRIPTION
content:
<b>tdbbackup</b> is a utility from the <I>tdbtools</I> suite designed for creating consistent backups of TDB (Trivial Database) files. TDB files are lightweight databases often used by Samba and other applications for storing various types of data, such as user credentials, group mappings, or internal state.<br><br>The primary challenge with backing up live database files is ensuring data consistency. If a database is being written to during a backup operation, the resulting backup file might be corrupt or contain inconsistent data. <b>tdbbackup</b> addresses this by internally acquiring a lock on the source TDB file, copying its contents to a specified destination, and then releasing the lock. This guarantees that the backup copy reflects a single, consistent state of the database, even if it's actively in use.<br><br>This command is particularly vital for Samba administrators who need to regularly back up critical TDB files like <I>secrets.tdb</I>, <I>passdb.tdb</I>, or <I>group_mapping.tdb</I> without interrupting Samba services or risking data corruption. It ensures data integrity for recovery operations.


title: CAVEATS
content:
<b>tdbbackup</b> requires appropriate file system permissions to read the source TDB file and write to the specified destination path. The TDB file must be unlockable by <b>tdbbackup</b>; if another process holds an exclusive lock preventing advisory locking, the backup might fail. While <b>tdbbackup</b> uses advisory locking to ensure consistency, it relies on other applications (like Samba) also respecting these locks.


title: CONSISTENCY GUARANTEE
content:
<b>tdbbackup</b> ensures a consistent snapshot of the TDB file by acquiring a lock on the file before initiating the copy. This critical step prevents partial or corrupt backups that could occur if the file were modified by another process during the copy operation, guaranteeing a reliable point-in-time backup.


title: USAGE WITH SAMBA
content:
For Samba administrators, <b>tdbbackup</b> is essential for regularly backing up critical TDB files such as <I>/var/lib/samba/private/secrets.tdb</I>, <I>/var/lib/samba/private/passdb.tdb</I>, and <I>/var/lib/samba/group_mapping.tdb</I>. Incorporating regular <b>tdbbackup</b> operations into backup routines is a key part of disaster recovery planning for Samba environments.


title: HISTORY
content:
<b>tdbbackup</b> is an integral part of the <I>tdbtools</I> suite, which emerged from the development efforts behind Samba. The TDB (Trivial Database) library was created to provide a lightweight, robust, and fast key-value store for Samba's internal operations, particularly for scenarios requiring concurrent access from multiple processes. As Samba became a critical component in network infrastructures, the need for reliable backup mechanisms for its persistent data, often stored in TDB files, became paramount. <b>tdbbackup</b> was specifically developed to address the challenge of backing up these live TDB files consistently, leveraging the TDB library's locking mechanisms to ensure data integrity during the backup process. Its evolution closely tracks the increasing reliance on TDB files within the Samba project.


title: PARAMETERS
content:
<b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Don't pretty print the data.</i> Output data in raw hexadecimal format, showing the exact bytes stored. This is useful for low-level debugging.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Pretty print the data.</i> This is the default behavior. It attempts to interpret the data and display it in a more human-readable format, often converting ASCII strings where possible.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show statistics.</i> Displays statistics about the TDB file, such as the number of records, hash chain lengths, and free space. Does not dump the actual records.<br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show all records.</i> Includes deleted records in the output. By default, <b>tdbdump</b> only shows active records. Deleted records are often still present in the file until the space is re-used.<br><br><b><tdb-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The path to the TDB file</i> to be dumped. This is a mandatory argument.<br><br>


title: DESCRIPTION
content:
<b>tdbdump</b> is a command-line utility designed to inspect and display the contents of a Trivial Database (TDB) file. TDB is a lightweight, high-performance database library primarily used by Samba to store various types of persistent data, such as share definitions, user information, lock states, and other internal state data. It stores data as key-value pairs.<br><br><b>tdbdump</b> allows administrators and developers to examine the raw data within these files, which can be invaluable for debugging issues, understanding Samba's internal state, or recovering specific pieces of information. It can display data in a human-readable "pretty print" format or as raw hexadecimal output, and can also provide statistics about the database.


title: CAVEATS
content:
<b>tdbdump</b> is specific to TDB files; it cannot be used for other database formats (e.g., SQLite, MySQL).<br><br>The "pretty print" output (using <b>-p</b>) relies on heuristics to determine if data is printable ASCII; binary data might still appear unintelligible.<br><br>Examining TDB files while Samba services are running can lead to inconsistent or incomplete output due to concurrent writes, although <b>tdbdump</b> itself is read-only. For consistent dumps, it is recommended to stop relevant Samba services first.


title: COMMON USAGE EXAMPLES
content:
To view a user database:<br><i>tdbdump /var/lib/samba/private/secrets.tdb</i><br><br>To check statistics of a database:<br><i>tdbdump -s /var/lib/samba/private/passdb.tdb</i><br><br>To dump raw hexadecimal data for debugging:<br><i>tdbdump -H /var/lib/samba/private/share_info.tdb</i>


title: TDB FILE LOCATIONS
content:
TDB files are typically found in Samba's private directory, often <i>/var/lib/samba/private/</i> or <i>/var/cache/samba/</i>. Common TDB files include <i>secrets.tdb</i>, <i>passdb.tdb</i>, <i>share_info.tdb</i>, <i>connections.tdb</i>, and <i>locking.tdb</i>.


title: HISTORY
content:
TDB (Trivial Database) was developed as part of the Samba project to provide a simple, high-performance, and persistent key-value store for internal use. It's designed for concurrent access by multiple processes, making it suitable for services like Samba that manage shared state. <b>tdbdump</b> is an essential part of the TDB utility suite, providing visibility into these critical data files, and has been a staple tool for Samba administrators and developers since TDB's inception.


title: SYNOPSIS
content:
<b>tdbtool</b> [<i>OPTIONS</i>] <i>TDB_FILE</i> [<i>COMMAND</i>] [<i>KEY</i>] [<i>VALUE</i>]<br><br><b>tdbtool</b> <i>TDB_FILE</i> <b>info</b><br><b>tdbtool</b> <i>TDB_FILE</i> <b>dump</b><br><b>tdbtool</b> <i>TDB_FILE</i> <b>create</b><br><b>tdbtool</b> <i>TDB_FILE</i> <b>check</b><br><b>tdbtool</b> <i>TDB_FILE</i> <b>delete</b> <i>KEY</i><br><b>tdbtool</b> <i>TDB_FILE</i> <b>store</b> <i>KEY VALUE</i><br><b>tdbtool</b> <i>TDB_FILE</i> <b>keys</b>


title: PARAMETERS
content:
<b>-H, --hex</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display keys and values in hexadecimal format. This is the default output format for 'dump' and 'keys' commands.<br><br><b>-s, --string</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret keys and values as human-readable strings. Useful for viewing textual data.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce more verbose output, often showing additional details about operations.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about the TDB file's header, such as its version, size, and number of records.<br><br><b>dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump all key-value pairs stored in the TDB file. By default, outputs in hexadecimal.<br><br><b>create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new, empty TDB file. If the file already exists, it will be truncated.<br><br><b>check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a consistency check on the TDB file, verifying its integrity.<br><br><b>delete KEY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete the record associated with the specified KEY from the TDB file.<br><br><b>store KEY VALUE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Store a new key-value pair or update an existing one. If the KEY already exists, its VALUE will be overwritten.<br><br><b>keys</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump only the keys present in the TDB file. Useful for quickly listing entries without their values.<br><br>


title: DESCRIPTION
content:
<i>tdbtool</i> is a command-line utility used for inspecting, creating, and modifying TDB (Trivial Database) files. TDB is a simple, lightweight key-value database often employed by the Samba suite to store various kinds of persistent data, such as share definitions, lock information, user mapping, and other internal state.<br><br>This tool provides a direct interface to manipulate these database files, allowing administrators and developers to examine the contents of a TDB file, add new records, update existing ones, or delete entries. It's particularly useful for debugging issues related to Samba's internal data, recovering from corruption, or performing manual data adjustments when necessary. While powerful, direct modification requires caution, as incorrect operations can lead to data corruption or service instability. By default, <i>tdbtool</i> displays keys and values in hexadecimal format, but it can also interpret them as strings for easier readability.


title: CAVEATS
content:
Direct manipulation of TDB files using <i>tdbtool</i> carries risks. Incorrect operations, especially when modifying or deleting records, can lead to data corruption within the TDB file. This can, in turn, cause critical Samba services to malfunction or even fail to start. It is highly recommended to <b>always back up any TDB file</b> before attempting modifications. Additionally, modifications should ideally be performed on files that are not actively in use by a running Samba daemon or other services to prevent conflicts or inconsistent states.


title: KEY AND VALUE FORMAT
content:
By default, <i>tdbtool</i> expects and outputs keys and values as hexadecimal byte sequences. This is the raw format in which TDB stores data. For example, a key 'users' might be displayed as '7573657273'. To work with human-readable strings, especially for textual data, use the <b>-s</b> or <b>--string</b> option. When using <b>store</b>, if <b>-s</b> is not specified, you'll need to provide hexadecimal representations of the key and value.


title: TYPICAL USE CASES
content:
Typical uses for <i>tdbtool</i> include:<br><b>Debugging:</b> Examining the contents of TDB files (e.g., 'locking.tdb', 'secrets.tdb') to understand Samba's internal state.<br><b>Corruption Recovery:</b> In rare cases of TDB file corruption, <i>tdbtool</i> might be used to attempt to delete corrupted records or check file integrity.<br><b>Advanced Administration:</b> Manually adding or modifying specific entries for very specific configurations or troubleshooting scenarios.<br><b>Data Migration/Inspection:</b> Viewing TDB contents before or after Samba upgrades or reconfigurations.


title: HISTORY
content:
<i>tdbtool</i> is an integral part of the Samba suite, an open-source implementation of the SMB/CIFS networking protocol. It was developed by Andrew Tridgell and the Samba Team as a utility to manage TDB (Trivial Database) files, which are a simple, high-performance database format designed specifically for Samba's internal data storage needs. TDB itself was created to provide a lightweight, efficient key-value store without the overhead of more complex database systems, making <i>tdbtool</i> essential for debugging, maintenance, and advanced administration of Samba installations.


title: PARAMETERS
content:
<b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the use of colors in the program's display, provided the terminal supports them.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns off tutorial mode. When this option is used, the program will not explain moves or suggest optimal plays, acting more like a regular backgammon program without the instructional guidance.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates 'play only' mode. Similar to <b>-t</b>, but also suppresses any instructional text about rules or strategy, focusing purely on the gameplay itself without interruptions.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Engages quiet mode. This option suppresses all non-essential output, such as welcome messages and lengthy explanations, making the program more suitable for experienced users who prefer a streamlined game.<br><br>


title: DESCRIPTION
content:
Teachgammon is an <b>interactive backgammon tutor</b> designed to help beginners learn the game from scratch. It explains the fundamental rules, suggests optimal moves for various board states, and analyzes the user's plays, providing immediate feedback and reasoning. The program visually displays the backgammon board, allows users to make their moves, and then offers insightful comments or proceeds with its own turn. Beyond its tutorial capabilities, it can also function as a standard backgammon game for more experienced players by disabling its instructional and assistive features via command-line options.


title: CAVEATS
content:
Some terminals may not display colors correctly, leading to display issues.<br>The built-in AI (Artificial Intelligence) is not particularly strong and may make suboptimal moves, especially at higher levels of play.


title: HISTORY
content:
Teachgammon is a classic program that forms part of the traditional BSD games package. It was originally written by Mark B. Horton, contributing to its legacy as an early interactive learning tool for backgammon.


title: PARAMETERS
content:
<b><b>-o</b>, <b>--outdir</b> <I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where output files (e.g., <I>.pdf</I>) should be placed. By default, output goes into the current directory.<br><br><b><b>-k</b>, <b>--keep-intermediates</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not delete intermediate files (like <I>.log</I>, <I>.aux</I>, <I>.dvi</I>) after a successful build. Useful for debugging.<br><br><b><b>-p</b>, <b>--print-stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the primary output (e.g., the PDF file content) to standard output. Useful for piping results.<br><br><b><b>-r</b>, <b>--reruns</b> <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the maximum number of times to re-run <I>LaTeX</I> to resolve cross-references, tables of contents, etc. Defaults to a reasonable number.<br><br><b><b>--keep-logs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always keep the <I>.log</I> file, even if <I>--keep-intermediates</I> is not specified.<br><br><b><b>--warnings-as-errors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat any compiler warnings as fatal errors, causing the build to fail.<br><br><b><b>-c</b>, <b>--chatter</b> <I>LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control the verbosity of the output. <I>LEVEL</I> can be <I>minimal</I>, <I>default</I>, <I>high</I>, or <I>diagnostic</I>.<br><br><b><b>--only-cached</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only use locally cached assets and do not attempt to download any missing resources from the network.<br><br><b><b>--synctex</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate <I>SyncTeX</I> data for forward/inverse search functionality with text editors.<br><br><b><b>--set-config</b> <I>KEY=VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a specific configuration variable. For advanced customization.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version information of <I>Tectonic</I>.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br>


title: DESCRIPTION
content:
<i>Tectonic</i> is a modern, cross-platform, self-contained <I>TeX</I>/<I>LaTeX</I> typesetting engine designed for reproducibility and ease of deployment. Unlike traditional <I>TeX</I> distributions, <I>Tectonic</I> aims to provide a complete and isolated environment, bundling all necessary components like fonts and packages internally.<br><br>It addresses common issues with traditional <I>TeX</I> setups, such as large distribution sizes and difficulties in achieving consistent, reproducible outputs across different systems. <I>Tectonic</I> achieves this by leveraging a 'Web-friendly' approach, where it can fetch missing resources (like <I>TeX</I> packages or fonts) on demand from remote caches, minimizing its initial footprint. This makes it particularly well-suited for automated build systems, continuous integration pipelines, and web services that require efficient and reliable document compilation.


title: CAVEATS
content:
Although powerful, <i>Tectonic</i> is not a full drop-in replacement for a complete <I>TeX Live</I> or <I>MiKTeX</I> installation for all highly specialized or legacy scenarios. It's opinionated about its internal asset management, which might differ from a system-wide <I>TeX</I> distribution. Network access is often required for the first build of a document if necessary packages are not already cached locally. As an actively developed project, certain features or behaviors might evolve.


title: REPRODUCIBLE BUILDS
content:
A core philosophy of <I>Tectonic</I> is to produce bit-for-bit identical PDF output for the same <I>LaTeX</I> source, regardless of the system or time of compilation. This is crucial for scientific publishing, automated pipelines, and ensuring consistency.


title: SELF-CONTAINED NATURE
content:
<I>Tectonic</I> aims to be a single binary that includes almost everything needed to compile <I>LaTeX</I> documents, including common fonts and packages. This reduces the need for large external <I>TeX</I> installations and simplifies deployment across various environments.


title: ON-DEMAND ASSET FETCHING
content:
When a document requires a package or font not pre-bundled or locally cached, <I>Tectonic</I> can intelligently download it on the fly from a remote asset server (like the <I>TeX Live</I> archives). This 'pull-on-demand' model keeps the <I>Tectonic</I> binary relatively small while still providing access to a vast ecosystem of <I>TeX</I> resources.


title: HISTORY
content:
<i>Tectonic</i> was initiated and is primarily maintained by the <i>tectonic-typesetting</i> open-source community, with significant contributions from Jonathan Kew (also known as <I>pkgw</I>). The project began with the goal of creating a modern, robust, and reproducible <I>TeX</I> engine that could overcome the challenges of traditional <I>TeX</I> distributions, particularly in automated and cloud environments. It is written in <I>Rust</I> and first gained public attention around 2017-2018, steadily growing its feature set and user base as a reliable alternative for efficient <I>LaTeX</I> compilation.


title: PARAMETERS
content:
<b>-a, --append</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append to the given <i>FILE</i>s, do not overwrite existing content.<br><br><b>-i, --ignore-interrupts</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore interrupt signals (like Ctrl+C), allowing the command to continue running.<br><br>


title: DESCRIPTION
content:
<i>tee</i> is a fundamental command-line utility that <b>reads standard input</b> and simultaneously <b>writes it to standard output</b> and to <b>one or more files</b>. This unique capability makes it invaluable for tasks where you need to both view the output of a command on your screen and capture it in a file for later analysis, logging, or further processing. It acts like a "T" junction in a pipe, diverting the flow of data. By default, <i>tee</i> will <i>overwrite</i> the content of the specified files. However, it can be instructed to <i>append</i> to existing files, which is crucial for maintaining logs or accumulating data over time. Its primary use case is within pipelines, allowing intermediate results to be saved without interrupting the flow of data to subsequent commands. <i>tee</i> also handles signals gracefully, making it robust for long-running operations.


title: CAVEATS
content:
By default, <i>tee</i> <b>overwrites</b> files. Care must be taken to use the <i>-a</i> option when appending is desired to avoid unintended data loss.<br>If the disk runs out of space or permissions are insufficient, <i>tee</i> may fail to write to files. While it can print errors, the default behavior might not halt the pipeline unless explicitly configured.<br>For very large inputs, <i>tee</i>'s performance might be limited by disk write speeds or file system overhead.


title: COMMON USAGE EXAMPLES
content:
<i>command</i> | <b>tee</b> <i>output.log</i><br>This command runs `command`, displays its output on the screen, and saves it to `output.log`, overwriting the file if it exists.<br><br><i>command</i> | <b>tee</b> -a <i>session.log</i><br>Similar to the above, but appends the output to `session.log` instead of overwriting it.<br><br><b>Capturing intermediate pipeline output</b>:<br><i>command1</i> | <b>tee</b> <i>intermediate.txt</i> | <i>command2</i><br>The output of `command1` is saved to `intermediate.txt` and also piped as input to `command2`.


title: ERROR HANDLING
content:
The <i>--output-error</i> option (specific to GNU <i>tee</i>) allows specifying behavior upon write errors (e.g., disk full, permissions denied). Options include <i>warn</i> (default), <i>warn-nopipe</i>, <i>exit</i>, and <i>exit-nopipe</i>, providing more control over pipeline termination when errors occur during file writes.


title: HISTORY
content:
The <i>tee</i> command has been a standard utility in Unix-like operating systems since their early development. Its design reflects the Unix philosophy of small, specialized tools that can be combined in pipelines to perform complex tasks. It is part of the <i>GNU Core Utilities</i>, ensuring its availability and consistent behavior across most modern Linux distributions. Its enduring presence underscores its fundamental utility in command-line operations and shell scripting.


title: PARAMETERS
content:
<b><I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument specifying a Telegram URL (e.g., <I>tg://resolve?domain=username</I>) to open a specific chat, channel, or bot directly upon launching the application. This functionality often relies on desktop environment integration for handling <I>tg://</I> links.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed version of Telegram Desktop to the console (standard output/error) and then typically launches the application.<br><br>


title: DESCRIPTION
content:
The <b>telegram-desktop</b> command is used to launch the official Telegram Desktop client for Linux. Telegram is a popular, cloud-based mobile and desktop messaging app with a focus on speed and security. It allows users to send messages, photos, videos, and files of any type, as well as create groups for up to 200,000 members or channels for broadcasting to unlimited audiences. The desktop client provides a full-featured interface to access all Telegram functionalities directly from the Linux desktop, including encrypted chats, voice and video calls, and stickers. While primarily a graphical application, this command serves as the entry point to start the user interface and interact with the Telegram service.


title: CAVEATS
content:
As a graphical application, <B>telegram-desktop</B> is primarily controlled through its user interface rather than command-line arguments. Most of its features and settings are accessible only within the running application. Direct command-line interaction beyond launching or opening specific URLs is very limited.


title: DESKTOP INTEGRATION
content:
On Linux, <B>telegram-desktop</B> is typically integrated with the desktop environment's MIME type and URI scheme handling, allowing <I>tg://</I> URLs to be opened directly by the application from web browsers or other applications. This is the common mechanism for clicking on Telegram links to launch or focus the app.


title: INSTALLATION METHODS
content:
<B>telegram-desktop</B> can be installed via various methods on Linux, including official tar.gz archives, distribution package managers (like APT, DNF), Snap, or Flatpak. The command's behavior might vary slightly depending on the installation method (e.g., how it handles paths, updates, or background processes).


title: HISTORY
content:
Telegram, founded by Pavel Durov, launched in 2013, with its desktop client emerging shortly after. The <B>telegram-desktop</B> application is a native cross-platform client (often based on Qt) designed to provide a full-featured messaging experience independent of web browsers. Its development has focused on security, speed, and providing a rich set of features for both personal and group communication, evolving alongside the mobile applications to maintain feature parity and user experience across devices.


title: PARAMETERS
content:
<b>0</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Halt the system (power off).<br><br><b>1 or S/s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Single-user mode. Used for system maintenance or rescue operations.<br><br><b>2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Multi-user mode without NFS (Network File System) services. Often a text-only mode.<br><br><b>3</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Full multi-user mode, text-only. This is a common default runlevel for servers.<br><br><b>4</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unused or user-definable runlevel. Not typically configured by default.<br><br><b>5</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Full multi-user mode with graphical desktop. This is the common default runlevel for desktop systems.<br><br><b>6</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reboot the system.<br><br><b>Q or q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-examine the <i>/etc/inittab</i> file. This reloads the configuration for the <i>init</i> process (primarily for SysVinit).<br><br>


title: DESCRIPTION
content:
<i>telinit</i> is a command used to instruct the <i>init</i> process to change the system's runlevel. Runlevels define the operating mode of the system, ranging from single-user mode to multi-user mode with full networking and graphical interfaces.<br><br>Historically, <i>init</i> (PID 1) was the first process started by the kernel and responsible for managing system boot, shutdown, and runlevels based on the <i>/etc/inittab</i> file. <i>telinit</i> acts as a frontend to send signals to this <i>init</i> process.<br><br>On modern Linux distributions that use <i>systemd</i>, <i>telinit</i> is often provided as a compatibility symlink to <i>systemctl</i>, which translates runlevel requests into <i>systemd</i> target changes (e.g., runlevel 5 maps to <i>graphical.target</i>). While it still functions, <i>systemctl isolate</i> or <i>systemctl set-default</i> are the native and preferred methods for managing system states in <i>systemd</i> environments. Executing <i>telinit</i> typically requires superuser privileges.


title: CAVEATS
content:
Requires root (superuser) privileges to execute.<br>On <i>systemd</i>-based distributions, <i>telinit</i> is a legacy command. While it often works due to compatibility layers, <i>systemctl isolate</i> is the native and preferred command to change targets (equivalent to runlevels).<br>Changing runlevels drastically alters the system's state and can interrupt services or active users; use with caution.


title: DEFAULT RUNLEVELS
content:
The default runlevel is typically configured in the <i>/etc/inittab</i> file (for SysVinit) or as the default boot target (for <i>systemd</i>). Common defaults are:<br><b>Runlevel 3</b>: Text-mode server (no GUI).<br><b>Runlevel 5</b>: Graphical desktop environment.


title: SYSTEMD EQUIVALENCE
content:
On <i>systemd</i> systems, runlevels map to specific <i>systemd</i> targets:<br><b>Runlevel 0</b>: <i>poweroff.target</i><br><b>Runlevel 1/S/s</b>: <i>rescue.target</i><br><b>Runlevel 2</b>: <i>multi-user.target</i> (often)<br><b>Runlevel 3</b>: <i>multi-user.target</i><br><b>Runlevel 5</b>: <i>graphical.target</i><br><b>Runlevel 6</b>: <i>reboot.target</i><br>Using <i>systemctl isolate <target-name></i> is the direct <i>systemd</i> equivalent.


title: HISTORY
content:
<i>telinit</i> is historically part of the <i>sysvinit</i> package, which provides the traditional System V-style <i>init</i> system. For decades, <i>init</i> was PID 1 on Linux and Unix-like systems, managing the entire boot process, daemon startup, and system runlevels based on the <i>/etc/inittab</i> configuration file.<br><br>The <i>telinit</i> command was developed as a standard interface for users (specifically, administrators) to communicate with the running <i>init</i> process to request a change in the system's runlevel. Its usage became synonymous with system state management.<br><br>With the rise of newer init systems like <i>Upstart</i> and, more predominantly, <i>systemd</i>, the role of <i>init</i> and its direct configuration file <i>/etc/inittab</i> has been largely superseded. However, to maintain backward compatibility, <i>systemd</i> often provides a <i>telinit</i> executable (usually a symbolic link to <i>systemctl</i>) that translates the traditional runlevel requests into <i>systemd</i> 'target' changes, ensuring that older scripts and muscle memory can still function.


title: SYNOPSIS
content:
<b>telnet</b> [<i>options</i>] [<i>host</i> [<i>port</i>]]<br><b>telnet</b> [<i>command</i>] (<i>for entering telnet command mode</i>)


title: PARAMETERS
content:
<b><b>-4</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Forces <b>telnet</b> to use IPv4 addresses only for host resolution.</i><br><br><b><b>-6</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Forces <b>telnet</b> to use IPv6 addresses only for host resolution.</i><br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Attempts automatic login using the current username if supported by the remote host.</i><br><br><b><b>-e</b> <i>escape_char</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the escape character for <b>telnet</b>. The default is Ctrl+]. This character brings up the <b>telnet</b> prompt.</i><br><br><b><b>-l</b> <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies a username to be used for automatic login on the remote system, bypassing a login prompt if possible.</i><br><br><b><i>host</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The remote hostname or IP address to connect to. This is the primary target for the connection.</i><br><br><b><i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The destination port number or service name on the remote host. If omitted, <b>telnet</b> defaults to port 23 (the standard TELNET port).</i><br><br>


title: DESCRIPTION
content:
<i><br><b>telnet</b> is a command-line utility and protocol used for interactive text-oriented communication with a remote host or server. It enables a user to log in to a remote computer and execute commands as if they were sitting at the remote machine. Initially designed for remote terminal access, <b>telnet</b> operates by establishing a TCP connection to the specified host and port, then sending keystrokes from the local machine to the remote host and displaying the remote host's output back to the local terminal. Its primary use was for remote shell access on Unix-like systems.<br><br>However, a significant drawback of <b>telnet</b> is its lack of encryption. All data, including usernames, passwords, and transmitted commands, is sent in plaintext over the network. This makes it highly vulnerable to eavesdropping and interception by malicious actors, rendering it insecure for most modern applications, especially over public networks. Consequently, <b>telnet</b> has largely been superseded by more secure protocols like SSH (Secure Shell) for remote administration. Despite its security flaws, <b>telnet</b> can still be useful for basic network diagnostics, such as checking if a specific port is open on a remote server, or for interacting with simple plaintext services that don't require encryption (e.g., some SMTP, HTTP, or POP3 servers for manual debugging).</i>


title: CAVEATS
content:
<i><br><b>Security Risk:</b> All data, including usernames and passwords, is transmitted in plaintext over the network, making it highly vulnerable to interception and eavesdropping. It is not recommended for secure remote login.<br><br><b>Obsolete for Remote Login:</b> Largely superseded by SSH (Secure Shell) for secure remote access and administration due to its cryptographic protection.<br><br><b>Firewall Blocking:</b> Many modern firewalls block incoming and outgoing connections on the default TELNET port (23) due to its inherent insecurity.</i>


title: <I>DEFAULT PORT</I>
content:
<i><br>When no port is specified, <b>telnet</b> defaults to connecting to port 23, which is the standard port assigned to the TELNET service.</i>


title: <I>ESCAPE CHARACTER</I>
content:
<i><br>While connected, pressing the escape character (default <b>Ctrl+]</b>) allows the user to drop into the local <b>telnet</b> command prompt. From this prompt, commands like <b>open</b>, <b>close</b>, <b>quit</b>, <b>status</b>, and <b>set</b> can be issued to control the <b>telnet</b> client.</i>


title: <I>DIAGNOSTIC USE</I>
content:
<i><br>Despite its security limitations, <b>telnet</b> is still commonly used by network administrators and developers for basic network diagnostics, such as checking if a specific port is open and listening on a remote server, or to manually send commands to services like HTTP, SMTP, or POP3 for debugging purposes. For example, <b>telnet example.com 80</b> can be used to manually interact with a web server.</i>


title: HISTORY
content:
<i><br>The <b>TELNET</b> protocol is one of the oldest network protocols, originally developed in 1969 as part of the ARPANET project. It was designed to provide a standardized method for remote terminal access, allowing users to interact with distant mainframe computers as if they were local terminals. For many years, <b>telnet</b> was the primary method for remote login and administration on Unix-like systems and other networked computers.<br><br>However, its fundamental design flaw – the lack of any encryption – became a critical security vulnerability as network security concerns grew. The ability for anyone on the network path to easily intercept and read all transmitted data, including sensitive credentials, led to its decline. By the mid-1990s, the development of SSH (Secure Shell) provided a cryptographically secure alternative, which quickly became the industry standard for remote access, effectively making <b>telnet</b> obsolete for secure applications. Despite this, <b>telnet</b> clients remain available in most operating systems, often used for basic network diagnostics or interacting with unencrypted legacy services.</i>


title: SYNOPSIS
content:
<B>tempfile</B> [<B>-d</B>] [<B>-q</B>] [<B>-p</B> <I>prefix</I>] [<B>-s</B> <I>suffix</I>] [<B>-m</B> <I>mode</I>] [<B>-t</B> <I>dir</I>] [<B>-k</B>] [<B>-n</B>] [<I>template</I>]


title: PARAMETERS
content:
<b><B>-d</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a temporary directory instead of a file.<br><br><b><B>-q</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress error messages during operation.<br><br><b><B>-p</B> <I>prefix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a prefix string for the temporary filename. Defaults to 'tmp.'.<br><br><b><B>-s</B> <I>suffix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a suffix string for the temporary filename.<br><br><b><B>-m</B> <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the permissions (octal mode) for the created file or directory.<br><br><b><B>-t</B> <I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where the temporary file or directory will be created. Overrides <B>TMPDIR</B>.<br><br><b><B>-k</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep the temporary file or directory after the program exits, preventing automatic deletion.<br><br><b><B>-n</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not actually create the file or directory; only print the generated name.<br><br><b><I>template</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A template for the filename, usually containing 'X' characters (e.g., 'myprog.XXXXXX') which will be replaced by unique characters. If not provided, a default template like 'tmp.XXXXXX' is used.<br><br>


title: DESCRIPTION
content:
The <I>tempfile</I> command is a utility designed to securely create unique temporary file or directory names. It helps prevent race conditions and avoids conflicts with existing files, making it ideal for shell scripts requiring temporary storage. Users can specify a prefix, suffix, and permissions for the created item, as well as an explicit temporary directory using the <B>-t</B> option. By default, <I>tempfile</I> tries to use directories specified by the <B>TMPDIR</B> environment variable, falling back to common temporary paths like <I>/tmp</I>. It prints the generated unique path to standard output, which can then be used by other commands or scripts. While functional, it is now largely considered deprecated in favor of the more modern and flexible <I>mktemp</I> utility.


title: CAVEATS
content:
The <I>tempfile</I> command is considered deprecated. Users and scripts are strongly encouraged to use <I>mktemp(1)</I> instead, which provides a more robust, flexible, and actively maintained solution for creating secure temporary files and directories. Relying on <I>tempfile</I> in new development is not recommended.<br>Using the <B>-k</B> option requires careful manual cleanup to prevent accumulation of temporary files.


title: ENVIRONMENT VARIABLES
content:
The <B>TMPDIR</B> environment variable can be used to specify a preferred directory for creating temporary files. If set, <I>tempfile</I> will attempt to use this directory first, unless the <B>-t</B> option is explicitly provided. If <B>TMPDIR</B> is not set, <I>tempfile</I> typically falls back to common temporary paths such as <I>/tmp</I> or <I>/var/tmp</I>.


title: EXIT STATUS
content:
<I>tempfile</I> exits with a status of 0 upon successful creation of a temporary file or directory (or successful generation of a name with <B>-n</B>). A non-zero exit status indicates an error, such as a problem with permissions, disk space, or invalid options provided by the user.


title: HISTORY
content:
<I>tempfile</I> has been a part of the <I>util-linux</I> project for many years, serving as a simple utility for generating unique temporary filenames in shell scripts. Its primary purpose was to address the challenge of securely creating temporary files while avoiding race conditions and name collisions, which were common issues with simpler methods. While effective for its time, its functionality has largely been superseded by the more advanced and flexible <I>mktemp</I> utility, which offers better portability and additional features. Consequently, <I>tempfile</I> is now officially deprecated, with <I>mktemp</I> being the recommended alternative for modern Unix-like systems.


title: SYNOPSIS
content:
<b>termdown</b> [<i>OPTIONS</i>] [<i>TIME</i>]<br>Example: <code>termdown 5m</code> or <code>termdown -c 'notify-send "Time up!"' 1h30m</code>


title: PARAMETERS
content:
<b>--alert, -a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays an audible alert sound when the timer finishes. Requires a sound player (e.g., <i>play</i> from SoX) to be available on the system.<br><br><b>--command <CMD>, -c <CMD></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified shell command <i>CMD</i> immediately after the countdown finishes.<br><br><b>--duration <TIME>, -d <TIME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the countdown duration. This is an alternative to providing <i>TIME</i> as a positional argument.<br><br><b>--fullscreen, -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the countdown in a large, centered font for better visibility, especially during presentations.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the command's help message and exits.<br><br><b>--list-sounds, -l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists available alert sound themes that can be used with the <i>--alert</i> option.<br><br><b>--message <MSG>, -m <MSG></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a custom text message <i>MSG</i> after the countdown completes, in addition to the default "Time is up!".<br><br><b>--progress, -p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a visual progress bar during the countdown, indicating the elapsed time relative to the total duration.<br><br><b>--repeat <N>, -r <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Repeats the countdown <i>N</i> times. If <i>N</i> is 0 or omitted, it repeats indefinitely.<br><br><b>--silent, -s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all visual output during the countdown, only performing the final action (command or alert).<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <b>termdown</b> and exits.<br><br>


title: DESCRIPTION
content:
<b>termdown</b> is a minimalist, yet powerful, command-line utility designed to provide a visual countdown timer directly in your terminal. It supports various time formats (e.g., seconds, minutes, hours) and can be configured to display progress, play alert sounds, or execute a specified command upon completion. Its simplicity makes it ideal for productivity techniques like Pomodoro, presentations, or general time management in a console environment. It's highly scriptable, allowing integration into automated workflows or custom shell scripts.


title: CAVEATS
content:
Audible alerts (<i>--alert</i>) require a system sound player like <i>play</i> from the `sox` package to be installed and configured.<br>Fullscreen mode behavior (<i>--fullscreen</i>) may vary slightly depending on the terminal emulator used.<br><b>termdown</b> is primarily designed for interactive use; complex background scripting might require careful handling of its output.


title: FLEXIBLE TIME FORMATS
content:
<b>termdown</b> accepts various time specifications, including just seconds (e.g., <code>600</code> for 10 minutes), combined units (e.g., <code>1h30m</code>, <code>5m30s</code>), or single units (e.g., <code>2h</code>, <code>15s</code>). The default unit for a plain number is seconds.


title: SCRIPTING INTEGRATION
content:
The <i>--command</i> option makes <b>termdown</b> highly valuable in shell scripts. For example, <code>termdown -c 'aplay /path/to/sound.wav' 10m</code> will play a custom sound after 10 minutes. This allows for customized notifications or automated task triggering upon timer completion.


title: HISTORY
content:
<b>termdown</b> emerged as a lightweight, modern alternative to older timer scripts, focusing on a clean terminal interface and simple scripting capabilities. Its development prioritizes ease of use and integration into standard Unix-like environments. It is often distributed via package managers like <i>apt</i>, <i>dnf</i>, or <i>pacman</i> as a community-maintained utility.


title: SYNOPSIS
content:
<b>terminalizer</b> <i>&lt;command&gt;</i> [<i>options</i>] [<i>arguments</i>]<br><br><b>Common Commands:</b><br>&nbsp;&nbsp;<b>record</b> [<i>&lt;file&gt;</i>]<br>&nbsp;&nbsp;<b>play</b> [<i>&lt;file&gt;</i>]<br>&nbsp;&nbsp;<b>render</b> [<i>&lt;file&gt;</i>]<br>&nbsp;&nbsp;<b>config</b><br>&nbsp;&nbsp;<b>init</b><br>&nbsp;&nbsp;<b>help</b> [<i>&lt;command&gt;</i>]<br>&nbsp;&nbsp;<b>version</b>


title: PARAMETERS
content:
<b><b>-o, --output</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file path for recording (e.g., <i>recording.yml</i>) or rendering (e.g., <i>output.gif</i>).<br><br><b><b>-c, --commands</b> <i>&lt;cmds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a comma-separated list of commands to execute automatically at the beginning of the recording or during playback.<br><br><b><b>-s, --speed-factor</b> <i>&lt;factor&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjust the playback or rendering speed. A factor greater than 1 speeds up, less than 1 slows down. (e.g., 0.5 for half speed, 2 for double speed).<br><br><b><b>-d, --delay</b> <i>&lt;ms&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an initial delay in milliseconds before the recording begins. Useful for preparing your terminal.<br><br><b><b>-g, --gif-images</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>record</b>) Immediately render GIF images from the recording upon completion.<br><br><b><b>-l, --loop</b> <i>&lt;n&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>play</b>) Loop the playback <i>n</i> times. Set to 0 for infinite looping.<br><br><b><b>-i, --interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>play</b>) Allow user interaction during playback, pausing for user input if required.<br><br><b><b>-q, --quality</b> <i>&lt;factor&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>render</b>) Set the quality of the generated GIF. Higher values result in better quality but larger file sizes (0-100).<br><br><b><b>--transparent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>render</b>) Render the GIF with a transparent background.<br><br><b><b>--width</b> <i>&lt;width&gt;</i>, <b>--height</b> <i>&lt;height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>render</b>) Specify the width and height of the rendered GIF in pixels.<br><br><b><b>--font-size</b> <i>&lt;size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>render</b>) Set the font size for the text in the rendered GIF.<br><br><b><b>--cursor-style</b> <i>&lt;style&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>render</b>) Define the style of the cursor (e.g., <i>block</i>, <i>underline</i>, <i>beam</i>).<br><br><b><b>--window-frame</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>render</b>) Include a window frame (border and title bar) around the terminal content in the GIF.<br><br><b><b>--window-title</b> <i>&lt;title&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>render</b>) Set a custom title for the window frame when <i>--window-frame</i> is enabled.<br><br>


title: DESCRIPTION
content:
<i>terminalizer</i> is a powerful and versatile command-line tool designed to record your terminal sessions and replay them as animated GIFs or directly in your terminal. Built with Node.js, it captures terminal input, output, and precise timing information, storing it in a YAML-based recording file. This allows for accurate reproduction of the session, including cursor movements, delays, and interactive commands. <br><br>Beyond simple playback, <i>terminalizer</i> excels at rendering high-quality animated GIFs from these recordings, making it an excellent tool for creating tutorials, demonstrations, or sharing specific command-line interactions. It offers extensive customization options for the rendered GIFs, including dimensions, font styles, cursor appearance, and theme colors, ensuring the output aligns with your aesthetic and functional requirements. Its cross-platform compatibility makes it accessible to a wide range of users on Linux, macOS, and Windows.


title: CAVEATS
content:
<i>terminalizer</i> requires <b>Node.js</b> and <b>npm</b> to be installed on your system. While it captures a wide range of terminal activities, complex interactive applications (e.g., full-screen TUI apps like <i>vim</i> or <i>htop</i>) might not always render or play back with perfect fidelity, especially concerning cursor position or real-time updates. The quality and file size of generated GIFs can vary significantly based on recording length, resolution, and chosen rendering options.


title: CONFIGURATION FILE
content:
<i>terminalizer</i> uses a global configuration file, typically located at <b>~/.terminalizer/config.yml</b>. This file allows users to define default settings for recording and rendering, such as theme, font details, window dimensions, and more, avoiding the need to specify options repeatedly on the command line.


title: USE CASES
content:
Beyond simple recording, <i>terminalizer</i> is extensively used for creating highly effective technical tutorials, showcasing command-line tool functionalities, debugging sessions, or providing visual steps for complex setups. The GIF output is particularly valuable for embedding in documentation, GitHub READMEs, or blog posts.


title: HISTORY
content:
Created by <i>Gokhan Ozcelebi</i>, <i>terminalizer</i> emerged as an open-source project written in JavaScript/Node.js. It quickly gained traction for its user-friendly interface and unique ability to render terminal recordings into shareable animated GIFs, offering a modern alternative to traditional terminal recording methods and making it accessible to a broader audience for documentation and demonstration purposes.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show help message and exit.</I><br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show program's version number and exit.</I><br><br><b>-p <I>PROFILE</I>, --profile <I>PROFILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Use the specified profile for the new window.</I><br><br><b>-x <I>COMMAND</I>, --execute <I>COMMAND</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Execute the given command instead of the default shell.</I><br><br><b>-e <I>COMMAND</I>, --command <I>COMMAND</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Alias for --execute.</I><br><br><b>-m, --maximise</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Start the window maximised.</I><br><br><b>-f, --fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Start the window in fullscreen mode.</I><br><br><b>-w, --no-menubar</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Hide the menubar from the window.</I><br><br><b>-T <I>TITLE</I>, --title <I>TITLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set the initial window title.</I><br><br><b>-H, --hidden</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Start hidden (only to be used with --show-on-activity).</I><br><br><b>-b, --borderless</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Start with no window borders.</I><br><br><b>-c <I>FILE</I>, --config <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify an alternative configuration file.</I><br><br><b>-l <I>LAYOUT</I>, --layout <I>LAYOUT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Load a specified layout from the configuration.</I><br><br><b>--geometry <I>GEOMETRY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set initial window size and position (e.g., 80x24+0+0).</I><br><br><b>--working-directory <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set the initial working directory for new terminals.</I><br><br>


title: DESCRIPTION
content:
<I>Terminator</I> is a powerful and highly customizable <B>GTK-based</B> terminal emulator designed for efficiency, especially for users who work with multiple command-line interfaces simultaneously. Unlike basic terminals, it allows for flexible arrangement of multiple GNOME terminals within one window. Key features include horizontal and vertical splitting of terminals, tab support, and drag-and-drop re-ordering of terminals. It also provides automatic logging and robust customization options for profiles, colors, fonts, and window behavior. <I>Terminator</I> significantly enhances productivity for developers, system administrators, and anyone needing to manage several console sessions concurrently. Its intuitive interface and rich feature set make it a popular choice over default terminal applications for those requiring advanced terminal management capabilities.


title: CAVEATS
content:
<I>Terminator</I> is a graphical application and requires a display server (like <B>Xorg</B> or <B>Wayland</B>) to run. It's built on <B>GTK+</B> and <B>VTE</B>, so its behavior and appearance are tied to these libraries. Configuration is primarily done via its GUI preferences or by directly editing its <B>INI-style</B> configuration file, rather than through command-line arguments for all settings.


title: <B>CONFIGURATION</B>
content:
<I>Terminator</I> stores its configuration in a file, typically located at <B>~/.config/terminator/config</B>. This file uses an <B>INI-like format</B> and allows for detailed customization of profiles, keybindings, layouts, and appearance settings. Many options available in the GUI preferences can be manually edited here for fine-grained control or scripting, providing a powerful way to tailor the terminal to specific workflows.


title: <B>KEYBINDINGS</B>
content:
<I>Terminator</I> offers a rich set of default keybindings for efficient interaction. Some common ones include:<br><I>• </I><B>Ctrl+Shift+O</B><I>: Split horizontally.</I><br><I>• </I><B>Ctrl+Shift+E</B><I>: Split vertically.</I><br><I>• </I><B>Alt+Arrow Keys</B><I>: Navigate between splits.</I><br><I>• </I><B>Ctrl+Shift+W</B><I>: Close current split.</I><br><I>• </I><B>Ctrl+Shift+T</B><I>: Open new tab.</I><br><I>• </I><B>Ctrl+PgUp/PgDn</B><I>: Switch between tabs.</I><br><I>• </I><B>Ctrl+Shift+C/V</B><I>: Copy/Paste.</I><br><I>These powerful shortcuts can be customized via the preferences menu or directly in the configuration file to suit individual preferences and enhance workflow speed.</I>


title: HISTORY
content:
<I>Terminator</I> was initially developed by <B>Chris Jones</B> (gnome-terminator on Launchpad) and first released in <B>2007</B>. It aimed to provide advanced features like splitting and tiling of terminals within a single window, a functionality not natively available in many default terminal emulators at the time. Its development was driven by the need for increased productivity for command-line heavy users, drawing inspiration from tools like <I>tmux</I> and <I>screen</I> but offering a graphical interface. Over the years, it has gained a strong user base due to its flexibility, extensive customization options, and active community support, becoming a staple for many Linux power users.


title: SYNOPSIS
content:
<b>terminator</b> [<i>options</i>]<br><i>Note: Terminator is primarily a graphical application launched from the command line, and its command-line options control its initial state or specific behaviors.</i>


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's help message and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br><b>-p, --profile=<I>PROFILE_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific profile for the new window.<br><br><b>-e, --command=<I>COMMAND</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specified command instead of a shell. <br><i>Note: The command is executed by the shell.</i><br><br><b>-x, --execute <I>COMMAND</I> ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specified command instead of a shell. <br><i>Note: Arguments are passed directly without shell processing.</i><br><br><b>--geometry=<I>GEOMETRY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the initial size and position of the window (e.g., '800x600+100+50').<br><br><b>--working-directory=<I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial working directory for new terminals.<br><br><b>--fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the window in fullscreen mode.<br><br><b>--maximise</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the window in maximized mode.<br><br><b>--no-dbus</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable DBus support, preventing new windows from opening in an existing Terminator instance.<br><br><b>--role=<I>ROLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a role for the window, useful for window managers.<br><br><b>--socket-name=<I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to or create a socket with the given name for inter-process communication.<br><br><b>--class=<I>CLASS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the X window class for the window, useful for window manager rules.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output.<br><br>


title: DESCRIPTION
content:
It is important to note that 'termineter' is not a standard Linux command or utility in most distributions. The information provided below assumes the user meant <I>Terminator</I>, a popular and feature-rich terminal emulator for Linux, which is a common graphical application. <br><br><I>Terminator</I> provides a unique approach to managing multiple terminal sessions by allowing users to arrange and resize multiple terminal windows within a single application frame. Unlike traditional terminal emulators, <I>Terminator</I> supports horizontal and vertical splitting of panes, enabling complex layouts. It also offers tabbed interfaces, drag-and-drop reordering of terminals, and the ability to broadcast commands to multiple panes simultaneously. Its extensive customization options cover everything from font styles and colors to keybindings and plugin support, making it a highly flexible and efficient tool for command-line tasks, server administration, and programming workflows. It aims to solve the problem of managing many <I>xterm</I> or <I>gnome-terminal</I> windows.


title: CAVEATS
content:
As clarified in the description, 'termineter' is not a standard Linux command. The analysis provided is for <I>Terminator</I>, a graphical terminal emulator. <I>Terminator</I> is a GUI application and not a command-line utility in the traditional sense like <I>grep</I> or <I>ls</I>; its features rely on a graphical environment. Compared to lightweight terminals, it can be slightly more resource-intensive due to its many features and Python-based implementation.


title: KEY BINDINGS
content:
<I>Terminator</I> heavily relies on keyboard shortcuts for its advanced features. Common ones include:<br><b>Ctrl+Shift+O</b>: Split horizontally<br><b>Ctrl+Shift+E</b>: Split vertically<br><b>Ctrl+Shift+W</b>: Close current pane<br><b>Ctrl+Shift+PgUp/PgDown</b>: Move between tabs<br><b>Alt+Arrow Keys</b>: Navigate between panes<br><b>Ctrl+Shift+I</b>: Open a new tab


title: CONFIGURATION FILES
content:
<I>Terminator's</I> configuration is managed through a YAML file, typically located at <I>~/.config/terminator/config</I>. This file allows for detailed customization of profiles, keybindings, and plugins, providing granular control over the application's behavior and appearance.


title: HISTORY
content:
<I>Terminator</I> was created to improve upon the limitations of single-pane terminal emulators. Developed in Python and GTK+, it gained popularity for its innovative approach to splitting and arranging terminals. Its development has focused on providing a highly customizable and efficient environment for command-line users, making it a go-to choice for many developers and system administrators since its early releases.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information and exits.<br><br><b><b>-c</b>, <b>--config</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file path instead of the default.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging, which can be useful for troubleshooting issues.<br><br><b><b>scan</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a one-time scan of your configured music directories, updating the library database with new or removed audio files.<br><br><b><b>config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the default configuration file in your preferred text editor (if configured) or prints its path to the console.<br><br>


title: DESCRIPTION
content:
<b>termusic</b> is a modern, terminal-based music player and manager written in Rust. It provides a full-featured interface for managing and playing your local music collection directly from the command line. Designed for efficiency and a rich user experience, it supports a variety of audio formats, playlist management, powerful search capabilities, and customizable keybindings. It's an excellent choice for users who prefer to stay within the terminal environment while enjoying their music. It offers features like gapless playback, album art display (in supported terminals), and flexible configuration via a TOML file.


title: CAVEATS
content:
Terminal compatibility varies; not all terminals fully support true colors or image rendering for album art. <b>termusic</b> relies on an external audio backend (commonly <I>mpv</I>) for playback, which must be installed and accessible in your system's PATH. Initial setup requires configuring music directories in its TOML configuration file.


title: CONFIGURATION FILE
content:
<b>termusic</b> is highly configurable via a TOML file, typically located at <I>~/.config/termusic/config.toml</I>. This file allows users to set music directories, customize keybindings, adjust appearance options, and fine-tune playback settings to their preference.


title: AUDIO BACKEND
content:
For audio playback, <b>termusic</b> acts as a frontend to an external player. The most commonly used and recommended backend is <I>mpv</I>. Users must ensure that <I>mpv</I> or another supported audio player is installed and correctly configured in their system's PATH for playback functionality.


title: HISTORY
content:
<b>termusic</b> is a relatively modern music player, developed in Rust. Its development began around late 2020, gaining traction as a robust and user-friendly alternative to older terminal-based music players. It leverages Rust's performance and memory safety, focusing on a highly customizable user experience and a rich feature set within the terminal environment.


title: PARAMETERS
content:
<b><b>init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a working directory containing <i>Terraform</i> configuration files, downloading necessary providers and modules.<br><br><b><b>plan</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates an execution plan, showing what actions <i>Terraform</i> will take (create, modify, destroy) without actually performing them.<br><br><b><b>apply</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the changes required to reach the desired state of the configuration, provisioning or updating infrastructure.<br><br><b><b>destroy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Destroys all <i>Terraform</i>-managed infrastructure specified in the configuration.<br><br><b><b>validate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the configuration files for syntax errors and internal consistency.<br><br><b><b>fmt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rewrites configuration files to a canonical format, improving readability and consistency.<br><br><b><b>output</b> [NAME]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts and displays the value of an output variable from the state file. If NAME is omitted, all outputs are shown.<br><br><b><b>state</b> &lt;subcommand&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides advanced commands for inspecting and manipulating the <i>Terraform</i> state.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <i>Terraform</i> version and its plugin versions.<br><br>


title: DESCRIPTION
content:
<i>Terraform</i> is an open-source Infrastructure as Code (IaC) tool developed by HashiCorp. It allows users to define and provision datacenter infrastructure using a high-level configuration language known as <b>HashiCorp Configuration Language (HCL)</b>. Terraform supports a multitude of cloud providers (AWS, Azure, GCP, etc.) and on-premise solutions. Its core functionality revolves around managing the lifecycle of infrastructure: planning, applying, changing, and destroying resources predictably and efficiently. By treating infrastructure as code, Terraform enables version control, collaboration, and automated deployments, significantly reducing manual errors and improving operational consistency. It uses a state file to track the current state of managed resources, allowing it to determine necessary changes to reach the desired state defined in the configuration. This makes it ideal for managing complex, multi-cloud environments.


title: CAVEATS
content:
<b>State File Management:</b> <i>Terraform</i> relies heavily on a state file to track managed resources. Mismanagement or corruption of this file can lead to infrastructure drift, unintended changes, or data loss. Using remote state backends (e.g., S3, Azure Blob Storage, HashiCorp Cloud) with locking is highly recommended to prevent conflicts and ensure consistency.<br><br><b>Infrastructure Drift:</b> Manual changes made to infrastructure outside of <i>Terraform</i>'s control can lead to 'drift' between the actual state and <i>Terraform</i>'s recorded state, potentially causing unexpected behavior during subsequent <b>plan</b> or <b>apply</b> operations.<br><br><b>Provider Dependencies:</b> <i>Terraform</i>'s functionality is dependent on the features and stability of its various cloud and service providers. Some bleeding-edge features of cloud services might not be immediately available via <i>Terraform</i> providers.


title: HASHICORP CONFIGURATION LANGUAGE (HCL)
content:
<i>Terraform</i> configurations are written in HCL, a declarative language designed to be both human-readable and machine-friendly. HCL allows users to define resources, data sources, variables, outputs, and modules in a structured, consistent manner across different providers.


title: THE <I>TERRAFORM</I> STATE FILE
content:
The state file (typically <i>terraform.tfstate</i>) is a crucial component that maps real-world resources to your configuration. <i>Terraform</i> uses this file to understand the current state of your infrastructure, track metadata about managed resources, and plan changes to reach the desired state defined in your configuration. It's critical to manage this file carefully, especially in team environments, often by storing it remotely.


title: PROVIDERS AND MODULES
content:
<b>Providers</b> are plugins that enable <i>Terraform</i> to interact with various cloud platforms (e.g., AWS, Azure, GCP) and other services (e.g., Kubernetes, Docker, DNS). They expose resources and data sources for <i>Terraform</i> to manage. <b>Modules</b> are self-contained <i>Terraform</i> configurations that can be reused across different projects or within the same project, promoting organization, reusability, and best practices.


title: HISTORY
content:
<i>Terraform</i> was first publicly released by HashiCorp in July 2014. It emerged as a groundbreaking tool for provisioning and managing cloud infrastructure using a declarative approach, distinguishing itself with its vendor-agnostic nature and extensibility through a vast ecosystem of providers. Its adoption grew rapidly among DevOps and SRE teams due to its ability to manage infrastructure as code, enabling version control, collaboration, and automated deployments. Over the years, <i>Terraform</i> has continuously evolved, introducing key features like modules for reusability, workspaces for isolating environments, and robust remote state backends with locking, solidifying its position as a cornerstone tool for modern infrastructure automation and multi-cloud management.


title: PARAMETERS
content:
<b><b>-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the input files are already formatted. The command exits with a non-zero status code (3) if any files are not correctly formatted, making it suitable for CI/CD pipelines.<br><br><b><b>-diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the differences (diff) between the current file content and what <i>terraform fmt</i> would produce, without applying any changes to the files.<br><br><b><b>-list=false</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;By default (<i>-list=true</i>), <i>terraform fmt</i> lists the names of files whose formatting would change. Setting this to <i>false</i> suppresses that output.<br><br><b><b>-write=false</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;By default (<i>-write=true</i>), <i>terraform fmt</i> writes the formatted content back to the original files. Setting this to <i>false</i> prevents in-place modification, useful when combined with <i>-diff</i> or <i>-check</i>.<br><br><b><b>-recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively formats files in subdirectories. This is the default behavior when no specific paths are provided or when a directory path is given. This flag can be set to <i>-recursive=false</i> to prevent recursion.<br><br><b><b>-compact</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>-check</i> or <i>-diff</i>, output only filenames to stdout, one per line. This is particularly useful for scripting.<br><br><b><b>-no-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable color output in the console.<br><br><b><b>-json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output machine-readable JSON for <i>-check</i> or <i>-diff</i> results. This is useful for programmatic integration.<br><br>


title: DESCRIPTION
content:
The <i>terraform fmt</i> command is a crucial utility for maintaining consistent code style and readability in Terraform configurations. It automatically rewrites Terraform configuration files (<i>.tf</i>, <i>.tfvars</i>, and <i>.tf.json</i>) to a canonical format, ensuring adherence to standard indentation, spacing, and line breaking rules. This helps improve readability, reduces merge conflicts in version control systems, and enforces a common style across teams.<br><br>By default, <i>terraform fmt</i> processes all relevant files in the current directory and its subdirectories recursively, applying changes in-place. It's an idempotent operation, meaning running it multiple times on the same files will produce the same result once formatted. While it ensures stylistic consistency, it does not validate the syntax or configuration logic beyond what's necessary for parsing the HCL.


title: CAVEATS
content:
<i>terraform fmt</i> modifies files in place by default. It's highly recommended to use version control (e.g., Git) to manage your Terraform configurations and commit changes before running <i>fmt</i>, or to use the <i>-diff</i> or <i>-check</i> flags first to preview changes. The command aims to enforce a single, opinionated style and does not offer options for custom formatting rules.


title: DEFAULT BEHAVIOR
content:
If no specific paths are provided, <i>terraform fmt</i> defaults to recursively finding and formatting all <i>.tf</i>, <i>.tfvars</i>, and <i>.tf.json</i> files within the current working directory and its subdirectories. It writes changes directly to these files.


title: EXIT CODES
content:
The command can return different exit codes:<br><b>0</b>: Success; files were formatted or were already correctly formatted.<br><b>1</b>: An error occurred during execution (e.g., syntax error in a file, I/O error).<br><b>3</b>: Used specifically with the <i>-check</i> flag; indicates that one or more files were not correctly formatted according to <i>terraform fmt</i>'s rules.


title: HISTORY
content:
The <i>terraform fmt</i> command has been an integral part of the Terraform CLI since its early versions, evolving alongside the HashiCorp Configuration Language (HCL). Its introduction simplified codebase maintenance for individual users and, more importantly, enabled large teams to enforce a consistent coding style, which became critical as Terraform adoption grew for managing complex infrastructure across various cloud providers.


title: PARAMETERS
content:
<b>-json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the values in a machine-readable JSON format. If a specific output <b>NAME</b> is provided, it outputs a JSON string for that value; otherwise, it outputs a JSON object containing all outputs.<br><br><b>-raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When requesting a single output value that is a string, this option prints the raw string value without any extra quotes or formatting. This is particularly useful for piping the output directly into other shell commands.<br><br><b>-state=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Terraform state file (e.g., <i>terraform.tfstate</i>) to read output values from. If omitted, Terraform will use the default state file in the current working directory or the configured remote state.<br><br><b>-no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colorized output. Useful for logs or environments where color output is not desired or supported.<br><br><b>NAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument to specify a single output variable by its name to display. If omitted, all output variables defined in the state file will be displayed.<br><br>


title: DESCRIPTION
content:
The <b>terraform output</b> command is used to extract and display the output values from a Terraform state file. These output values are defined within your Terraform configuration (<i>.tf</i> files) using the <b>output</b> block and typically represent important information about the infrastructure provisioned, such as IP addresses, DNS names, or resource IDs.<br><br>This command is crucial for interacting with deployed infrastructure, integrating Terraform with other automation tools, or passing data between different Terraform configurations. By default, it prints all defined output values in a human-readable format. However, it also supports a machine-readable JSON format, making it suitable for scripting and programmatic access to infrastructure details. It retrieves information from the local <i>terraform.tfstate</i> file by default, but can also specify a different state file or interact with remote state if configured.


title: CAVEATS
content:
The <b>terraform output</b> command relies on a valid and accessible Terraform state file. If the state file is corrupted, missing, or if the Terraform configuration has not been applied (meaning no state exists), the command will fail. Care should be taken when using outputs that might contain sensitive information (e.g., passwords, API keys); while Terraform can mark outputs as sensitive to redact them in console output, they are still present in the state file. Always use the <b>-json</b> flag for programmatic parsing to avoid issues with human-readable formatting variations.


title: USAGE EXAMPLES
content:
<b>Display all outputs:</b><br><pre><code>terraform output</code></pre><br><b>Display a specific output value:</b><br><pre><code>terraform output public_ip</code></pre><br><b>Display a specific output in raw format (useful for piping):</b><br><pre><code>terraform output -raw instance_id > instance.txt</code></pre><br><b>Display all outputs as JSON:</b><br><pre><code>terraform output -json</code></pre><br><b>Extract a specific JSON value using jq:</b><br><pre><code>terraform output -json | jq -r '.vpc_id.value'</code></pre>


title: OUTPUT FORMATS
content:
By default, <b>terraform output</b> produces human-readable output, which is easy to scan but can be challenging to parse programmatically. The <b>-json</b> flag is highly recommended for scripting or integrating with other tools, as it provides a stable and predictable JSON structure. When a single output is requested with <b>-json</b>, it outputs just the JSON string representing that value (e.g., <code>"my-string"</code>); when all outputs are requested, it outputs a JSON object where keys are output names and values are objects containing <b>value</b>, <b>type</b>, and <b>sensitive</b> attributes.


title: HISTORY
content:
The <b>output</b> command has been a fundamental part of Terraform since its initial public release by HashiCorp in 2014. It was designed from the outset to serve as the primary mechanism for extracting valuable information about deployed infrastructure from the Terraform state, enabling introspection, integration with other systems, and chained automation workflows. Its core functionality has remained consistent, though enhancements like the <b>-json</b> flag have been added over time to improve its utility in scripting and API interactions.


title: SYNOPSIS
content:
<pre><b>terraform plan</b> [<i>options</i>] [<i>DIRECTORY</i>]<br><b>terraform plan</b> [<i>options</i>] <i>PLAN_FILE</i></pre>


title: PARAMETERS
content:
<b><b>-out=FILE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the generated plan to a specified file, allowing it to be used later with `terraform apply FILE`.<br><br><b><b>-destroy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a plan to destroy all managed remote objects, effectively tearing down the infrastructure.<br><br><b><b>-refresh=false</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the state refresh before generating the plan, using only the existing state file.<br><br><b><b>-var 'key=value'</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a variable for the plan, overriding variables defined elsewhere. Can be used multiple times.<br><br><b><b>-var-file=PATH</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads variables from a specified file (e.g., `terraform.tfvars`). Can be used multiple times.<br><br><b><b>-input=false</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables interactive prompts for input variables.<br><br><b><b>-lock=false</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables state locking for the duration of the plan. Use with caution.<br><br><b><b>-detailed-exitcode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Returns a detailed exit code: 0=no changes, 1=error, 2=changes proposed. Useful for scripting.<br><br><b><b>-json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the plan in machine-readable JSON format.<br><br><b><b>-target=RESOURCE_ADDRESS</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs Terraform to only plan changes to the specified resource or module. Use sparingly, primarily for recovery.<br><br><b><b>-replace=RESOURCE_ADDRESS</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks a specific resource instance to be replaced (destroyed and re-created). Use sparingly for specific scenarios.<br><br><b><b>-compact-warnings</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows warnings more compactly, only displaying the summary.<br><br><b><b>-refresh-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only refreshes the state without planning any configuration changes or proposing new actions.<br><br>


title: DESCRIPTION
content:
The <b>terraform plan</b> command is a fundamental component of the Terraform workflow, providing a crucial "dry run" capability. It computes the differences between your Terraform configuration files, the current state of your infrastructure (as recorded in the Terraform state file), and the actual state of the remote infrastructure providers. The primary purpose of `terraform plan` is to show you <i>exactly what actions Terraform will take</i> if you were to proceed with a `terraform apply` command. This includes creating new resources, updating existing ones, or destroying resources that are no longer defined or have been marked for deletion. It allows for a thorough review of proposed changes, helping to prevent unintended modifications or costly errors before they are committed to your live environment. The output clearly outlines each planned operation, making it an indispensable tool for validation, collaboration, and ensuring infrastructure stability.


title: CAVEATS
content:
A plan is a <i>prediction</i>: The actual `terraform apply` execution might differ if external factors change between `plan` and `apply` (e.g., manual modifications, race conditions on cloud resources).<br>Use `<b>-target</b>` and `<b>-replace</b>` options with extreme caution. They can lead to state drift and are generally intended for recovery or specific targeted operations rather than routine usage.<br>Sensitive data in your configuration, if not properly marked with `sensitive = true`, might be displayed in the plan output.


title: CI/CD INTEGRATION
content:
`terraform plan` is critical in automated CI/CD pipelines. By running `plan` with `<b>-detailed-exitcode</b>`, pipelines can automatically determine if infrastructure changes are proposed (exit code 2) and require manual review or if no changes are necessary (exit code 0).


title: SECURITY REVIEW
content:
The plan output serves as an audit trail and a valuable artifact for security and compliance reviews, ensuring that proposed infrastructure changes align with organizational policies.


title: HISTORY
content:
The `<b>terraform plan</b>` command has been a core and indispensable part of the Terraform CLI since its early days. Introduced as a fundamental safety mechanism, it underpins Terraform's "infrastructure as code" paradigm by allowing users to preview and approve infrastructure changes before they are applied. Its evolution has focused on providing clearer output, more control over execution (e.g., `-target`, `-replace`), and integration with CI/CD systems through features like detailed exit codes and JSON output.


title: SYNOPSIS
content:
terragrunt [GLOBAL_OPTIONS] <COMMAND> [COMMAND_OPTIONS]<br>terragrunt <COMMAND> [COMMAND_OPTIONS] [PATH]


title: PARAMETERS
content:
<b>--terragrunt-non-interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Disables all interactive prompts, essential for automation and CI/CD pipelines.<br><br><b>--terragrunt-config <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Specifies the path to the main <B>terragrunt.hcl</B> configuration file.<br><br><b>--terragrunt-source <URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Downloads Terraform code from a remote URL (e.g., Git repository) before execution.<br><br><b>--terragrunt-source-update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Forces Terragrunt to delete and re-download the Terraform source code.<br><br><b>--terragrunt-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Enables verbose debug logging, useful for troubleshooting issues.<br><br><b>--terragrunt-log-level <LEVEL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Sets the logging verbosity level (e.g., <B>info</B>, <B>warn</B>, <B>error</B>, <B>debug</B>).<br><br><b>--terragrunt-override-attr <KEY=VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Overrides a specific attribute within the <B>terragrunt.hcl</B> configuration file.<br><br><b>--terragrunt-fetch-dependencies</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Ensures that all module dependencies are downloaded and processed before execution.<br><br><b>--terragrunt-ignore-dependency-errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Global</I>: Allows <B>run-all</B> commands to continue execution even if a dependency module encounters an error.<br><br><b>apply</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Executes <B>terraform apply</B> after Terragrunt has prepared the environment, creating or updating infrastructure.<br><br><b>plan</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Executes <B>terraform plan</B> after Terragrunt setup, showing the planned infrastructure changes without applying them.<br><br><b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Initializes the Terraform working directory and configures the backend based on the <B>terragrunt.hcl</B> settings.<br><br><b>destroy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Executes <B>terraform destroy</B> after Terragrunt setup, to tear down Terraform-managed infrastructure.<br><br><b>run-all <COMMAND></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Runs a specified Terragrunt command (<B>apply</B>, <B>plan</B>, <B>destroy</B>, etc.) across all modules in the current directory hierarchy, respecting dependencies.<br><br><b>hclfmt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Formats Terragrunt HCL configuration files to a consistent, canonical style.<br><br><b>validate-inputs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Checks if all required inputs for the current Terraform module are correctly defined and provided via Terragrunt.<br><br><b>terragrunt-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Command</I>: Displays useful information about the current Terragrunt environment, including version, working directory, and parsed configuration.<br><br>


title: DESCRIPTION
content:
Terragrunt is a thin wrapper for <B>Terraform</B> that provides extra tools for working with Terraform configurations. Its primary goal is to keep your Terraform code <I>DRY</I> (Don't Repeat Yourself) by allowing you to define common configurations, such as remote state, providers, and backend settings, just once at a higher level and then inherit them across multiple environments and modules.<br><br>It solves challenges related to orchestrating multiple Terraform modules, managing dependencies between them, and handling remote state configuration in a more robust and consistent manner. Terragrunt achieves this by dynamically generating Terraform configuration files, executing Terraform commands, and providing features like dependency management (running modules in the correct order), enforcing remote state configuration, and automating backend initialization. It aims to reduce boilerplate, improve maintainability, and ensure consistency across large infrastructure projects built with Terraform.


title: CAVEATS
content:
Terragrunt introduces an additional abstraction layer over Terraform, which can sometimes increase the learning curve for new users. Debugging issues might require understanding both Terragrunt's behavior and the underlying Terraform commands. Complex <B>run-all</B> orchestrations might require careful dependency management to avoid unexpected behavior or state inconsistencies. It is opinionated about directory structure, which might require adapting existing Terraform layouts.


title: TERRAGRUNT CONFIGURATION FILES (<B>TERRAGRUNT.HCL</B>)
content:
These HCL-based files are the core of Terragrunt's configuration. They define how Terragrunt should interact with your Terraform modules, specifying properties like the source path of the Terraform code, input variables, remote state backend configurations, and explicit dependencies on other Terragrunt modules. They allow for powerful inheritance and variable interpolation.


title: DRY PRINCIPLE ENFORCEMENT
content:
Terragrunt's most significant benefit is its ability to enforce the <B>D</B>on't <B>R</B>epeat <B>Y</B>ourself (DRY) principle. It achieves this by allowing common configurations (e.g., AWS region, S3 backend settings, common tags) to be defined once at a higher level in the directory hierarchy and then automatically inherited by all child modules. This significantly reduces boilerplate code and improves consistency and maintainability across large infrastructure projects.


title: MODULE DEPENDENCY MANAGEMENT
content:
Terragrunt offers robust dependency management, allowing users to define explicit relationships between different Terraform modules. When using commands like <B>run-all</B>, Terragrunt automatically determines the correct order of execution for modules based on their dependencies, ensuring that resources are provisioned or destroyed in the correct sequence (e.g., a VPC must exist before subnets or EC2 instances are deployed within it).


title: HISTORY
content:
Terragrunt was developed by Gruntwork, a company specializing in DevOps and infrastructure-as-code. It was first released in 2016, motivated by the challenges of managing large, complex, and enterprise-grade Terraform deployments. Its core purpose was to address the lack of built-in features in Terraform for enforcing DRY principles, managing remote state consistently across environments, and orchestrating multiple interdependent modules efficiently. Since its inception, Terragrunt has evolved to become a popular companion tool for Terraform, especially in organizations with extensive infrastructure setups.


title: SYNOPSIS
content:
<b>TerrariaServer</b> [<i>options</i>]<br>or<br><b>mono</b> <i>TerrariaServer.exe</i> [<i>options</i>]


title: PARAMETERS
content:
<b><b>-port</b> <i><port></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network port for the server to listen on (default: 7777).<br><br><b><b>-world</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the path to the <i>.wld</i> file of the world to load. If the path does not exist, a new world will be created based on other parameters.<br><br><b><b>-maxplayers</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the maximum number of players that can connect to the server (1-255).<br><br><b><b>-autocreate</b> <i><size></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically creates a new world if the specified world does not exist.<br><i><size></i>: 1 (Small), 2 (Medium), 3 (Large).<br><br><b><b>-worldname</b> <i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the name for a newly autocreated world.<br><br><b><b>-difficulty</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the difficulty for a newly autocreated world.<br><i><num></i>: 0 (Journey), 1 (Classic), 2 (Expert), 3 (Master).<br><br><b><b>-seed</b> <i><seed></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the world seed for a newly autocreated world.<br><br><b><b>-password</b> <i><pass></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a password required for players to join the server.<br><br><b><b>-config</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads server settings from a specified configuration file (e.g., <i>serverconfig.txt</i>).<br><br><b><b>-secure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables anti-cheat protection for the server.<br><br><b><b>-banlist</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the ban list file.<br><br><b><b>-ip</b> <i><ip_address></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Binds the server to a specific IP address on the host machine.<br><br><b><b>-nologo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the display of the Terraria server logo on startup.<br><br><b><b>-logpath</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory to store server log files.<br><br><b><b>-players</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <b>-maxplayers</b>.<br><br><b><b>-autoshutdown</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables automatic server shutdown when no players are connected for a period.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of available command-line arguments and their descriptions.<br><br>


title: DESCRIPTION
content:
The <b>Terraria Dedicated Server</b> is a command-line application used to host multiplayer games of the popular 2D sandbox adventure game, <i>Terraria</i>. Unlike the game client which provides a graphical interface, the dedicated server runs in a console environment, providing stable and persistent game worlds for multiple players to connect to. On Linux, it often runs using the Mono runtime or as a native .NET application. It allows administrators to manage world settings, player connections, and server behavior without needing to run the game client itself. This is the primary "command-line" interaction point for Terraria on Linux, enabling server administrators to automate game world management and provide a reliable multiplayer experience.


title: CAVEATS
content:
The `terraria` command is not a standard Linux system utility. It refers specifically to the game's dedicated server application. The exact executable name can vary (e.g., <i>TerrariaServer.exe</i>, <i>TerrariaServer.x86_64</i>) depending on the distribution method (Steam, direct download) and whether it's run via Mono or a native .NET runtime. The game client itself, when launched graphically, typically does not accept these command-line parameters for gameplay settings.


title: CONFIGURATION FILES
content:
Server settings can be permanently stored and loaded from a text file, typically named <i>serverconfig.txt</i>. This file allows for more complex and persistent configurations than command-line arguments alone, including lists of banned players, server messages, and advanced world generation options.


title: IN-GAME SERVER COMMANDS
content:
Once the server is running, administrators can interact with it directly through its console by typing commands such as <b>save</b> (to save the world), <b>exit</b> (to shut down the server), <b>kick</b> <i><playername></i> (to remove a player), and <b>ban</b> <i><playername></i> (to permanently block a player from joining).


title: HISTORY
content:
<i>Terraria</i> was first released in 2011, with its dedicated server software becoming a crucial component for multiplayer gameplay. Over the years, the server application has evolved alongside the game, receiving updates for new content, bug fixes, and performance improvements. Its cross-platform nature, including support for Linux, has made it a popular choice for hosting persistent game worlds globally, leveraging the stability and efficiency of Linux servers.


title: PARAMETERS
content:
<b><b>-b</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a block special file.<br><br><b><b>-c</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a character special file.<br><br><b><b>-d</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a directory.<br><br><b><b>-e</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists.<br><br><b><b>-f</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a regular file.<br><br><b><b>-g</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and its set-group-ID bit is set.<br><br><b><b>-h</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a symbolic link (same as <b>-L</b>).<br><br><b><b>-k</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and its sticky bit is set.<br><br><b><b>-L</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a symbolic link (same as <b>-h</b>).<br><br><b><b>-p</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a named pipe (FIFO).<br><br><b><b>-r</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is readable by the current user.<br><br><b><b>-s</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and has a size greater than zero.<br><br><b><b>-S</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a socket.<br><br><b><b>-t</b> <I>FD</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if file descriptor <I>FD</I> (default 1) is open and refers to a terminal.<br><br><b><b>-u</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and its set-user-ID bit is set.<br><br><b><b>-w</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is writable by the current user.<br><br><b><b>-x</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is executable by the current user.<br><br><b><b>-O</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is owned by the effective user ID.<br><br><b><b>-G</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is owned by the effective group ID.<br><br><b><b>-N</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and has been modified since it was last read.<br><br><b><b><I>STRING</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>STRING</I> is not empty.<br><br><b><b>-z</b> <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the length of <I>STRING</I> is zero.<br><br><b><b>-n</b> <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the length of <I>STRING</I> is non-zero (same as just <I>STRING</I>).<br><br><b><b><I>STRING1</I> = <I>STRING2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the strings <I>STRING1</I> and <I>STRING2</I> are equal.<br><br><b><b><I>STRING1</I> != <I>STRING2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the strings <I>STRING1</I> and <I>STRING2</I> are not equal.<br><br><b><b><I>INT1</I> -eq <I>INT2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the integers <I>INT1</I> and <I>INT2</I> are arithmetically equal.<br><br><b><b><I>INT1</I> -ne <I>INT2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the integers <I>INT1</I> and <I>INT2</I> are not arithmetically equal.<br><br><b><b><I>INT1</I> -gt <I>INT2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the integer <I>INT1</I> is arithmetically greater than <I>INT2</I>.<br><br><b><b><I>INT1</I> -ge <I>INT2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the integer <I>INT1</I> is arithmetically greater than or equal to <I>INT2</I>.<br><br><b><b><I>INT1</I> -lt <I>INT2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the integer <I>INT1</I> is arithmetically less than <I>INT2</I>.<br><br><b><b><I>INT1</I> -le <I>INT2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the integer <I>INT1</I> is arithmetically less than or equal to <I>INT2</I>.<br><br><b><b>! <I>EXPRESSION</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>EXPRESSION</I> is false (logical negation).<br><br><b><b><I>EXP1</I> -a <I>EXP2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if both <I>EXP1</I> and <I>EXP2</I> are true (logical AND).<br><br><b><b><I>EXP1</I> -o <I>EXP2</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if either <I>EXP1</I> or <I>EXP2</I> is true (logical OR).<br><br><b><b>( <I>EXPRESSION</I> )</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluates <I>EXPRESSION</I> as a single unit; parentheses must be escaped or quoted for the shell.<br><br>


title: DESCRIPTION
content:
The <b>test</b> command evaluates an <I>EXPRESSION</I> and returns an exit status of 0 (true) if the <I>EXPRESSION</I> is true, and 1 (false) if it is false. It is commonly used in shell scripts within <I>if</I>, <I>while</I>, or <I>until</I> statements to control program flow based on conditions. The <b>test</b> command is often invoked using its alias <b>[</b> (which requires a closing <b>]</b> as the last argument).<br><br>It supports various types of tests, including checking file attributes (e.g., if a file exists, is a directory, or is readable), comparing strings, and comparing numeric values. The command itself does not produce any output; its result is solely determined by its exit status. Understanding <b>test</b> is fundamental for writing robust and dynamic shell scripts that can make decisions based on different conditions in the environment. It is a POSIX standard utility, making it widely available across Unix-like systems.


title: CAVEATS
content:
The <b>test</b> command, especially when used as <b>[</b>, requires careful attention to spacing. Each operator and argument must be a separate word, meaning they need to be separated by spaces. For example, <b>[ "$VAR" = "value" ]</b> is correct, while <b>["$VAR"="value"]</b> is not.<br><br>String arguments should almost always be quoted (e.g., <b>"$VAR"</b>) to prevent issues with empty strings or strings containing spaces/special characters, which could lead to syntax errors or unexpected evaluation results. Numeric comparisons (e.g., <b>-eq</b>) only work with integers. Portability can be an issue with some less common operators or specific behaviors, as different shells might have slightly varied implementations, though the core POSIX standard operators are reliable.


title: EXIT STATUS
content:
The <b>test</b> command does not produce output to standard output or standard error. Its only result is its exit status: <b>0</b> (true) if the <I>EXPRESSION</I> evaluates to true, and <b>1</b> (false) if it evaluates to false. This exit status is then used by the shell to control flow in <b>if</b>, <b>while</b>, and <b>until</b> statements.


title: SHELL BUILT-IN
content:
While <b>test</b> exists as an executable in <b>/usr/bin/test</b> (or similar), it is almost always implemented as a built-in command within modern shells like Bash, Zsh, and Dash. This makes its execution significantly faster as it avoids the overhead of launching a new process, which is crucial for efficient script execution.


title: STRING QUOTING
content:
When using <b>test</b> with string variables, it is a common best practice to quote the variables (e.g., <b>[ -f "$FILE" ]</b> or <b>[ "$VAR" = "hello" ]</b>). This prevents unexpected behavior if the variable is empty or contains spaces, tabs, or other special characters, which could otherwise be interpreted as separate arguments to <b>test</b>.


title: HISTORY
content:
The <b>test</b> command has been a fundamental part of Unix-like operating systems since their early development. It was included in the <I>Seventh Edition Unix</I> (V7) in 1979. Its alternative name, <b>[</b>, was introduced later, primarily for syntactic sugar in shell scripting to make conditional statements resemble more conventional programming language constructs. Over time, <b>test</b> became a core utility specified by the <I>POSIX standard</I>, ensuring its widespread availability and consistent behavior across various Unix and Linux distributions. Many modern shells implement <b>test</b> as a built-in command for performance reasons, avoiding the overhead of spawning an external process.


title: PARAMETERS
content:
<b><I>device_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a block device (e.g., <I>/dev/sda</I>, <I>/dev/nvme0n1</I>) to be analyzed for partition recovery or boot sector repair. If omitted, <b>TestDisk</b> will present an interactive list of detected disks to choose from.<br><br><b><I>disk_image</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the path to a raw disk image file (e.g., <I>my_disk.img</I>, <I>backup.dd</I>) to perform recovery operations on. This is highly recommended as a non-destructive way to work on a copy of the problematic disk.<br><br>


title: DESCRIPTION
content:
<b>TestDisk</b> is a powerful, free, and open-source data recovery utility primarily designed to help recover lost partitions and/or make non-booting disks bootable again. It is highly effective when these issues are caused by faulty software, certain types of viruses, or human error, such as accidentally deleting a Partition Table.<br><br>It supports a wide range of file systems, including FAT, NTFS, ext2/3/4, HFS+, JFS, XFS, and more. Key functionalities include: finding lost partitions, recovering damaged boot sectors (especially for FAT/NTFS), fixing corrupted Master File Tables (MFT) for NTFS, recovering deleted files from FAT, NTFS, and ext2 filesystems, and copying files from deleted partitions.<br><br><b>TestDisk</b> operates by analyzing the disk structure, identifying potential partition entries, and then allowing the user to write a new, corrected partition table. Its interactive, menu-driven interface makes it accessible, though a basic understanding of disk partitioning is beneficial.


title: CAVEATS
content:
Using <b>TestDisk</b> incorrectly can lead to further data corruption or permanent data loss. <I>Always</I> back up critical data before attempting any recovery operations. It is highly recommended to run <b>TestDisk</b> from a live operating system (e.g., a Live CD/USB) to prevent any writes to the affected disk during the recovery process. While user-friendly, a basic understanding of disk partitioning, file systems, and the underlying data structures is beneficial for successful recovery.


title: INTERACTIVE OPERATION
content:
<b>TestDisk</b> operates primarily through an interactive, menu-driven interface. Upon execution, it guides the user step-by-step through disk selection, analysis of partition structures, searching for lost partitions, and finally, the option to write changes to the disk or recover files. This interactive nature makes it accessible even without memorizing complex command-line arguments.


title: READ-ONLY ANALYSIS
content:
By default, <b>TestDisk</b> performs a read-only analysis of the disk. No changes are written to the disk unless explicitly confirmed by the user, usually by selecting the <I>[ Write ]</I> option. This crucial safety feature helps prevent accidental data corruption during the recovery process. It is always advised to verify detected partitions and choose actions carefully.


title: LOG FILE GENERATION
content:
<b>TestDisk</b> automatically creates a <I>testdisk.log</I> file in the directory from which it was executed. This log file records all actions performed and messages displayed during the session, which can be invaluable for troubleshooting, resuming interrupted operations, or for seeking expert assistance.


title: HISTORY
content:
<b>TestDisk</b> was developed by Christophe Grenier and first released in 2002. It emerged as a powerful, free, and open-source solution for partition recovery, addressing a critical need for users across various operating systems, including Linux, Windows, and macOS. Its companion utility, <b>PhotoRec</b> (for file carving), was developed shortly thereafter. The project has seen continuous development and updates, maintaining its relevance and effectiveness in the data recovery landscape.


title: SYNOPSIS
content:
<b>st-flash</b> [<i>OPTIONS</i>] <i><COMMAND></i> [<i>ARGS...</i>]<br><br><b>Common Commands:</b><br>&nbsp;&nbsp;<b>st-flash</b> write <i><path/to/file.bin> <address></i><br>&nbsp;&nbsp;<b>st-flash</b> write <i><path/to/file.hex></i><br>&nbsp;&nbsp;<b>st-flash</b> read <i><path/to/output.bin> <address> <size></i><br>&nbsp;&nbsp;<b>st-flash</b> erase<br>&nbsp;&nbsp;<b>st-flash</b> reset<br>&nbsp;&nbsp;<b>st-flash</b> info


title: PARAMETERS
content:
<b>write <path/to/file> [address]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes a binary or Intel HEX file to the target's flash memory. For binary files, a hexadecimal <i>address</i> is required.<br><br><b>read <path/to/output.bin> <address> <size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads <i>size</i> bytes from the specified <i>address</i> on the target and saves them to a binary file.<br><br><b>erase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Erases the entire flash memory of the connected STM32 microcontroller.<br><br><b>reset</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the target microcontroller, typically causing it to start execution from the beginning of its firmware.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about the connected ST-LINK debug probe and the target STM32 microcontroller.<br><br><b>--format <fmt></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file format (e.g., 'binary', 'ihex'). Usually auto-detected from file extension.<br><br><b>--flash=<size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually specifies the flash size of the target in bytes. Useful if auto-detection fails.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output, showing more details about the communication and operations.<br><br><b>--area=<name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the memory area for read/write operations (e.g., 'flash', 'sram', 'option').<br><br><b>--connect-under-reset</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Holds the target microcontroller in reset during the connection process.<br><br><b>--serial <serial_number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific ST-LINK by its serial number when multiple probes are connected.<br><br><b>--port <port_number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the TCP/IP port number for network-connected ST-LINK probes (e.g., ST-LINK/V3E).<br><br>


title: DESCRIPTION
content:
<i>st-flash</i> is a command-line utility from the <br><b>stlink</b> open-source project, designed for programming and interacting with STM32 microcontrollers. It provides functionalities to write firmware images (e.g., .bin, .hex files) to the device's flash memory, read memory contents, erase the chip, and verify written data. It communicates with the STM32 target through ST-LINK debug probes (V1, V2, V3) connected via USB. Supporting various flash memory types and sizes found in STM32 families, <i>st-flash</i> is an essential tool for embedded developers working with STM32 MCUs, especially in Linux environments.


title: CAVEATS
content:
<b>Permissions:</b> <i>st-flash</i> often requires root privileges or proper <br><i>udev</i> rules configured to access the ST-LINK USB device.<br><b>ST-LINK Versions:</b> Compatibility and feature support can vary between ST-LINK V1, V2, and V3 probes.<br><b>Flash Protection:</b> Operations like reading or writing protected memory regions may fail unless the protection is first disabled using specific commands or tools.<br><b>Device Support:</b> While widely compatible, newer STM32 microcontroller series might require an updated version of the <i>stlink</i> package.


title: SUPPORTED FILE FORMATS
content:
<i>st-flash</i> primarily supports raw binary (.bin) and Intel HEX (.hex) file formats. When writing an Intel HEX file, the address information is embedded within the file itself, so an explicit address argument is not needed.


title: MEMORY AREA TARGETING
content:
Beyond the main flash memory, <i>st-flash</i> can interact with other memory areas on the STM32, such as SRAM for temporary data transfer or option bytes for configuration, by using the <i>--area</i> flag.


title: HISTORY
content:
<i>st-flash</i> is a core component of the <br><b>stlink</b> open-source project, which originated as a community-driven effort to provide cross-platform (Linux/macOS) support for ST-LINK debug probes. Before its existence, official ST-LINK tools were primarily Windows-based. Over time, it has evolved significantly, adding robust support for various ST-LINK versions and a wide array of STM32 microcontroller families, establishing itself as a de-facto standard command-line tool for embedded development on Linux systems.


title: PARAMETERS
content:
<b><I>checkout</I> (co)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Checks out a working copy from a repository.</I><br><br><b><I>update</I> (up)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Updates a working copy to the latest revision or a specific revision.</I><br><br><b><I>commit</I> (ci)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sends changes from a working copy to the repository.</I><br><br><b><I>add</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Adds files or directories to version control.</I><br><br><b><I>delete</I> (del, rm)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Deletes files or directories from version control.</I><br><br><b><I>status</I> (st, stat)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prints the status of working copy files and directories.</I><br><br><b><I>log</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Shows log messages for revisions.</I><br><br><b><I>diff</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Compares changes between revisions or a working copy and a revision.</I><br><br><b><I>info</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays information about a working copy item or URL.</I><br><br><b><I>merge</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Merges changes from one branch to another.</I><br><br><b><I>copy</I> (cp)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Copies files or directories (often used for branching/tagging).</I><br><br><b><I>help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays help on a subcommand or general usage.</I><br><br><b><I>--username &lt;arg&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies a username for authentication.</I><br><br><b><I>--password &lt;arg&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies a password for authentication.</I><br><br>


title: DESCRIPTION
content:
<I>The <b>svn</b> command is the primary command-line client for Apache Subversion, a centralized version control system. It allows users to interact with Subversion repositories to manage and track changes to files and directories over time. Key functionalities include checking out code from a repository, updating a working copy with the latest changes, committing local modifications, managing branches and tags, and merging changes between different lines of development. Subversion excels in collaborative environments by providing a robust system for managing revisions, resolving conflicts, and maintaining a complete history of project files. It operates on a client-server model, where a central repository stores all versions of the project data.</I>


title: CAVEATS
content:
<I>Being a centralized version control system, <b>svn</b> relies on a single repository server, which can be a single point of failure. It typically requires an active network connection for most operations like committing or updating, which can be a limitation in offline scenarios. Merging complex histories, particularly across multiple branches, can sometimes be challenging and require careful handling. While robust, its performance on very large repositories or with numerous binary files can sometimes be slower compared to distributed systems.</I>


title: <I>WORKING COPIES AND REPOSITORIES</I>
content:
<I><b>svn</b> operates by allowing users to create local "working copies" of files and directories from a central "repository". The repository stores the complete history of all project files, while the working copy is where users make their local changes. Operations like <b>checkout</b> create a working copy, <b>update</b> synchronizes it with the repository, and <b>commit</b> sends local changes back to the repository.</I>


title: <I>REVISIONS AND ATOMIC COMMITS</I>
content:
<I>Every time changes are committed to a Subversion repository, a new global "revision" number is assigned to the entire repository. This means all changes committed together form a single, atomic transaction; either all changes succeed, or none do. This atomic commit model ensures that the repository's state is always consistent, making it easier to track changes and revert to previous states.</I>


title: HISTORY
content:
<I>Apache Subversion was initiated in 2000 by CollabNet, aiming to replace CVS (Concurrent Versions System) by addressing its limitations while retaining its centralized model. The first stable version, 1.0, was released in 2004. Subversion gained significant popularity throughout the 2000s, becoming the dominant version control system for many organizations and open-source projects. In 2010, it became a top-level project under the Apache Software Foundation. Although its widespread adoption has been eclipsed by distributed version control systems like Git in recent years, <b>svn</b> continues to be actively maintained and used in many established projects and enterprise environments globally.</I>


title: SYNOPSIS
content:
<b>tc qdisc</b> { <b>add</b> | <b>change</b> | <b>replace</b> | <b>del</b> } <b>dev</b> <i>&lt;DEV&gt;</i> { <b>root</b> | <b>parent</b> <i>&lt;HANDLE&gt;</i> } [<b>handle</b> <i>&lt;MAJOR&gt;</i>:] <b>netem</b> [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b><b>add</b> | <b>change</b> | <b>replace</b> | <b>del</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Action to perform on the queuing discipline: <b>add</b> a new qdisc, <b>change</b> an existing one, <b>replace</b> an existing one, or <b>del</b> (delete) it.<br><br><b><b>dev</b> <i>&lt;DEV&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface (e.g., <i>eth0</i>, <i>enp0s3</i>) on which to apply the <i>netem</i> emulation.<br><br><b><b>root</b> | <b>parent</b> <i>&lt;HANDLE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines where the <i>netem</i> qdisc is attached in the qdisc hierarchy. <b>root</b> attaches it at the top level of the interface's qdisc tree. <b>parent</b> <i>&lt;HANDLE&gt;</i> attaches it as a child of an existing qdisc identified by its handle.<br><br><b><b>handle</b> <i>&lt;MAJOR&gt;</i>:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a unique identifier (major number) to the <i>netem</i> qdisc, allowing it to be referenced by other <i>tc</i> commands or sub-qdiscs. This is optional if using <b>root</b> with no children.<br><br><b><b>delay</b> <i>&lt;TIME&gt;</i> [<i>JITTER</i> [<i>CORRELATION</i>]]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Introduces a specified latency to packets.<br><i>TIME</i>: The base delay in milliseconds (e.g., '100ms').<br><i>JITTER</i>: Optional; adds random variation to the delay (e.g., '20ms').<br><i>CORRELATION</i>: Optional; a percentage (0-100%) indicating how strongly the delay of one packet correlates with the next, creating burstier or smoother delay patterns.<br><br><b><b>distribution</b> { <b>normal</b> | <b>pareto</b> | <b>paretonormal</b> }</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the statistical distribution for delay values when <i>JITTER</i> is used, providing more realistic delay patterns than a uniform distribution.<br><br><b><b>loss</b> { <i>PERCENT</i> [<i>CORRELATION</i>] | <b>GONE</b> }</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates packet loss.<br><i>PERCENT</i>: The probability of a packet being dropped (e.g., '5%').<br><i>CORRELATION</i>: Optional; a percentage (0-100%) indicating the correlation between consecutive packet losses, simulating bursty loss.<br><b>GONE</b>: (Deprecated) Causes permanent packet loss for all subsequent packets.<br><br><b><b>duplicate</b> <i>PERCENT</i> [<i>CORRELATION</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Duplicates packets with a given probability.<br><i>PERCENT</i>: The percentage probability of duplicating a packet (e.g., '2%').<br><i>CORRELATION</i>: Optional; a percentage (0-100%) indicating correlation for duplication patterns.<br><br><b><b>corrupt</b> <i>PERCENT</i> [<i>CORRELATION</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Corrupts packets with a given probability (introduces bit errors).<br><i>PERCENT</i>: The percentage probability of a packet being corrupted (e.g., '0.1%').<br><i>CORRELATION</i>: Optional; a percentage (0-100%) indicating correlation for corruption patterns.<br><br><b><b>reorder</b> <i>PERCENT</i> [<i>CORRELATION</i>] [<b>gap</b> <i>JITTER</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reorders packets, sending some packets out of their original sequence.<br><i>PERCENT</i>: The probability that a packet will be sent immediately (out of order) rather than being delayed.<br><i>CORRELATION</i>: Optional; a percentage (0-100%) influencing the reordering pattern.<br><b>gap</b> <i>JITTER</i>: Optional; influences the gap between reordered packets.<br><br><b><b>rate</b> <i>RATE</i> [<b>PACKETOVERHEAD</b> <i>BYTES</i>] [<b>CELLSIZE</b> <i>BYTES</i>] [<b>CELLOVERHEAD</b> <i>BYTES</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Emulates a fixed bandwidth rate. This is a basic rate limiter within <i>netem</i>.<br><i>RATE</i>: The desired bandwidth, e.g., '1mbit', '512kbit'.<br>Additional parameters (<i>PACKETOVERHEAD</i>, <i>CELLSIZE</i>, <i>CELLOVERHEAD</i>) allow for fine-tuning the rate calculation based on network layer overheads and cell-based network characteristics.<br><br><b><b>ecn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Explicit Congestion Notification (ECN) marking for packets under congestion, rather than dropping them. Requires kernel support.<br><br>


title: DESCRIPTION
content:
<i>tc-netem</i> is a powerful queuing discipline (qdisc) within the Linux traffic control (<i>tc</i>) subsystem. Its primary purpose is to emulate various characteristics of real-world networks, enabling developers and testers to simulate adverse network conditions without needing a physically impaired network.<br><br><i>Netem</i> can introduce latency (delay), packet loss, packet corruption, packet duplication, and packet reordering. It can also emulate a fixed bandwidth rate. This functionality is invaluable for testing the robustness and performance of applications, network protocols, and services under non-ideal network scenarios, such as high-latency satellite links, unreliable wireless connections, or congested internet paths.<br><br>Typically applied to an egress (outgoing) network interface, <i>netem</i> manipulates packets as they leave the system. Its flexibility allows for fine-grained control over network impairments, making it a crucial tool for quality assurance, development, and research in network-dependent systems.


title: CAVEATS
content:
<ul><li><b>Egress Traffic Only:</b> <i>Netem</i> primarily affects outgoing (egress) traffic on the specified interface. To apply network emulation to incoming (ingress) traffic, it's typically necessary to use an <i>ifb</i> (Intermediate Functional Block) device in conjunction with an <i>ingress</i> qdisc to redirect ingress traffic for shaping.</li><li><b>Basic Rate Limiting:</b> While <i>netem</i> includes a <b>rate</b> parameter, for complex or precise bandwidth shaping scenarios, it is often more effective to combine <i>netem</i> with dedicated rate-limiting qdiscs like <i>tbf</i> (Token Bucket Filter) or <i>htb</i> (Hierarchical Token Bucket).</li><li><b>Root Privileges:</b> Configuring <i>netem</i> rules requires root privileges (specifically, the <i>CAP_NET_ADMIN</i> capability).</li></ul>


title: COMMON USE CASES
content:
<i>Netem</i> is widely used for:<br><ul><li>Simulating Wide Area Network (WAN) conditions to test applications designed for distributed environments.</li><li>Evaluating the resilience and performance of network protocols (e.g., TCP, UDP) under adverse conditions like high latency or packet loss.</li><li>Benchmarking software and services to understand their behavior and limitations when network quality degrades.</li><li>Developing and testing error-handling mechanisms in network-aware applications.</li></ul>


title: CLEARING NETEM RULES
content:
To remove all <i>netem</i> (or any other <b>root</b>) rules from an interface and restore its default traffic behavior, use the following command:<br><code><b>tc qdisc del dev </b><i>&lt;DEV&gt;</i><b> root</b></code><br>Replace <i>&lt;DEV&gt;</i> with the actual network interface name.


title: HISTORY
content:
<i>Netem</i> was developed by Stephen Hemminger and Jamal Hadi Salim, becoming a standard part of the Linux kernel's traffic control framework. It was introduced around the Linux kernel 2.6.x series, significantly enhancing the kernel's capabilities for network testing and research. Initially, it provided basic delay and packet loss simulation, but over time, its feature set expanded to include corruption, duplication, and reordering, making it a comprehensive tool for emulating a wide range of real-world network conditions.


title: SYNOPSIS
content:
<code>tcc</code> is invoked from the command line, typically followed by options and input files. <br><br><b>Compilation and Linking:</b><br><pre><code>tcc [<i>options</i>] <i>files</i>... [-o <i>outputfile</i>]</code></pre><br><b>Running C Scripts Directly:</b><br><pre><code>tcc -run [<i>options</i>] <i>c_script_file</i> [<i>script_arguments</i>...]</code></pre><br><b>Creating Shared Libraries:</b><br><pre><code>tcc -shared [<i>options</i>] <i>files</i>... [-o <i>output_library.so</i>]</code></pre>


title: PARAMETERS
content:
<b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile source files only, without linking. Produces object files (.o).<br><br><b>-o <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the output file (executable, library, or object file).<br><br><b>-I <i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>dir</i> to the list of directories to search for include files.<br><br><b>-L <i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>dir</i> to the list of directories to search for libraries.<br><br><b>-l <i>lib</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Link with the specified library <i>lib</i>. (e.g., -lm for math library).<br><br><b>-D <i>macro[=val]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define a preprocessor macro with an optional value.<br><br><b>-U <i>macro</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undefine a preprocessor macro.<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate debugging information (DWARF).<br><br><b>-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile and execute the first input file directly as a C script. Subsequent arguments are passed to the script.<br><br><b>-shared</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a shared library (.so) instead of an executable.<br><br><b>-static</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Link all libraries statically, producing a self-contained executable.<br><br><b>-Wall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable all common compiler warnings.<br><br><b>-Werror</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat all warnings as errors.<br><br><b>-std=<i>std</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the C standard to use (e.g., c99, c11). TCC primarily supports C99.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the compiler version and other verbose information.<br><br>


title: DESCRIPTION
content:
The <i>Tiny C Compiler</i> (<b>TCC</b>) is an extremely small, fast, and feature-rich C compiler designed by Fabrice Bellard. Unlike larger compilers like GCC or Clang, TCC emphasizes speed and a small memory footprint, making it ideal for rapid prototyping, embedded systems, and situations where compilation speed is paramount. <br><br>It supports the C99 standard and provides several unique features, including the ability to compile C code directly into machine code for immediate execution (Just-In-Time compilation) and compile C scripts directly, similar to how shell scripts are executed. TCC can output executables, shared libraries, or assembly files. While it may not produce code as highly optimized as GCC for complex applications, its rapid compilation times and compact size make it a valuable tool for specific use cases, including system bootstrapping, educational purposes, and lightweight development environments.


title: CAVEATS
content:
While powerful for its size, TCC has some limitations compared to full-featured compilers like GCC or Clang. It provides less aggressive code optimization, which might lead to slightly less performant binaries for complex applications. Its support for newer C standards (beyond C99) and certain exotic features may also be limited or incomplete. TCC might not be pre-installed on all Linux distributions.


title: JIT COMPILATION AND SCRIPTING
content:
One of TCC's most notable features is its built-in Just-In-Time (JIT) compiler. This allows TCC to compile C code into machine code in memory and execute it immediately, without creating intermediate object files or executables on disk. This capability, combined with the <b>-run</b> option, enables TCC to act as a powerful C script interpreter. You can add <code>#!/usr/bin/tcc -run</code> as the shebang line to a C source file, making it directly executable like any other script.


title: HISTORY
content:
TCC was originally developed by <i>Fabrice Bellard</i>, a renowned French computer programmer known for his many innovative projects. The first public release was around 2002. Bellard created TCC with the goal of producing an extremely small and fast C compiler, capable of compiling itself and being used in scenarios where resource constraints or rapid compilation were critical. Its unique JIT compilation capabilities and ability to execute C files directly as scripts distinguish it from other compilers. It has found niches in embedded systems, booting environments, and as a lightweight alternative for educational purposes or quick experiments.


title: PARAMETERS
content:
<b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the end of options. All subsequent arguments are treated as file names or script arguments, even if they start with a hyphen.<br><br><b><b>--encoding</b> <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the encoding of the script file. For example, <i>utf-8</i>. This ensures the script is read correctly.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Tcl version number (e.g., 8.5) and then exits, providing quick version information.<br><br><b><i>fileName</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to a Tcl script file to be executed. If omitted, <b>tclsh</b> enters interactive mode, prompting for commands.<br><br><b><i>arguments</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any additional arguments passed on the command line after the script file name. These are made available to the Tcl script via the <i>argv</i> global variable.<br><br>


title: DESCRIPTION
content:
<b>tclsh</b> (Tcl SHell) is the standard command-line interpreter for the Tcl programming language. It provides an environment to execute Tcl scripts from a file or interactively.<br><br>When invoked with a <i>fileName</i> argument, <b>tclsh</b> reads and executes the Tcl commands contained within that file. After processing the script, the shell typically exits.<br><br>If no <i>fileName</i> is provided, <b>tclsh</b> enters an interactive mode. In this mode, it reads Tcl commands from standard input, evaluates them, and prints the string representation of the command results to standard output. This allows users to experiment with Tcl commands directly, test small code snippets, or manage Tcl applications interactively.<br><br><b>tclsh</b> automatically sets global Tcl variables such as <i>argv0</i>, <i>argv</i>, and <i>argc</i> to reflect the script's name and any command-line arguments passed to it, facilitating argument parsing within Tcl scripts. It also supports the common <i>#!</i> (shebang) mechanism for making Tcl scripts directly executable on Unix-like systems.<br><br>The '8.5' in <b>tclsh8.5</b> indicates a specific version of the Tcl interpreter, ensuring compatibility with applications or scripts designed for that particular Tcl release.


title: CAVEATS
content:
Specific version dependency: <b>tclsh8.5</b> explicitly calls the Tcl 8.5 interpreter. Scripts requiring newer Tcl features (e.g., from Tcl 8.6 or 8.7) might not run or might behave unexpectedly. <br><br>Lack of GUI: Unlike <b>wish</b> (the Tk shell), <b>tclsh</b> does not include the Tk toolkit by default, meaning it cannot directly create graphical user interfaces. It's primarily for command-line and backend scripting. <br><br>Error handling: By default, if a script encounters an error and is not handled by Tcl's <b>catch</b> command, <b>tclsh</b> will print an error message to standard error and exit with a non-zero status code.


title: INTERACTIVE MODE
content:
When <b>tclsh</b> is run without a script file, it provides an interactive prompt (typically '% ' or 'tcl> '). Users can type Tcl commands directly, press Enter to execute them, and see the results immediately. This mode is invaluable for debugging, learning Tcl, and quick command execution. The global variable <i>tcl_interactive</i> is set to '1' in this mode.


title: SCRIPT EXECUTION
content:
Tcl scripts can be executed by passing their filename to <b>tclsh</b>. For example: <b>tclsh8.5</b> <i>my_script.tcl arg1 arg2</i>. Inside <i>my_script.tcl</i>, the global variable <i>::argv0</i> would be "my_script.tcl", <i>::argv</i> would be the list `[list arg1 arg2]`, and <i>::argc</i> would be '2', allowing the script to easily access its command-line arguments.


title: HISTORY
content:
Tcl (Tool Command Language) was created by John Ousterhout in 1988 at the University of California, Berkeley. <b>tclsh</b> has been the fundamental command-line interpreter since Tcl's inception, providing the core execution environment. Version 8.5 of Tcl, released in 2007, introduced significant features like dicts (dictionaries) and improved object-oriented capabilities (though <i>oo::</i> became standard in 8.6). The <b>tclsh</b> command itself has remained largely consistent in its core functionality as the project evolved, primarily adding support for new Tcl language features and interpreter improvements over time. Its stability and consistency across versions make it a reliable tool for scripting and automation.


title: SYNOPSIS
content:
<b>tcpdump</b> [ <i>options</i> ] [ <i>expression</i> ]<br>Common usage: <b>tcpdump</b> [ <b>-i</b> <i>interface</i> ] [ <b>-n</b> ] [ <b>-v</b> ] [ <b>-A</b> ] [ <b>-s</b> <i>snaplen</i> ] [ <b>-w</b> <i>file</i> ] [ <b>-r</b> <i>file</i> ] [ <i>expression</i> ]


title: PARAMETERS
content:
<b><b>-i</b> <i><interface></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to listen on (e.g., eth0, wlan0). If not specified, <b>tcpdump</b> selects the lowest numbered, configured interface (excluding loopback).<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't convert host addresses to names. This speeds up output and avoids DNS lookups.<br><br><b><b>-nn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't convert host addresses and port numbers to names. Even faster than <b>-n</b>.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output. Use <b>-vv</b> or <b>-vvv</b> for more detail.<br><br><b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints each packet (minus its link-level header) in ASCII. Useful for capturing web traffic or other text-based protocols.<br><br><b><b>-X</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints each packet (minus its link-level header) in hex and ASCII. Useful for deep inspection of packet contents.<br><br><b><b>-s</b> <i><snaplen></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the snapshot length (bytes) to capture per packet. Default is usually 65535, capturing the full packet. Setting a smaller value reduces data stored.<br><br><b><b>-c</b> <i><count></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit after receiving <i><count></i> packets.<br><br><b><b>-w</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the raw packets to <i><file></i> in <b>pcap</b> format, instead of parsing and printing them. This file can be opened by Wireshark.<br><br><b><b>-r</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read packets from <i><file></i> (which must be a <b>pcap</b> file created with the <b>-w</b> option).<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all network interfaces on which <b>tcpdump</b> can listen.<br><br><b><i><expression></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A filtering expression that specifies which packets will be dumped. It's based on Berkeley Packet Filter (BPF) syntax.<br><br>


title: DESCRIPTION
content:
<i><b>tcpdump</b></i> is a powerful command-line packet analyzer tool for Unix-like operating systems. It allows users to intercept and display TCP/IP and other packets being transmitted or received over a network to which the computer is attached. It can be used for network troubleshooting, security monitoring, and application debugging. <i><b>tcpdump</b></i> writes packets to standard output or a file, making it suitable for scripting and further analysis with tools like Wireshark. It supports a rich filtering language (BPF - Berkeley Packet Filter) to capture only specific traffic, saving resources and focusing the analysis. Its versatility makes it an indispensable tool for network administrators and security professionals.


title: CAVEATS
content:
<i><b>tcpdump</b></i> typically requires root privileges (or <b>sudo</b>) to capture packets directly from the network interface. Improper use or capturing on high-traffic networks can lead to significant resource consumption (CPU, memory, disk I/O) and potentially impact network performance. The raw output can be voluminous and complex to interpret without understanding networking protocols; thus, captured files (<b>.pcap</b>) are often analyzed with graphical tools like Wireshark. Be mindful of disk space when capturing for extended periods or on busy links, as <b>pcap</b> files can grow very large quickly. Capturing on <i>any</i> interface might not always work as expected on some systems, and specifying a precise interface with <b>-i</b> is often preferred.


title: FILTER EXPRESSIONS (BPF)
content:
<i><b>tcpdump</b></i>'s power lies in its ability to filter captured traffic using complex expressions based on the Berkeley Packet Filter (BPF) syntax. These expressions can filter by host (e.g., <i>host 192.168.1.1</i>), port (e.g., <i>port 80</i>), protocol (e.g., <i>tcp</i>, <i>udp</i>, <i>icmp</i>), direction (<i>src</i>, <i>dst</i>), or even specific bit patterns within the packet. Combining these with logical operators (<i>and</i>, <i>or</i>, <i>not</i>) allows for highly granular control over what traffic is displayed or saved, significantly reducing the volume of data and focusing the analysis. Examples include <i>host example.com and tcp port 80</i> or <i>src net 10.0.0.0/8 and not port 22</i>.


title: HISTORY
content:
<i><b>tcpdump</b></i> was originally written in 1987 by Van Jacobson, Sally Floyd, Vern Paxson, and Steven McCanne at Lawrence Berkeley National Laboratory (LBNL). It was part of the <i><b>libpcap</b></i> library, which provides a portable API for network packet capture. The <i><b>libpcap</b></i> library (and thus <i><b>tcpdump</b></i>) quickly became a standard for network monitoring and analysis on Unix-like systems. Its development continued over the years, adapting to new protocols and operating system features, maintaining its status as a fundamental tool in network diagnostics and security. It remains widely used due to its efficiency, scriptability, and powerful filtering capabilities.


title: SYNOPSIS
content:
<b>tdbrestore</b> [<i>options</i>] <i>&lt;tdb_file&gt;</i><br><i>Example usage:</i> <b>tdbdump</b> <i>/path/to/original.tdb</i> | <b>tdbrestore</b> <i>/path/to/new.tdb</i>


title: PARAMETERS
content:
<b><b>-h</b>, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b><b>-v</b>, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the restoration process.<br><br><b><b>-a</b>, --append</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append the dumped data to an existing TDB file. If this option is not used, <b>tdbrestore</b> will overwrite the target <i>tdb_file</i> if it already exists, potentially leading to data loss.<br><br><b><i>&lt;tdb_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the TDB file where the data will be restored. This file will be created if it doesn't exist, or overwritten/appended to based on the <b>-a</b> option.<br><br>


title: DESCRIPTION
content:
The <b>tdbrestore</b> command is a utility provided by the Samba suite, designed to restore Trivial Database (TDB) files from a previously created dump. TDB files are lightweight, key-value databases crucial for Samba's internal operations, storing information like user accounts, group mappings, share configurations, and lock states.<br><br><b>tdbrestore</b> reads the TDB dump, typically generated by the <b>tdbdump</b> command, from standard input and reconstructs the TDB file specified as an argument. This command is indispensable for disaster recovery, allowing administrators to restore corrupted TDB files, or for migrating TDB data between Samba installations. It's vital to ensure that Samba services are stopped before restoring critical TDBs to prevent data corruption or inconsistency.


title: CAVEATS
content:
<i><b>Overwriting Data:</b></i> By default, <b>tdbrestore</b> will overwrite the target TDB file if it already exists. Use the <b>-a</b> (append) option to add data to an existing file instead.<br><i><b>Prerequisites:</b></i> The command relies on a TDB dump created by <b>tdbdump</b>. Without a valid dump file, <b>tdbrestore</b> cannot reconstruct the database.<br><i><b>Service Interruption:</b></i> For critical Samba TDBs (e.g., <i>passdb.tdb</i>, <i>secrets.tdb</i>), it is highly recommended to stop all related Samba services (like <b>smbd</b>, <b>nmbd</b>, <b>winbindd</b>) before performing a restore operation to prevent data corruption or inconsistencies caused by concurrent access.


title: COMMON TDB FILES IN SAMBA
content:
Many critical Samba functions rely on TDB files. Examples include <i>passdb.tdb</i> (stores user password hashes and account information), <i>secrets.tdb</i> (stores sensitive cryptographic keys), <i>group_mapping.tdb</i> (maps Windows SIDs to Unix GIDs), and <i>share_info.tdb</i> (stores share definitions). Understanding which TDB file to restore is crucial for effective recovery.


title: USAGE EXAMPLE FOR BACKUP AND RESTORE
content:
<i><b>1. Backup a TDB file:</b></i><br><b>tdbdump</b> <i>/var/lib/samba/private/passdb.tdb</i> > <i>/path/to/backup/passdb.tdb.dump</i><br><br><i><b>2. Restore the TDB file (after stopping Samba services):</b></i><br><b>cat</b> <i>/path/to/backup/passdb.tdb.dump</i> | <b>tdbrestore</b> <i>/var/lib/samba/private/passdb.tdb</i>


title: HISTORY
content:
<b>tdbrestore</b> is an integral utility of the Samba project, an open-source software suite that provides file and print services to SMB/CIFS clients. Samba's development began in the early 1990s, and TDB (Trivial Database) was introduced as a lightweight, persistent key-value store to manage various internal data structures, replacing earlier ad-hoc file formats. <b>tdbrestore</b>, alongside <b>tdbdump</b>, was developed to provide essential backup and recovery capabilities for these critical TDB files, ensuring the robustness and manageability of Samba deployments.


title: PARAMETERS
content:
<b><b><code>-a</code></b>, <b><code>--append</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append to the given <i>FILE</i>s, rather than overwriting them. This is crucial for maintaining logs or accumulating data over multiple runs.<br><br><b><b><code>-i</code></b>, <b><code>--ignore-interrupts</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore interrupt signals (like <code>Ctrl-C</code>). This allows <code>tee</code> to continue processing even if an interrupt signal is received, useful for critical operations.<br><br><b><b><code>-u</code></b>, <b><code>--unbuffered</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unbuffer output. By default, <code>tee</code> buffers its output, writing in blocks. This option forces <code>tee</code> to write to each output <i>FILE</i> as soon as data is received, useful for real-time monitoring of streams.<br><br><b><b><code>--output-error</code></b>[=<i>MODE</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set behavior on write errors. <i>MODE</i> can be <code>warn-errno</code> (default: diagnose errors with errno message), <code>warn-once</code> (diagnose errors just once), <code>warn-all</code> (diagnose errors for all attempts), or <code>exit</code> (exit on first write error).<br><br>


title: DESCRIPTION
content:
The <b><code>tee</code></b> command reads standard input and writes it to both standard output and one or more specified files. This dual output capability makes it invaluable in command pipelines, allowing users to simultaneously view intermediate output on the console while saving it to a file for later analysis, logging, or further processing.<br><br>By default, <code>tee</code> will <i>overwrite</i> any existing files it writes to. However, it provides an option to <i>append</i> to files, preserving their previous content. It acts like a "T" junction in a pipe, splitting the data stream. Commonly used with other powerful commands like <code>grep</code>, <code>sort</code>, <code>awk</code>, or <code>sed</code>, <code>tee</code> enables non-destructive data flow monitoring and persistence. For instance, <code>command | tee log.txt</code> displays the command's output and saves it to <code>log.txt</code>. For continuous logging without overwriting, <code>long_process | tee -a log.txt</code> is often employed. Its simplicity, combined with its profound utility, establishes <code>tee</code> as a fundamental tool in Unix-like operating systems for scripting and efficient command-line operations.


title: CAVEATS
content:
By default, <code>tee</code> <i>overwrites</i> target files. Always use <b><code>-a</code></b> for appending if you intend to preserve existing content.<br>If not used with <b><code>-u</code></b>, <code>tee</code> might buffer output, leading to delays in real-time display or logging, especially in pipelines. Error handling for multiple files: by default, <code>tee</code> attempts to continue processing even if writing to one file fails, unless <b><code>--output-error=exit</code></b> is specified.


title: COMMON USE CASES
content:
<b>Logging and Monitoring:</b> Capturing the output of a command (e.g., a long-running script, a build process) to a log file while simultaneously displaying it on the console for real-time monitoring.<br><b>Pipeline Debugging:</b> Saving the intermediate output of a complex command pipeline to a file for later inspection and debugging, without interrupting the flow of the pipeline.<br><b>Data Persistence:</b> When you want to save the results of a command to a file for future use, but also need to pass those same results to the next command in a pipeline.


title: HISTORY
content:
The <b><code>tee</code></b> command is a standard utility that has been a part of Unix-like operating systems for many decades, pre-dating GNU Core Utilities. Its core functionality of duplicating a stream to both standard output and files has remained consistent due to its fundamental utility. Modern implementations, such as those in GNU Core Utilities, have added more advanced error handling options like <b><code>--output-error</code></b> to enhance its robustness and control over its behavior in complex scenarios, but its basic 'T-junction' purpose is historical.


title: SYNOPSIS
content:
<I>tesseract</I> <I>imagename</I> <I>outputbase</I> [<I>options...</I>]<br><I>tesseract</I> <I>--help</I> | <I>--version</I><br><br><I>imagename</I>: The path to the input image file (e.g., JPEG, PNG, TIFF).<br><I>outputbase</I>: The base name for the output file(s) (without extension).


title: PARAMETERS
content:
<b>-l <I>LANG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the language(s) to use for OCR (e.g., <I>eng</I> for English, <I>eng+fra</I> for multiple).<br><br><b>--oem <I>OEM_MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the OCR Engine Mode (<b>0</b>=Legacy, <b>1</b>=LSTM, <b>2</b>=Legacy+LSTM, <b>3</b>=Default).<br><br><b>--psm <I>PSM_MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the Page Segmentation Mode, determining how Tesseract interprets the page layout (e.g., <b>3</b>=Auto, <b>6</b>=Block, <b>7</b>=Line).<br><br><b>-c <I>VAR=VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a Tesseract configuration variable for fine-tuning.<br><br><b>--dpi <I>DPI_VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input image DPI, crucial for correct scaling and recognition.<br><br><b>--tessdata-dir <I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where Tesseract language data files are located.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br>


title: DESCRIPTION
content:
Tesseract is a powerful, free, and open-source optical character recognition (OCR) engine used to convert images containing text into machine-readable text. Originally developed by Hewlett-Packard in the 1980s, it was open-sourced in 2005 and has been sponsored by Google since 2006. <br><br>It supports a wide variety of image formats, including TIFF, JPEG, PNG, and more. Tesseract's strength lies in its ability to accurately recognize text in numerous languages, provided the corresponding language data packs are installed. Users can specify the input image, a base name for the output file, and various options to control the recognition process. <br><br>Output can be generated in several formats, such as plain text, searchable PDF, hOCR (HTML with embedded OCR data), TSV, and ALTO XML. Tesseract is widely used for digitizing historical documents, making scanned documents searchable, automating data entry, and enhancing accessibility by converting image-based content into editable text. Its command-line interface makes it suitable for scripting and integration into larger workflows.


title: CAVEATS
content:
Tesseract's accuracy is heavily dependent on the quality of the input image; poor resolution, skewed images, or complex backgrounds can significantly degrade results. It typically performs best on clear, well-scanned documents. While it supports many languages, the necessary language data packs must be separately installed. Handwriting recognition is generally less accurate compared to printed text. As a command-line tool, it lacks a built-in graphical user interface.


title: OUTPUT FORMATS
content:
Tesseract can output recognized text in various formats beyond plain text, including searchable PDF, hOCR (HTML with embedded OCR data), TSV (tab-separated values), and ALTO XML, providing flexibility for different use cases.


title: CUSTOM CONFIGURATIONS
content:
Users can create and apply custom configuration files to fine-tune Tesseract's behavior for specific tasks or document types, allowing for advanced control over the OCR process and optimizing accuracy for particular scenarios.


title: HISTORY
content:
Tesseract was originally developed by Hewlett-Packard between 1985 and 1995 as a proprietary OCR engine. After being open-sourced under the Apache License 2.0 in 2005, Google took over its sponsorship and active development in 2006. Google significantly improved the engine, leading to the release of Tesseract 3.0, and later Tesseract 4.0 which introduced a new, more accurate LSTM-based neural network engine. This continuous development has made it one of the most widely used and advanced open-source OCR engines available.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--suppress-prompt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the interactive prompt. This is useful for scripting where no user interaction is desired. The command will exit with a status code indicating success or failure.<br><br><b><b>-v</b>, <b>--show-defaults</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing all parameters including the default values that Samba applies if not explicitly set in <i>smb.conf</i>. Provides a complete view of the effective configuration.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the validity of users mentioned in the configuration. This option may require root privileges to access user account information.<br><br><b><b>-t</b>, <b>--syntax-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a syntax check only, without printing the parsed configuration. It returns 0 on success and a non-zero value on error, making it suitable for automated checks.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs messages to standard output (stdout) instead of the default syslog or debug file.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the processing of parameter includes. This means any 'include' directives in <i>smb.conf</i> will be ignored.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with common command-line options.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information for the <i>testparm</i> utility and the Samba suite.<br><br><b><i>configfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative Samba configuration file to check instead of the default (typically <i>/etc/samba/smb.conf</i>).<br><br><b><i>hostname</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates a connection from a specific hostname. This can be used to test host-based access controls defined in the configuration.<br><br><b><i>hostIP</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates a connection from a specific IP address, useful for testing IP-based access restrictions.<br><br>


title: DESCRIPTION
content:
<i>testparm</i> is a command-line utility from the Samba suite. Its primary function is to parse and validate the syntax of the Samba configuration file, typically <i>smb.conf</i>. It helps administrators identify and correct syntax errors, preventing potential issues before starting or restarting the Samba daemons. Beyond syntax checking, <i>testparm</i> also displays the effective configuration parameters, including all default values that Samba applies internally. This comprehensive output allows administrators to verify how their settings are interpreted, resolve conflicts, and ensure that global and share-specific options are configured as intended. It can also simulate connections from specific hosts or IP addresses to test access permissions, making it an indispensable tool for pre-deployment validation and troubleshooting.


title: CAVEATS
content:
<i>testparm</i> primarily checks the <i>syntax</i> and <i>parameter interpretation</i> of <i>smb.conf</i>. It does not perform live network tests, verify actual file system permissions, or diagnose runtime issues of the Samba server. For complete validation, the <i>smbd</i> daemon itself must be run and tested. Some specific checks, such as user validity with the <b>-u</b> option, may require elevated (root) privileges.


title: NON-INTERACTIVE MODE FOR SCRIPTING
content:
The <b>-s</b> or <b>--suppress-prompt</b> option is invaluable for automation. When used in scripts, <i>testparm</i> runs non-interactively and exits with a status code (0 for success, non-zero for errors), allowing for automated configuration checks as part of continuous integration/deployment pipelines or system health monitoring scripts. This facilitates robust and error-free Samba deployments.


title: UNDERSTANDING EFFECTIVE CONFIGURATION
content:
The <b>-v</b> or <b>--show-defaults</b> option is crucial for a complete understanding of how Samba will operate. It displays not only the parameters explicitly set by the administrator in <i>smb.conf</i> but also all the default values that Samba applies internally. This comprehensive output helps in debugging unexpected behavior by revealing all active parameters, ensuring administrators have a full picture of their server's configuration.


title: HISTORY
content:
<i>testparm</i> has been a fundamental component of the Samba suite since its early development. As the complexity of Samba configurations grew, especially with features like Active Directory integration, the importance of a robust configuration validation tool increased. <i>testparm</i> has consistently served as the go-to utility for administrators to ensure the correctness and integrity of their <i>smb.conf</i> files, evolving alongside Samba to support new parameters and syntax, thereby preventing common startup failures and aiding in the deployment of complex server environments.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of <i>testssl</i>.<br><br><b><b>-p</b>, <b>--protocols</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests all supported SSL/TLS protocols, reporting which ones are enabled.<br><br><b><b>-e</b>, <b>--each-cipher</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests each cipher separately, providing detailed output for every supported cipher.<br><br><b><b>-S</b>, <b>--suites</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows all supported ciphers, grouped by protocol.<br><br><b><b>-B</b>, <b>--heartbleed</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifically checks for the Heartbleed vulnerability.<br><br><b><b>-D</b>, <b>--drown</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for the DROWN vulnerability, which affects servers allowing SSLv2 connections.<br><br><b><b>-L</b>, <b>--logjam</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests for the Logjam vulnerability, related to weak Diffie-Hellman key exchange.<br><br><b><b>--ip=&lt;ip&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a specific IP address of the target, useful for multi-homed servers.<br><br><b><b>--starttls &lt;protocol&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests STARTTLS support for specified protocols (e.g., <i>smtp</i>, <i>imap</i>, <i>xmpp</i>).<br><br><b><b>--json</b>, <b>--jsonfile=&lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs results in JSON format, optionally writing to a specified file. Ideal for programmatic parsing.<br><br><b><b>--html</b>, <b>--htmlfile=&lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs results in HTML format, optionally writing to a specified file. Suitable for reports.<br><br><b><b>--quiet</b>, <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all output except for the final results summary.<br><br>


title: DESCRIPTION
content:
<i>testssl</i> is a robust, free, and command-line driven tool for checking a server's SSL/TLS (Secure Sockets Layer/Transport Layer Security) configuration. It performs a deep analysis of cryptographic protocols, ciphers, and security flaws, helping administrators identify and mitigate potential vulnerabilities such as Heartbleed, POODLE, BEAST, FREAK, Logjam, DROWN, and ROBOT. Beyond vulnerability detection, it also scrutinizes certificate details, server preferences, renegotiation capabilities, HSTS implementation, and OCSP stapling, providing a detailed, color-coded report. Its broad support for IPv4/IPv6 and STARTTLS (for protocols like SMTP, XMPP, LDAP, POP3, IMAP, FTP, RDP, PostgreSQL, MySQL) makes it an invaluable tool for ensuring comprehensive server security and compliance.


title: CAVEATS
content:
<i>testssl</i> can be resource-intensive and time-consuming for full scans, especially on large numbers of targets.<br>It relies on an external <i>openssl</i> installation; its capabilities are limited by the features compiled into the local <i>openssl</i> version.<br>Not typically included in standard Linux distributions' repositories, often requiring manual installation from its GitHub repository.<br>Some deep vulnerability checks might trigger intrusion detection/prevention systems (IDS/IPS).


title: EXTENSIVE VULNERABILITY CHECKS
content:
<i>testssl</i> is renowned for its comprehensive suite of built-in checks for a vast array of known SSL/TLS vulnerabilities, including but not limited to Heartbleed, POODLE, BEAST, CRIME, FREAK, Logjam, DROWN, SWEET32, and ROBOT. This makes it an indispensable tool for quickly assessing a server's resilience against common and historical cryptographic attacks.


title: FLEXIBLE OUTPUT FORMATS
content:
Beyond its default human-readable, color-coded terminal output, <i>testssl</i> supports various output formats. Users can generate results in JSON for easy programmatic integration and parsing, or in HTML for convenient reporting and archival, enhancing its utility in automated security pipelines and documentation.


title: BROAD PROTOCOL SUPPORT INCLUDING STARTTLS
content:
A key strength of <i>testssl</i> is its ability to test SSL/TLS configurations not just for HTTPS, but also for a wide range of other protocols via STARTTLS. This includes services like SMTP, IMAP, POP3, FTP, XMPP, LDAP, RDP, PostgreSQL, and MySQL, ensuring a holistic security assessment across an organization's entire service landscape.


title: HISTORY
content:
<i>testssl.sh</i> was initially developed by Dirk Wetter in 2012 as a robust tool for SSL/TLS server auditing. Its comprehensive feature set, ease of use, and continuous updates, incorporating new vulnerabilities and best practices, quickly propelled it to become a widely adopted standard for security professionals and system administrators worldwide. Its development remains active, ensuring it stays current with evolving cryptographic threats.


title: PARAMETERS
content:
<b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current high scores recorded for the game without starting a new game session.<br><br>


title: DESCRIPTION
content:
<br><i>tetris-bsd</i> is a terminal-based implementation of the popular puzzle video game, Tetris. The objective is to manipulate falling blocks (tetrominoes) by moving and rotating them to form complete horizontal lines without gaps. When a line is completed, it disappears, and the blocks above it fall to fill the space, scoring points. The game continues until the stack of blocks reaches the top of the playing field, at which point the game ends. This version is part of the <i>bsdgames</i> collection, providing a nostalgic text-mode gaming experience directly within the command line interface.<br><br>It supports essential gameplay mechanics including moving left/right, rotating, soft dropping, and hard dropping blocks. Users can also pause the game, quit, view high scores, and redraw the screen if terminal issues occur. High scores are persisted, allowing players to track their progress and compete for the top spot. Its simplicity and text-based nature make it a lightweight yet engaging option for a quick game in the terminal.


title: CAVEATS
content:
<br>This command relies on terminal capabilities and may not display correctly in all terminal emulators or with certain font configurations. It uses <i>ncurses</i> for rendering, requiring a compatible environment. High scores are typically stored in a system-wide file (e.g., <i>/var/games/bsdgames/tetris-scores</i>), which may require appropriate file permissions for writing if the user playing does not have them, though reading is usually always permitted. The game controls are based on common vi-like keybindings, which might be unfamiliar to users accustomed to modern game controls.


title: GAME CONTROLS
content:
<br>The game uses a specific set of keyboard controls for gameplay:<br><b>h</b>, <b>j</b>, <b>k</b>, <b>l</b> (or uppercase versions): Move left, move down (soft drop), rotate left, rotate right respectively.<br><b>p</b> (or <b>P</b>): Pause the game.<br><b>q</b> (or <b>Q</b>): Quit the game.<br><b>Space bar</b>: Drop the block immediately (hard drop).<br><b>^L</b> (Control-L): Redraw the screen, useful if terminal display gets corrupted.<br><b>^Z</b> (Control-Z): Suspend the game (sends it to background).


title: HISTORY
content:
<br>The <i>tetris</i> game, as part of the <i>bsdgames</i> collection, has a long history rooted in the Unix and BSD operating systems. The original Tetris game was created by Alexey Pajitnov in 1984. The Unix versions, like <i>tetris-bsd</i>, aim to replicate the classic experience in a text-based terminal environment. This specific version was written by Ken Koppen and later adapted to use the <i>ncurses</i> library by John B. Roll, making it portable across various Unix-like systems. It's often found in distributions' "bsdgames" packages, maintaining a tradition of including classic, simple games that are lightweight and readily available on command-line systems. Its development reflects the early days of computing where graphical interfaces were not standard, emphasizing efficiency and terminal compatibility.


title: SYNOPSIS
content:
<b>tex</b> [<options>] <<i>filename</i>><br><br><i>Note: The <<i>.tex</i>> extension is usually omitted when specifying <<i>filename</i>>.</i>


title: PARAMETERS
content:
<b><<i>filename</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the main TeX source file to process. The <i>.tex</i> extension is usually omitted.<br><br><b><b>-interaction=</b><i>{mode}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the user interaction mode for errors and missing files. Modes include <i>batchmode</i>, <i>nonstopmode</i>, <i>scrollmode</i>, and <i>errorstopmode</i> (default).<br><br><b><b>-output-directory=</b><i><dir></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where all output files (<i>.dvi</i>, <i>.log</i>, <i>.aux</i>, etc.) will be placed.<br><br><b><b>-ini</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to create TeX format files (<i>.fmt</i>). This loads <i>tex.ini</i> and saves the compiled format for later use, typically by system administrators.<br><br><b><b>-fmt=</b><i><format></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the TeX format file to load, such as <i>plain</i> or <i>latex</i>. Most users invoke wrappers like <b>latex</b> directly.<br><br><b><b>-jobname=</b><i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the base name for all generated output files, overriding the default name derived from the input <i>filename</i>.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the TeX executable and exits.<br><br>


title: DESCRIPTION
content:
The <b>tex</b> command is the executable for Donald Knuth's powerful and highly stable typesetting system. It reads a source file, typically with a <i>.tex</i> extension, which contains text mixed with TeX commands. Its primary purpose is to produce high-quality documents, particularly those involving complex mathematical formulas or intricate layouts. The output of the <b>tex</b> command is a <i>Device Independent (DVI)</i> file, which can then be converted to other formats like PostScript or PDF using additional utilities. While <b>tex</b> provides the core engine, most users interact with higher-level macro packages such as <i>LaTeX</i>, which simplifies document creation by abstracting away much of TeX's low-level complexity. TeX is renowned for its precision, portability, and free availability, making it a cornerstone in academic and scientific publishing.


title: CAVEATS
content:
The <b>tex</b> command primarily produces <i>DVI</i> files; a separate conversion step (e.g., using <b>dvips</b> and <b>ps2pdf</b>, or <b>dvipdfm</b>) is required to obtain <i>PDF</i> output. For direct <i>PDF</i> generation, <b>pdflatex</b> is generally preferred. Directly using <b>tex</b> often requires a deeper understanding of TeX's primitive commands, as it lacks the user-friendly macros provided by packages like <i>LaTeX</i>. Its error messages can also be quite cryptic for beginners.


title: DVI OUTPUT FORMAT
content:
The default output of <b>tex</b> is a <i>Device Independent (DVI)</i> file. This binary format describes the layout of the document but is not directly viewable or printable without a specific <i>DVI</i> viewer or a conversion utility.


title: TEX FORMATS AND MACRO PACKAGES
content:
While <b>tex</b> is the core engine, it is rarely used directly for document creation. Instead, users typically leverage 'format files' which are precompiled collections of macros. The most popular format is <i>LaTeX</i>, which builds on <i>plain TeX</i> to provide a powerful and user-friendly markup language for structured documents.


title: HISTORY
content:
TeX was created by Donald E. Knuth, a renowned computer scientist, in the late 1970s. The initial version was released in 1978, driven by Knuth's dissatisfaction with the quality of digital typesetting for his book series, <i>The Art of Computer Programming</i>. Knuth designed TeX to produce aesthetically pleasing and mathematically precise documents. Version 3 (TeX82), released in 1982, introduced significant improvements, including a more robust macro system. TeX's version number incrementally approaches Pi, reflecting Knuth's commitment to stability and very few, controlled changes. It quickly gained popularity in academic and scientific circles due to its high-quality output, stability, and open-source nature, becoming a de facto standard for technical document preparation.


title: SEE ALSO
content:
<b>latex</b>(1), <b>pdflatex</b>(1), <b>dvips</b>(1), <b>ps2pdf</b>(1), <b>dvipdfm</b>(1), <b>bibtex</b>(1), <b>makeindex</b>(1)


title: PARAMETERS
content:
<b><<i>format_name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The symbolic name of the TeX format to be created or updated (e.g., <i>plain</i>, <i>latex</i>). This refers to the corresponding source file (e.g., <i>plain.tex</i>, <i>latex.ltx</i>).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about the compilation process, including TeX engine output.<br><br><b>-u, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the format file only if its source (e.g., <i>plain.tex</i>) is newer than the existing <i>.fmt</i> file.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces recompilation of the format file, even if it appears up-to-date or newer than its source.<br><br><b>-o <<i>output_dir</i>>, --output-directory=<<i>output_dir</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative directory for the generated <i>.fmt</i> file, overriding the default TeX output location.<br><br>


title: DESCRIPTION
content:
The <b>tex-fmt</b> command is conceptually designed to compile TeX source files into precompiled format files (e.g., <i>plain.fmt</i>, <i>latex.fmt</i>). These <i>.fmt</i> files significantly speed up TeX processing by loading a pre-initialized state of the TeX engine, including macros and definitions. While <b>tex-fmt</b> itself is not a universally standardized standalone binary in modern TeX distributions (like TeX Live, where <b>fmtutil</b> is the primary tool), its name implies a utility for handling TeX formats. It would typically automate the process of invoking the TeX engine with the <i>-ini</i> (initialization) option on a format source file, followed by a <i>\dump</i> command, to produce the corresponding <i>.fmt</i> file. It serves as an abstraction for a fundamental TeX operation.


title: CAVEATS
content:
The command <b>tex-fmt</b> is not a widely distributed or standardized standalone executable in most modern Linux distributions or TeX Live installations. Its functionality is typically provided by more comprehensive tools such as <b>fmtutil</b> or <b>mktexfmt</b>, which offer more robust and configurable format management. If <b>tex-fmt</b> exists on a specific system, it is likely a local script or an alias for one of these standard tools, or a remnant from older TeX setups. Users should generally rely on <b>fmtutil</b> for managing TeX formats.


title: FORMAT FILES (.FMT)
content:
TeX format files are precompiled versions of a TeX engine's state, containing loaded macros, fonts, and internal settings. They are generated from <i>.tex</i> source files (e.g., <i>plain.tex</i> for <i>plain.fmt</i>) using the TeX engine's initialization mode (<b>tex -ini</b>). Using a <i>.fmt</i> file drastically reduces the startup time for large documents by avoiding the need to parse and load all standard macros from scratch for every run.


title: COMPILATION PROCESS
content:
A typical internal process for <b>tex-fmt plain</b> would involve locating <i>plain.tex</i> (or <i>plain.ltx</i> for LaTeX), then executing <b>tex -ini plain.tex \dump</b>, resulting in <i>plain.fmt</i> being created in an appropriate TeX tree directory. The specific location is managed by the TeX File System (TDS) hierarchy and typically resolved by <b>kpsewhich</b>.


title: HISTORY
content:
The concept of a <b>tex-fmt</b> utility likely emerged from the need to simplify the creation of TeX format files, which historically involved direct invocation of <b>tex -ini</b> followed by <i>\dump</i>. As TeX distributions grew more complex, simple scripts for this purpose evolved into more sophisticated tools. In modern TeX Live, <b>fmtutil</b> became the de facto standard for building and maintaining format files, incorporating features like dependency tracking and configuration management, effectively superseding simpler <b>tex-fmt</b> concepts or scripts.


title: PARAMETERS
content:
<b><b>-total</b>, <b>--total</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs only the grand total count of words.<br><br><b><b>-sum</b>, <b>--sum</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a summary of counts, often categorized by document sections.<br><br><b><b>-char</b>, <b>--char</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts characters, including spaces.<br><br><b><b>-word</b>, <b>--word</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts words (this is the default behavior).<br><br><b><b>-sentence</b>, <b>--sentence</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts sentences within the document.<br><br><b><b>-incbib</b>, <b>--incbib</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes the bibliography (e.g., from <i>.bbl</i> files) in the total word count.<br><br><b><b>-nobib</b>, <b>--nobib</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes the bibliography from the total word count (this is the default).<br><br><b><b>-incfig</b>, <b>--incfig</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes the text from figure and table captions in the word count.<br><br><b><b>-sub[=<i>LEVEL</i>]</b>, <b>--sub[=<i>LEVEL</i>]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts words per subdocument or per sectional unit (e.g., <i>section</i>, <i>subsection</i>, <i>paragraph</i>).<br><br><b><b>-exclcmd=<i>CMD</i></b>, <b>--exclude-command=<i>CMD</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes the argument of a specific LaTeX command (e.g., <i>\footnote</i>) from counting.<br><br><b><b>-exclenv=<i>ENV</i></b>, <b>--exclude-environment=<i>ENV</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes content within a specific LaTeX environment (e.g., <i>figure</i>, <i>abstract</i>) from counting.<br><br><b><b>-only-section=<i>SEC</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts only the content within a specified section or subsection name.<br><br><b><b>-output=<i>FORMAT</i></b>, <b>--output=<i>FORMAT</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format: <i>summary</i> (default), <i>tex</i> (LaTeX table), <i>xml</i>, or <i>csv</i>.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational messages, showing only the final count.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command options and exits.<br><br>


title: DESCRIPTION
content:
<i>texcount</i> is a powerful Perl script designed to provide accurate word, character, and sentence counts for LaTeX, TeX, and ConTeXt documents.<br>It intelligently parses LaTeX commands, environments, and document structure, enabling it to exclude or include specific elements like comments, commands, or sections from the count.<br>Unlike generic word counters, <i>texcount</i> understands the nuances of LaTeX, providing a more reliable count by ignoring the underlying code.<br>It supports various output formats, including simple summaries, LaTeX tables, or XML, making it versatile for academic, publishing, and reporting purposes.


title: CAVEATS
content:
<i>texcount</i> relies on parsing LaTeX syntax, so malformed or highly unconventional LaTeX code might lead to inaccurate counts.<br>Its definition of a 'word' is based on whitespace and common punctuation, which may not always align with very specific linguistic counting rules.<br>It requires a Perl interpreter to run.


title: CONFIGURATION FILES
content:
<i>texcount</i> can be configured using a personal configuration file (<i>~/.texcountrc</i>) or a project-specific file (<i>.texcountrc</i> in the current directory).<br>These files allow users to define custom counting rules, default exclusions, or specify how certain LaTeX commands and environments should be handled, providing a high degree of customization for specific document types or workflows.


title: COUNTING RULES AND INCLUSIONS
content:
<i>texcount</i> applies intelligent rules for what constitutes a 'word', typically separating by whitespace and certain punctuation.<br>By default, it excludes LaTeX commands, environments like <i>verbatim</i>, and comments.<br>However, options exist to include or exclude almost any element, such as footnotes, specific commands, or mathematical content, offering fine-grained control over the final count based on user requirements.


title: HISTORY
content:
<i>texcount</i> is a well-established and actively maintained Perl script, originating to provide accurate word counts for academic and publishing workflows involving LaTeX.<br>It has evolved over many years to support newer LaTeX features, packages, and more complex document structures, becoming a standard tool for LaTeX users needing precise document statistics.


title: SYNOPSIS
content:
<i>texdoc</i> [<i>OPTION</i>...] <i>NAME</i>...<br><i>texdoc</i> [<i>OPTION</i>...] <i>SUBCOMMAND</i> [<i>ARGUMENTS</i>...]


title: PARAMETERS
content:
<b><b>-l</b> or <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all documentation files matching the given <i>NAME</i> without opening any, useful for exploring available options.<br><br><b><b>-s</b> or <b>--show-path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the full file path to the document that would be opened, but does not launch a viewer.<br><br><b><b>-f</b> or <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the opening of a document, even if multiple matches are found, typically opening the first or most relevant one based on internal logic.<br><br><b><b>-w</b> or <b>--web</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>texdoc</i> to attempt opening HTML documentation using a web browser instead of a local document viewer.<br><br><b><b>-m</b> or <b>--most-recent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When multiple versions of documentation are found, this option attempts to open the most recently updated or versioned document available.<br><br><b><b>-V</b> or <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <i>texdoc</i> program's version information and exits.<br><br><b><b>-h</b> or <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and exits.<br><br>


title: DESCRIPTION
content:
<i>texdoc</i> is an indispensable utility within the TeX Live distribution, designed to simplify the process of locating and viewing documentation for TeX, LaTeX, and related packages. Instead of manually searching complex file systems or online repositories, users can simply provide the name of a package or topic. <i>texdoc</i> then intelligently finds the relevant documentation file—which could be in formats like PDF, DVI, PostScript, HTML, or plain text—and automatically opens it using the appropriate viewer configured on the user's system.<br><br>It leverages the <i>kpsewhich</i> program to efficiently search the extensive TeX directory tree for documentation files, making it highly effective for accessing the vast array of manuals and guides distributed with TeX. This command significantly enhances the user experience for TeX users, providing quick, seamless access to essential package information directly from the command line by abstracting away the complexities of file locations and viewer selection.


title: CAVEATS
content:
<i>texdoc</i> relies on a properly installed and configured TeX distribution, such as TeX Live. Its functionality is dependent on the <i>kpsewhich</i> utility for locating files, which can occasionally be slow or misconfigured. Users might also need to explicitly set up their preferred document viewers as <i>texdoc</i> defers to system defaults or environment variables (e.g., <i>TEXDOCVIEWER</i>), which may not always be optimal.


title: CONFIGURATION OF VIEWERS
content:
<i>texdoc</i> determines which application opens the documentation by consulting system-wide configurations and environment variables (e.g., <i>TEXDOCVIEWER</i>). For optimal experience, users may need to explicitly configure these settings to align with their preferred PDF, DVI, or HTML viewer applications.


title: SEARCH LOGIC
content:
The command employs a sophisticated search algorithm that often prioritizes exact matches for package names. If an exact match is not found or the query is ambiguous, <i>texdoc</i> is capable of listing multiple potential documents, aiding users in navigating and locating less common or similarly named packages.


title: HISTORY
content:
<i>texdoc</i> emerged as an essential component of the TeX Live distribution, driven by the need for a standardized and user-friendly method to access the vast documentation accompanying TeX packages. Prior to its widespread adoption, users often had to manually navigate complex directory structures or consult package-specific instructions to find relevant documentation. Over time, it has evolved to support various document formats and integrate seamlessly with different viewers, becoming a cornerstone utility that significantly streamlines the documentation lookup process for the global TeX community.


title: SYNOPSIS
content:
<b>texliveonfly</b> [<i>OPTIONS</i>] <i>COMMAND</i> [<i>ARGUMENTS...</i>]<br><b>texliveonfly</b> <i>COMMAND</i> [<i>ARGUMENTS...</i>]


title: PARAMETERS
content:
<b>--install-prefix <path> | -p <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative installation prefix for <I>tlmgr</I>. Useful for installing packages in a user-specific directory rather than system-wide.<br><br><b>--dry-run | -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a trial run without actually installing any packages. It will show which packages <I>would</I> be installed.<br><br><b>--no-install | -N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables automatic package installation. The script will simply execute the specified command without attempting to resolve missing packages.<br><br><b>--quiet | -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most of <I>texliveonfly</I>'s output, showing only the wrapped command's output.<br><br><b>--verbose | -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables more verbose output from <I>texliveonfly</I>, providing more details about its operations.<br><br><b>--debug | -d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, showing all debug messages which can be helpful for troubleshooting.<br><br><b>--help | -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and available options.<br><br><b>--version | -V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <I>texliveonfly</I> script.<br><br>


title: DESCRIPTION
content:
<I>texliveonfly</I> is a wrapper script designed to automatically detect and install missing TeX Live packages during the compilation of LaTeX documents. When a LaTeX compiler (such as <I>pdflatex</I>, <I>xelatex</I>, or <I>lualatex</I>) reports an error due to a missing package, <I>texliveonfly</I> parses the output, identifies the required package, and then uses the <I>tlmgr</I> (TeX Live Manager) utility to download and install it. This eliminates the need for manual package installation, streamlining the workflow for LaTeX users, especially when working with new or complex documents that have many dependencies. It then re-runs the original compilation command after successful installation. It is particularly useful for development and quick testing, saving significant time by resolving common package dependency issues automatically.


title: CAVEATS
content:
While <I>texliveonfly</I> is convenient, it has several important caveats: <br>1. It requires <I>tlmgr</I> (TeX Live Manager) to be installed and accessible in your PATH. It is designed specifically for the TeX Live distribution and will not work with other TeX distributions like MiKTeX. <br>2. An active internet connection is necessary for package downloads and installation. <br>3. Depending on your TeX Live installation, running <I>tlmgr</I> (and thus <I>texliveonfly</I>) might require root or administrator privileges, which could pose a security risk if not managed carefully. <br>4. For reproducible builds, it's generally better to explicitly manage your LaTeX dependencies rather than relying on on-the-fly installations. This script is more suited for development or exploration. <br>5. It might not correctly identify all missing packages in complex scenarios or if error messages deviate from expected patterns. <br>6. Repeated compilation attempts might occur if a package cannot be found or installed, potentially leading to slow builds.


title: WORKING PRINCIPLE
content:
<I>texliveonfly</I> operates by redirecting the standard output and error streams of the wrapped LaTeX command. It then scans these streams for specific error messages indicating missing TeX Live packages. If such a message is found, it extracts the package name and attempts to install it using <I>tlmgr install</I>. After the installation, the original command is re-executed, assuming the dependency is now resolved. This cycle can repeat if multiple missing packages are detected. This approach makes it a seamless experience for the user, as they only need to run their compilation command once.


title: HISTORY
content:
<I>texliveonfly</I> was developed by Alexey Malakhov to address a common frustration among LaTeX users: the manual installation of missing packages. Before such tools, users would encounter an error, identify the missing package from the log, open a terminal, run <I>tlmgr install &lt;package-name&gt;</I>, and then retry compilation. <I>texliveonfly</I> automates this tedious process, making it significantly easier to work with new or unfamiliar LaTeX documents and reducing the barrier to entry for beginners encountering dependency issues.


title: SYNOPSIS
content:
<b>textql</b> [<i>options</i>] [<i>--query &lt;SQL query&gt;</i> | <i>--sql &lt;file&gt;</i>] [<i>&lt;input_file&gt;...</i>]<br><b>textql</b> [<i>options</i>] <i>&lt;SQL query&gt;</i>


title: PARAMETERS
content:
<b><b>-header</b>, <b>--header</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat the first row of input files as column headers. These headers will be used as column names in SQL queries.<br><br><b><b>-dlm</b> &lt;char&gt;, <b>--delimiter</b> &lt;char&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input field delimiter (e.g., ',' for CSV, '\t' for TSV). Defaults to comma.<br><br><b><b>-tab-table</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shorthand for <b>--delimiter='\t'</b>, indicating that input files are tab-separated.<br><br><b><b>-output-dlm</b> &lt;char&gt;, <b>--output-delimiter</b> &lt;char&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output field delimiter. Defaults to the input delimiter if not explicitly set.<br><br><b><b>-output-header</b>, <b>--output-header</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include column headers in the query output. Useful for generating new delimited files.<br><br><b><b>-source</b> &lt;file&gt;..., <b>--source</b> &lt;file&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify one or more input file paths for the query. Can be omitted if data is piped via stdin.<br><br><b><b>-query</b> &lt;query&gt;, <b>--query</b> &lt;query&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The SQL query string to execute. It's recommended to enclose the query in quotes.<br><br><b><b>-sql</b> &lt;file&gt;, <b>--sql</b> &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing the SQL query to execute, allowing for complex queries.<br><br><b><b>-output-file</b> &lt;file&gt;, <b>-o</b> &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Direct the query output to the specified file instead of printing to stdout.<br><br><b><b>-db-path</b> &lt;path&gt;, <b>--db-path</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a SQLite database file. Useful for persistent tables, indexing, or more complex multi-step queries.<br><br><b><b>-save-to</b> &lt;table&gt;, <b>--save-to</b> &lt;table&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the results of the query into a specified table within the database given by <b>-db-path</b>.<br><br><b><b>-console</b>, <b>--console</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start an interactive SQLite console with the input files already loaded as temporary tables, for direct SQL interaction.<br><br><b><b>-pretty</b>, <b>--pretty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format output in a human-readable, tabular form, especially useful for displaying results directly in the terminal.<br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the <i>textql</i> version and exit.<br><br>


title: DESCRIPTION
content:
<i>textql</i> is a versatile command-line utility that enables users to execute SQL queries directly on CSV, TSV, or any other delimited text files. It eliminates the need for manual data imports into a traditional database by treating each input file as a virtual table. Built upon the robust SQLite engine, <i>textql</i> allows for powerful data manipulation, including filtering, sorting, aggregation, and joining across multiple files, using familiar SQL syntax.<br><br>It's an invaluable tool for ad-hoc data analysis, quick reporting, and automating data transformation tasks on flat files. Whether you need to extract specific columns, count occurrences, or combine data from several spreadsheets, <i>textql</i> provides a fast and efficient solution right from your terminal.


title: CAVEATS
content:
While powerful, <i>textql</i> treats input files as temporary tables by default unless the <b>--db-path</b> option is used, meaning changes are not saved back to the original files directly. Its SQL dialect is based on SQLite, so specific functions or syntaxes from other SQL implementations (e.g., PostgreSQL, MySQL) might not be supported. Performance for extremely large files (gigabytes+) can be slower than dedicated database systems, though it generally performs well for typical command-line data processing tasks.


title: TABLE NAMING CONVENTION
content:
When processing files, <i>textql</i> automatically assigns table names based on the input filename. For example, 'data.csv' becomes the table 'data' within the SQL context. If multiple files are provided, each corresponds to its own table name based on its base name (filename without extension).


title: PIPING INPUT
content:
<i>textql</i> can accept input directly from <i>stdin</i>. When piping data, the input is typically treated as a single table named 'stdin'. This allows for chaining commands, e.g., 'cat file.csv | textql "SELECT * FROM stdin WHERE column > 10"'.


title: HISTORY
content:
<i>textql</i> was initially developed by Paul Pellegrini and released as an open-source project written in Go. Its creation was motivated by the desire to bring the power and familiarity of SQL to the common use case of processing delimited text files directly from the command line, without the overhead of importing data into a full-fledged database. It quickly gained traction among data analysts and system administrators for its simplicity, efficiency, and cross-platform compatibility.


title: SYNOPSIS
content:
tfmtodit [-a <i>append</i>] [-c <i>checksum</i>] [-e <i>encoding</i>] [-f <i>factor</i>] [-h] [-i <i>index</i>] [-v] <i>tfmfile</i> <i>ditfile</i>


title: PARAMETERS
content:
<b><i>tfmfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <i>input TeX font metric file</i> (.tfm) to be converted. This file contains the font's dimensional data.<br><br><b><i>ditfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <i>output groff font description file</i> (.dit) where the converted font information will be written.<br><br><b>-a <i>append</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of a file whose contents will be <i>appended</i> to the end of the generated <i>ditfile</i>. This is useful for adding supplementary data like ligatures or kerning information.<br><br><b>-c <i>checksum</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows you to <i>specify a checksum value</i> to be embedded in the output font file. If omitted, the checksum from the input <i>tfmfile</i> is used.<br><br><b>-e <i>encoding</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Designates an <i>encoding file</i>. This file contains mappings from character codes in the .tfm file to standard glyph names, which is crucial for correct character rendering, especially for non-ASCII or special characters.<br><br><b>-f <i>factor</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a <i>scaling factor</i>. All font dimensions read from the .tfm file will be multiplied by this factor. The default value is 1000. This is useful for adjusting internal font units.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a <i>help message</i> detailing command usage and options, then exits.<br><br><b>-i <i>index</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>internal index of the first character</i> in the font. The default value is 0.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <i>verbose output</i>. This option causes <b>tfmtodit</b> to print additional information about the conversion process to standard error.<br><br>


title: DESCRIPTION
content:
<b>tfmtodit</b> is a utility program that serves as a bridge between the TeX typesetting system and the groff (GNU troff) document formatting system. Its primary function is to transform TeX font metric (<i>.tfm</i>) files, which encapsulate detailed information about the dimensions and characteristics of TeX fonts, into groff font description (<i>.dit</i>) files. <br><br>These <i>.dit</i> files are indispensable for groff to accurately render and use TeX fonts when generating output, particularly for device-independent formats like PostScript. By performing this conversion, <b>tfmtodit</b> enables users to leverage the extensive collection of high-quality TeX fonts within the groff environment, thereby expanding groff's typographic capabilities. It is commonly utilized by system administrators or advanced users who need to customize their groff setup to include specific TeX fonts not natively supported.


title: CAVEATS
content:
<b>tfmtodit</b> is designed for standard TeX font metrics and might not fully support highly complex or newer font features (e.g., certain OpenType or TrueType capabilities) that go beyond the scope of traditional .tfm files.<br><br>The correct functioning of character mapping heavily relies on the provision of an accurate <i>encoding file</i> via the <code>-e</code> option; without it, character display issues may arise, especially for non-English or symbolic fonts. The input <i>tfmfile</i> must be a valid and uncorrupted TeX font metric file for successful conversion.<br><br>For groff to locate and use the generated <i>ditfile</i>, it typically needs to be placed in a directory configured in <code>GROFF_FONT_PATH</code> or standard groff font directories (e.g., <i>/usr/share/groff/site-font/dev&lt;device&gt;/</i>).


title: HISTORY
content:
<b>tfmtodit</b> is an integral component of the <i>groff</i> (GNU troff) distribution, a free and powerful implementation of the classic Unix troff document formatter. Its development traces back to the late 1980s with the inception of groff by James Clark. The command was created to address the need for groff to utilize fonts specifically designed for the TeX typesetting system, a critical capability given TeX's prominence in academic and technical publishing.<br><br>By enabling the conversion of TeX's binary .tfm format into groff's text-based font description format, <b>tfmtodit</b> significantly expanded groff's typographic palette, allowing users to seamlessly integrate the vast library of high-quality TeX fonts into their groff-formatted documents and facilitating interoperability between these two distinct yet powerful typesetting ecosystems.


title: SYNOPSIS
content:
<b>tftp</b> [<i>options</i>] [<i>host</i> [<i>port</i>]]<br><b>tftp</b> -g|-p [<i>options</i>] <i>remote-file</i> [<i>local-file</i>]


title: PARAMETERS
content:
<b><i>host</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The hostname or IP address of the remote TFTP server to connect to. Required for non-interactive transfers.<br><br><b><i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The remote UDP port number to connect to. Defaults to 69.<br><br><b>-g <i>remote-file</i> / --get <i>remote-file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a non-interactive 'get' (download) operation for the specified <i>remote-file</i>. An optional <i>local-file</i> can be specified as the destination.<br><br><b>-p <i>local-file</i> / --put <i>local-file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a non-interactive 'put' (upload) operation for the specified <i>local-file</i>. An optional <i>remote-file</i> can be specified as the destination on the server.<br><br><b>-c <i>command</i> / --command <i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a single TFTP <i>command</i> (e.g., 'get file', 'put file', 'mode octet') non-interactively, then exits the client.<br><br><b>-l <i>port</i> / --local-port <i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local UDP <i>port</i> to bind to for the transfer.<br><br><b>-m <i>mode</i> / --mode <i>mode</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the transfer <i>mode</i> for file transfers. Common modes are 'netascii' (for text files) and 'octet' (for binary files, which is the default).<br><br><b>-r <i>port</i> / --remote-port <i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the remote UDP <i>port</i> on the TFTP server to connect to.<br><br><b>-v / --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the transfer process, including packet information.<br><br><b>-R <i>count</i> / --retries <i>count</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of retransmission <i>count</i> for lost packets before giving up.<br><br><b>-t <i>seconds</i> / --timeout <i>seconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the timeout in <i>seconds</i> to wait for an acknowledgment before retransmitting a packet.<br><br><b>-b <i>size</i> / --blocksize <i>size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the TFTP 'blksize' option to the specified <i>size</i> (in bytes), allowing negotiation of larger data blocks per packet.<br><br><b>-B / --blksize-option</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly enables the TFTP 'blksize' option, allowing the negotiation of larger transfer block sizes.<br><br><b>-k / --tsize-option</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the TFTP 'tsize' (transfer size) option, allowing the client to query or specify the file size before transfer begins.<br><br><b>-N / --no-tftp-options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables all TFTP options (e.g., blksize, tsize) during the transfer, forcing basic TFTP behavior.<br><br><b>-h / --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with command-line options and exits.<br><br><b>-V / --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the <b>tftp</b> client and exits.<br><br>


title: DESCRIPTION
content:
The <b>tftp</b> command is a client for the Trivial File Transfer Protocol (TFTP), a very simple protocol for transferring files. Unlike FTP, TFTP uses User Datagram Protocol (UDP) for transport, lacks user authentication and encryption, and is connectionless. This design makes it ideal for specific tasks such as booting diskless workstations, network devices (e.g., routers, switches), and firmware updates where simplicity and minimal overhead are crucial, and security is handled by network segmentation or physical access control.<br><br>The <b>tftp</b> command can operate in two primary modes: a non-interactive mode for direct file transfer using command-line arguments, or an interactive mode where users can issue multiple commands within a TFTP session. It typically communicates on UDP port 69, though other ports can be specified.


title: CAVEATS
content:
TFTP inherently lacks security features such as user authentication, encryption, and directory listing. All transfers are in plain text and are vulnerable to eavesdropping, spoofing, and unauthorized access if the network is not secure. Being UDP-based, it is connectionless and does not guarantee delivery, though <b>tftp</b> clients implement retransmission logic to handle packet loss. Due to its simplicity and security limitations, it is generally not suitable for transferring large files or sensitive data in untrusted environments. Proper firewall rules (UDP port 69) and server-side file permissions are critical for controlling access and ensuring security.


title: INTERACTIVE MODE
content:
When <b>tftp</b> is invoked without the <i>-g</i>, <i>-p</i>, or <i>-c</i> options (and optionally without a <i>host</i>), it enters an interactive mode. In this mode, users can issue multiple commands to control the TFTP session, making it suitable for multiple transfers or changing parameters on the fly. To connect to a server, use the <i>connect</i> command. Below are some common interactive commands:<br><ul><li><i>connect host [port]</i>: Sets the remote <i>host</i> and optional <i>port</i> for subsequent transfers.</li><li><i>mode {netascii|octet|mail}</i>: Sets the file transfer mode for future <i>get</i> or <i>put</i> operations.</li><li><i>get remote-file [local-file]</i>: Downloads <i>remote-file</i> from the server. If <i>local-file</i> is omitted, it defaults to the <i>remote-file</i> name.</li><li><i>put local-file [remote-file]</i>: Uploads <i>local-file</i> to the server. If <i>remote-file</i> is omitted, it defaults to the <i>local-file</i> name.</li><li><i>verbose</i>: Toggles verbose output for command execution and transfer details.</li><li><i>trace</i>: Toggles packet tracing, showing the details of each TFTP packet sent and received, useful for debugging.</li><li><i>status</i>: Displays the current state of the <b>tftp</b> client, including the current remote host, port, and transfer mode.</li><li><i>quit</i> or <i>exit</i>: Exits the interactive <b>tftp</b> session.</li></ul>


title: HISTORY
content:
The Trivial File Transfer Protocol (TFTP) was defined in RFC 783 in June 1981, making it one of the earliest Internet protocols. Its design prioritized simplicity and a small code footprint, making it ideal for bootstrapping operations (like network booting) where a full-featured TCP/IP stack was not yet available or practical (e.g., ROM-based bootloaders). While less common for general-purpose file transfer today due to its inherent security limitations, TFTP remains a standard and crucial component in specific embedded systems, network device configuration, and PXE (Preboot Execution Environment) boot environments.


title: PARAMETERS
content:
<b>tgadevice</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. Specifies the path to the input Truevision Targa (TGA) file. If omitted, <i>tgatoppm</i> reads the TGA data from <i>standard input</i>.<br><br>


title: DESCRIPTION
content:
<i>tgatoppm</i> is a utility from the <I>Netpbm</I> image processing suite. Its primary function is to convert image files in the Truevision Targa (TGA) format into the Portable Pixmap (PPM) format. TGA files are common for storing images, particularly in video games and professional image editing. PPM is a simple, uncompressed image format, part of the Netpbm family, designed for easy manipulation and conversion between various image types.<br><br><i>tgatoppm</i> reads the TGA image from a specified file or <i>standard input</i> if no file is given, and writes the resulting PPM image to <i>standard output</i>. It supports different TGA types, including truecolor, colormapped, and black-and-white, converting them all to truecolor PPM. It also handles both uncompressed and Run-Length Encoded (RLE) TGA data. This conversion is often a crucial step in workflows that require processing TGA files with other Netpbm tools or converting them to more widely supported formats.


title: CAVEATS
content:
<b>Alpha Channel Discarded</b>: <i>tgatoppm</i> ignores any alpha channel information present in 32-bit TGA files. The output PPM format does not support alpha transparency, so this data is lost during conversion.<br><b>Color Mapping to Truecolor</b>: Even if the input TGA file uses a color map (indexed color), the output will always be a <i>truecolor</i> PPM. This may result in larger file sizes for images that could otherwise be represented more compactly.<br><b>Standard Output Only</b>: The command outputs the PPM data exclusively to <i>standard output</i>, requiring redirection (e.g., <code>> output.ppm</code>) to save the result to a file.


title: PIPELINE USAGE
content:
<i>tgatoppm</i> is designed to work seamlessly in command-line pipelines. For example, to convert a TGA file and then apply a gamma correction:<br><code>tgatoppm input.tga | pnmgamma 2.2 > output.ppm</code>


title: INPUT/OUTPUT STREAMS
content:
By default, if no <i>tgadevice</i> argument is provided, the command reads TGA data from <i>standard input</i>. This allows it to process TGA data piped from another command. The output PPM data is always written to <i>standard output</i>.


title: HISTORY
content:
<i>tgatoppm</i> is an integral part of the <I>Netpbm</I> project, a widely used open-source graphics library and toolkit. The Netpbm suite originated from the <I>pbmplus</I> package created by Jef Poskanzer in the late 1980s. Its design emphasizes simple, atomic tools that can be chained together via pipelines, a philosophy that <i>tgatoppm</i> perfectly embodies. It has been maintained and expanded upon by various developers over decades, ensuring its continued relevance for image format conversion on Unix-like systems.


title: SYNOPSIS
content:
<b>tgpt</b> [<i>options</i>] [<i>prompt ...</i>]<br><b>tgpt</b> [<b>--model</b> <i>model_name</i>] [<b>--chat</b> <i>chat_id</i>] [<b>--stream</b>] [<b>--temperature</b> <i>value</i>] [<b>--system</b> <i>"prompt"</i>] [<i>"Your query here."</i>]


title: PARAMETERS
content:
<b><i>prompt ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The text query or instruction to send to the AI model. If the prompt contains spaces, it typically needs to be enclosed in quotes.<br><br><b><b>--model</b> <i>model_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the AI model to use for the request (e.g., <i>gpt-4</i>, <i>gpt-3.5-turbo</i>, <i>gemini-pro</i>, <i>llama</i>). The availability of models depends on the configured API keys and the specific <i><b>tgpt</b></i> implementation.<br><br><b><b>--chat</b> <i>chat_id</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Engages in a conversational session. This option allows <i><b>tgpt</b></i> to maintain and retrieve conversation history using a specified <i>chat_id</i> (e.g., a session name or identifier).<br><br><b><b>--stream</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables streaming output, displaying the AI response character by character or word by word as it is generated, rather than waiting for the entire response to complete.<br><br><b><b>--temperature</b> <i>value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the randomness and creativity of the AI's output. A value closer to <i>0</i> (e.g., <i>0.2</i>) results in more deterministic and focused responses, while a higher value (e.g., <i>0.8</i>) encourages more diverse and creative output.<br><br><b><b>--system</b> <i>"prompt"</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an initial system message or role-playing context to the AI. This guides the AI's behavior or persona for the current query or entire chat session.<br><br><b><b>--list-models</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of AI models that the current <i><b>tgpt</b></i> configuration can access, based on the enabled APIs and keys.<br><br><b><b>--config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens or displays the configuration file for <i><b>tgpt</b></i>, allowing users to inspect or modify API keys, default models, and other settings.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message, detailing the command's usage syntax and all available options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <i><b>tgpt</b></i> script, including its release number and sometimes the underlying AI models it supports.<br><br>


title: DESCRIPTION
content:
<i><b>tgpt</b></i> is a versatile command-line utility designed to provide a seamless interface for interacting with various large language models (LLMs) directly from your terminal. Unlike standard Linux commands, <i><b>tgpt</b></i> is typically a community-driven, user-installed script (often written in Bash or Python) that acts as a wrapper around the APIs of popular AI services like OpenAI's GPT series, Google's Gemini, Anthropic's Claude, and open-source models.<br><br>It enables users to quickly query AI models, generate text, write code, answer questions, and perform other AI-driven tasks without needing to open a web browser. Key features often include support for different models, streaming responses for real-time output, managing conversation history, and customizable parameters like temperature and system prompts, making it an invaluable tool for developers, writers, and anyone looking to integrate AI into their command-line workflow.


title: CAVEATS
content:
<i><b>tgpt</b></i> is not a standard Linux utility and typically requires manual installation from a source like a Git repository. Its operation is contingent on an active internet connection and valid API keys for the specific AI models it interacts with (e.g., OpenAI API key), which may involve usage costs. Users should be aware of data privacy implications, as queries are sent to third-party AI services. The functionality and supported models of <i><b>tgpt</b></i> are subject to changes and updates by the respective AI service providers and the script maintainers.


title: INSTALLATION
content:
<i><b>tgpt</b></i> is typically installed by cloning its Git repository and placing the executable script in a directory included in your system's PATH. A common installation method involves:<br><i>git clone https://github.com/aandrew-me/tgpt.git</i><br><i>cd tgpt</i><br><i>sudo cp tgpt /usr/local/bin/</i><br>Follow the specific instructions from the project's README for the most accurate and up-to-date installation guidance.


title: CONFIGURATION
content:
Before using <i><b>tgpt</b></i>, it's essential to configure your API keys for the desired AI models. This is usually done by editing a configuration file (often located in <i>~/.config/tgpt/tgpt.conf</i> or similar) or by setting environment variables (e.g., <i>OPENAI_API_KEY="your_key_here"</i>, <i>GOOGLE_API_KEY="your_key_here"</i>). Consult the project's documentation for precise configuration steps and supported environment variables.


title: HISTORY
content:
The emergence of <i><b>tgpt</b></i>, and similar command-line interfaces for large language models, closely parallels the public accessibility and widespread adoption of powerful AI models like OpenAI's GPT series, beginning in the early 2020s. These tools were developed by the open-source community to provide a more direct and scriptable way for developers and power users to interact with AI from their terminal, leveraging existing API infrastructures. Unlike traditional Linux commands with decades of history, <i><b>tgpt</b></i>'s development is rapid and continuously evolving to support new AI models, features, and API changes, driven by community contributions rather than being a part of a standard distribution.


title: SYNOPSIS
content:
<B>tgz</B> is a file format, not a direct command. It is handled by the <B>tar</B> utility.<BR><BR><B>To create a .tgz archive:</B><BR><I>tar -czvf &lt;archive_name&gt;.tgz &lt;files_or_directories_to_archive&gt;...</I><BR><BR><B>To extract a .tgz archive:</B><BR><I>tar -xzvf &lt;archive_name&gt;.tgz</I><BR><BR><B>To list contents of a .tgz archive:</B><BR><I>tar -tzvf &lt;archive_name&gt;.tgz</I>


title: PARAMETERS
content:
<b>-c, --create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new archive.<br><br><b>-x, --extract, --get</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts files from an archive.<br><br><b>-z, --gzip, --ungzip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the archive through gzip. This is essential for .tgz files.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbously list files processed. Useful for seeing progress.<br><br><b>-f, --file=ARCHIVE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the archive file to work with. This option is typically required.<br><br><b>-t, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the contents of an archive without extracting them.<br><br><b>-C, --directory=DIR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Change to directory DIR before performing operations. Useful for extracting to a specific location.<br><br><b>--exclude=PATTERN</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching PATTERN from the archive.<br><br>


title: DESCRIPTION
content:
The term <I>tgz</I> (or <I>.tar.gz</I>) is a common file extension for a <B>tar</B> archive that has been compressed using <B>gzip</B>. It combines the functionality of two separate tools:<BR><B>tar</B> (Tape Archive) for bundling multiple files and directories into a single archive file, preserving file permissions, ownership, and directory structures;<BR>and <B>gzip</B> (GNU Zip) for compressing that archive to reduce its size. This combination is widely used in Linux and Unix-like systems for distributing software, backing up data, and packaging files for transfer. While <I>tgz</I> itself is not a command, it refers to the file format, and the <B>tar</B> command with the appropriate options (specifically the <B>-z</B> or <B>--gzip</B> flag) is used to create, extract, list, and manage these archives.


title: CAVEATS
content:
<B>tgz</B> is a <I>file extension</I> and <I>format</I>, not an executable command itself. Operations are performed using the <B>tar</B> command.<BR>Requires the <B>gzip</B> utility to be installed on the system for compression/decompression, though it is standard on most Linux distributions.<BR>Archives can become very large for extensive data sets, and operations can be time-consuming.<BR>By default, <B>tar</B> preserves file permissions, ownership, and timestamps. When extracting as a regular user, ownership might not be restored correctly unless extracted by `root`.


title: CREATING A .TGZ ARCHIVE (EXAMPLE)
content:
<I>To archive a directory named `my_project` into `my_project.tgz`:</I><BR><I>tar -czvf my_project.tgz my_project/</I><BR><I>This command will create a compressed archive in the current directory, showing the files as they are added.</I>


title: EXTRACTING A .TGZ ARCHIVE (EXAMPLE)
content:
<I>To extract `my_project.tgz` into the current directory:</I><BR><I>tar -xzvf my_project.tgz</I><BR><I>To extract it into a specific directory, e.g., `/tmp/extracted_data`:</I><BR><I>tar -xzvf my_project.tgz -C /tmp/extracted_data</I><BR><I>This will decompress and unpack the archive, typically recreating the directory structure within.</I>


title: LISTING CONTENTS OF A .TGZ (EXAMPLE)
content:
<I>To view the files and directories inside `my_project.tgz` without extracting:</I><BR><I>tar -tzvf my_project.tgz</I><BR><I>This is useful for inspecting an archive's contents before full extraction.</I>


title: HISTORY
content:
The <B>tar</B> utility dates back to the early days of Unix in the 1970s, originally designed for writing data to sequential I/O devices like magnetic tape drives. Its ability to bundle multiple files and directories into a single stream made it ideal for archiving and backup.<BR>The <B>gzip</B> compression utility was developed by Jean-loup Gailly and Mark Adler, and first released in 1992. It became the standard compression utility in the GNU project. The combination of <B>tar</B> for archiving and <B>gzip</B> for compression quickly became a popular and efficient way to package files on Unix-like systems, leading to the widespread adoption of the <I>.tar.gz</I> or shorthand <I>.tgz</I> file format.


title: SYNOPSIS
content:
<i>Please note: <b>thc-ipv6</b> is a collection of individual tools, not a single executable command. Each tool has its own specific syntax and options. Below are common invocation patterns for typical tools within the suite:</i><br><br><b>alive6</b> -<i>i</i> <I>interface</I> [<I>target_ipv6</I>]<br><b>attack6</b> -<i>i</i> <I>interface</I> -<i>s</i> <I>source_ipv6</I> -<i>t</i> <I>target_ipv6</I> [<I>options</I>]<br><b>flood_router6</b> -<i>i</i> <I>interface</I> [<I>options</I>]<br><b>fake_router6</b> -<i>i</i> <I>interface</I> [<I>options</I>]


title: PARAMETERS
content:
<b>-i <I>interface</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to use, e.g., eth0 or wlan0.<br><br><b>-s <I>source_ipv6</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the source IPv6 address for the packets being sent.<br><br><b>-d <I>destination_ipv6</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the destination IPv6 address for the packets.<br><br><b>-t <I>target_ipv6</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target IPv6 address or network segment for the operation.<br><br><b>-l <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates a listen port for tools requiring one, or a target port for scanning.<br><br><b>-n <I>count</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of packets to send or iterations to perform.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests a random source or destination address/MAC in some tools.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the tool's execution.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and available options for a specific tool.<br><br>


title: DESCRIPTION
content:
<i>thc-ipv6</i> is a comprehensive suite of tools developed by The Hacker's Choice (THC) for analyzing, attacking, and securing IPv6 networks. Unlike a single command, it comprises over 40 individual utilities designed to test various aspects of IPv6 protocol implementations and network configurations. These tools cover a wide range of attack vectors, including Neighbor Discovery Protocol (NDP) manipulation, Router Advertisement (RA) spoofing, fragmentation attacks, ICMPv6 floods, denial-of-service, and reconnaissance. Network administrators and security professionals commonly use <i>thc-ipv6</i> for penetration testing, vulnerability assessment, and educational purposes to understand the complexities and potential weaknesses in IPv6 deployments. Its modular nature allows users to combine different tools for sophisticated attack scenarios or to precisely target specific vulnerabilities.


title: CAVEATS
content:
<i><b>Ethical Use:</b> <i>thc-ipv6</i> tools are powerful and can cause network disruption, crashes, or denial of service. They must only be used on networks where explicit permission has been granted by the owner. Unauthorized use is illegal and unethical.<br><b>Network Impact:</b> Some tools, particularly those involving flooding or spoofing, can significantly impact network performance, stability, and connectivity, potentially leading to outages.<br><b>Privileges:</b> Most <i>thc-ipv6</i> tools require root or superuser privileges to operate, as they interact directly with network interfaces and raw sockets.</i>


title: TOOL CATEGORIES
content:
<i>The <i>thc-ipv6</i> suite includes tools for various purposes, broadly categorized as:</i><br><b>Reconnaissance:</b> Tools like <i>alive6</i> to discover active IPv6 hosts.<br><b>Attacks:</b> Tools such as <i>attack6</i>, <i>flood_router6</i>, <i>deny6</i> for various DoS and protocol manipulation attacks.<br><b>Spoofing:</b> <i>fake_router6</i>, <i>parasite6</i> for Man-in-the-Middle and fake router scenarios.<br><b>Scanning:</b> <i>v6scan</i> for port scanning.<br><b>Utilities:</b> Tools like <i>thcping6</i>, <i>trace6</i> for basic network diagnostics.


title: INSTALLATION
content:
<i><i>thc-ipv6</i> is typically available in the package repositories of popular Linux distributions (e.g., Debian/Ubuntu: <b>apt install thc-ipv6</b>, Fedora: <b>dnf install thc-ipv6</b>). Users can also compile it from source code, usually found on GitHub or dedicated security tool repositories.</i>


title: HISTORY
content:
<i>The <i>thc-ipv6</i> suite was developed by The Hacker's Choice (THC), a prominent international hacker group known for its open-source security tools and research. The development of these tools began in response to the growing deployment of IPv6 and the need for dedicated tools to assess its security implications. THC recognized that existing IPv4-centric tools were inadequate for effectively testing IPv6 networks, which operate with different protocols and attack vectors. The suite has been continuously updated to address new vulnerabilities and provide comprehensive testing capabilities, establishing itself as a de facto standard for IPv6 penetration testing and security auditing.</i>


title: PARAMETERS
content:
<b><b>-d</b> <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target domain name to search for.<br><br><b><b>-b</b> <I>source</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The data source(s) to use. Common sources include: <i>all</i>, <i>baidu</i>, <i>bing</i>, <i>brave</i>, <i>censys</i>, <i>crtsh</i>, <i>dnsdumpster</i>, <i>duckduckgo</i>, <i>fullhunt</i>, <i>github-code</i>, <i>google</i>, <i>hunter</i>, <i>intelx</i>, <i>linkedin</i>, <i>linkedin_contacts</i>, <i>maxmind</i>, <i>netcraft</i>, <i>otx</i>, <i>pgp</i>, <i>rapiddns</i>, <i>rocketreach</i>, <i>securityTrails</i>, <i>shodan</i>, <i>spyse</i>, <i>subdomain_center</i>, <i>threatcrowd</i>, <i>trello</i>, <i>twitter</i>, <i>urlscan</i>, <i>virustotal</i>, <i>whatweb</i>, <i>zoomeye</i>.<br><br><b><b>-l</b> <I>limit</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of results (default: 500). Some sources may have lower internal limits.<br><br><b><b>-f</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the results to an HTML and/or XML file (e.g., <i>results.html</i>, <i>results.xml</i>).<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a DNS reverse lookup on the discovered IP addresses.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a DNS brute force for hostnames.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a DNS TLD expansion brute force (e.g., .com, .org, .net).<br><br><b><b>-e</b> <I>DNS server</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific DNS server for lookups.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a DNS server enumeration on the target domain.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a port scan on discovered hosts using nmap (requires nmap installed).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version of theharvester.<br><br><b><b>--screenshot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Take screenshots of discovered web pages (requires Playwright and a web browser setup).<br><br><b><b>--take-over</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for possible domain takeovers on discovered CNAME entries.<br><br><b><b>--dns-lookup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform DNS lookups for all discovered hosts to resolve IP addresses.<br><br><b><b>--shodan-lookup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use Shodan to find open ports and banners for discovered hosts (requires a Shodan API key).<br><br>


title: DESCRIPTION
content:
<b>theharvester</b> is a simple but effective open-source intelligence (OSINT) tool used for gathering publicly available information such as email addresses, subdomains, hostnames, employee names, and open ports. It collects data from various public sources including search engines (Google, Bing, Baidu, Yahoo), PGP key servers, LinkedIn, Twitter, and specialized services like Shodan, Censys, and Netcraft. <br><br>The primary purpose of theharvester is to help penetration testers, security researchers, and red teams gather initial reconnaissance data on their target organizations. It automates the process of querying multiple data sources, consolidating the information, and presenting it in a structured format, which can then be used for further analysis, attack surface mapping, or social engineering efforts.


title: CAVEATS
content:
<b>theharvester</b> relies heavily on public API access and search engine scraping. <br> <br>1. <b>API Keys:</b> Many advanced sources (e.g., Shodan, Censys, Hunter.io) require valid API keys, which must be configured in the `api-keys.yaml` file (usually located in `~/.theharvester/`). Without these, certain searches will yield limited or no results. <br>2. <b>Rate Limiting:</b> Search engines and services often implement rate limiting. Excessive or frequent queries can lead to temporary IP blocks or CAPTCHA challenges, reducing the effectiveness of the tool. <br>3. <b>Accuracy:</b> The gathered information is as accurate as the public sources it scrapes. Data might be outdated, incorrect, or misleading. Always verify critical information. <br>4. <b>Legality/Ethics:</b> While OSINT is generally legal, the subsequent use of gathered information (e.g., for unauthorized access attempts) may not be. Always operate within legal and ethical boundaries, and ensure you have proper authorization for any target you are investigating.


title: API KEYS CONFIGURATION
content:
For many advanced sources, <b>theharvester</b> requires API keys. These keys should be stored in a file named <b>api-keys.yaml</b>, typically located in <b>~/.theharvester/</b>. Users need to manually create this file and populate it with their respective API keys for services like Shodan, Censys, Hunter.io, etc. <br> <br>Example entry for Shodan in <i>api-keys.yaml</i>: <br><i>shodan: YOUR_SHODAN_API_KEY</i>


title: INSTALLATION AND DEPENDENCIES
content:
<b>theharvester</b> is often pre-installed on penetration testing distributions like Kali Linux. If not, it can typically be installed via pip: <i>pip3 install theharvester</i>. <br> <br>Some functionalities, like port scanning (<b>-p</b>), require additional tools such as Nmap to be installed on the system. Similarly, the screenshot feature (<b>--screenshot</b>) requires Playwright and a compatible browser to be set up.


title: HISTORY
content:
<b>theharvester</b> was initially developed by Christian Martorella as part of the BackTrack Linux distribution (now Kali Linux). It quickly gained popularity within the penetration testing and security research communities due to its simplicity and effectiveness in automating the initial reconnaissance phase. <br><br>Over the years, it has undergone continuous development, with new data sources being added and existing ones updated to maintain compatibility with changes in search engine algorithms and API endpoints. Its inclusion in major security distributions like Kali Linux has cemented its status as a go-to tool for OSINT.


title: PARAMETERS
content:
<b><i>-white</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts the image colors. By default, the output PBM represents the ThinkJet's black background as black (1) and foreground dots as white (0). This option flips the bits, resulting in a white background (0) and black foreground (1), which is more typical for displaying text.<br><br><b><i>-notrail</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the output of trailing empty rows that are typically generated by ThinkJet printers at the end of a page.<br><br><b><i>pjlfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input file containing the HP ThinkJet printer stream. If omitted, the command reads input from standard input (stdin).<br><br>


title: DESCRIPTION
content:
<i>thinkjettopbm</i> is a utility from the Netpbm package designed to convert print streams intended for HP ThinkJet printers into a portable bitmap (PBM) image format. This command is particularly useful for processing output generated by older applications or `hp2xx`, which would otherwise be sent directly to a ThinkJet or compatible DeskJet 500 printer.<br><br>It reads the printer data, typically from a specified file or standard input, and produces a PBM image on standard output. If the input stream contains multiple pages, <i>thinkjettopbm</i> concatenates them vertically into a single large PBM image. This tool serves as a bridge for visualizing or further processing print data from vintage HP printers in modern environments.


title: CAVEATS
content:
This command is designed for a very specific and old printer technology (HP ThinkJet from the 1980s) and might not be relevant for modern printer formats or systems. It assumes a specific PCL-like stream and may produce unexpected results with other printer data.


title: HISTORY
content:
<i>thinkjettopbm</i> is part of the Netpbm project, a long-standing collection of graphics manipulation utilities. Its existence dates back to the era when HP ThinkJet and DeskJet 500 printers were common, likely developed to provide interoperability and visualization capabilities for their specific printer output streams, particularly in Unix-like environments. Its role has diminished with the obsolescence of these specific printer models, but it remains a historical piece of the Netpbm toolkit.


title: PARAMETERS
content:
<b><b>-?</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options for <i>Thunar</i>.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <i>Thunar</i> application.<br><br><b><b>--bulk-rename</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the <i>Bulk Renamer</i> utility, allowing multiple files to be renamed simultaneously using various patterns.<br><br><b><b>--daemon</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>Thunar</i> in daemon mode in the background. This improves subsequent startup times for new windows.<br><br><b><b>--quit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quits any currently running <i>Thunar</i> daemon process.<br><br><b><b>--new-window</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>Thunar</i> to open a new window, even if an existing window could open a new tab.<br><br><b><b>--tab</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified <i>FILES/DIRECTORIES</i> in new tabs within an existing <i>Thunar</i> window.<br><br><b><b>--browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new <i>Thunar</i> window in 'browser mode', typically displaying the location bar and hiding the toolbar.<br><br><b><b>--list-view</b>, <b>--icon-view</b>, <b>--tree-view</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the initial view mode (list, icon, or tree) for the opened folder(s).<br><br><b><i>FILES/DIRECTORIES...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files or directories that <i>Thunar</i> should open or navigate to.<br><br>


title: DESCRIPTION
content:
<i>Thunar</i> is the default file manager for the <b>Xfce desktop environment</b>. It's designed to be fast, easy to use, and highly customizable. Thunar aims for a clean and intuitive user interface, focusing on responsiveness and low resource usage. It supports common file operations like creating, deleting, moving, copying, and renaming files and directories.<br><br>It also offers features such as tabbed browsing, a sidebar for quick access to locations, and support for volume management and network shares. Its powerful plugin system allows for extended functionality, making it versatile for various user needs while maintaining its lightweight nature. Thunar prioritizes user experience with its focus on simplicity and efficiency.


title: CAVEATS
content:
While <i>Thunar</i> is highly functional, its optimal performance and feature set are realized within the <b>Xfce desktop environment</b>. When used outside <i>Xfce</i>, some integrations (e.g., volume management, trash handling) might rely on additional components or require manual configuration. Its daemon mode is crucial for fast startup, so users should be aware that <i>Thunar</i> might remain running in the background even after closing all windows.


title: PLUGIN SYSTEM
content:
<i>Thunar's</i> architecture is built around a flexible plugin system. This allows users to extend its capabilities significantly without bloating the core application. Popular plugins include support for archive management, image thumbnailers, media tag editors, and version control integration, enhancing its versatility for various tasks.


title: CUSTOM ACTIONS
content:
A powerful feature of <i>Thunar</i> is the ability to define custom actions. Users can create custom commands (e.g., shell scripts) that appear in the context menu for specific file types or selections. This enables highly personalized workflows, allowing quick execution of common tasks directly from the file manager's graphical interface.


title: HISTORY
content:
<i>Thunar</i> was first introduced in <b>2007</b> by Benedikt Meurer as a modern and lightweight replacement for <i>XFFM</i>, the previous file manager in <i>Xfce</i>. Its development has consistently focused on providing a fast, responsive, and easy-to-use experience, adhering to <i>Xfce's</i> philosophy of efficiency and simplicity. Over the years, it has evolved with new features and a robust plugin system, maintaining its position as the default and highly regarded file manager for the <i>Xfce desktop</i>.


title: PARAMETERS
content:
<b><b>-P</b> <i>&lt;profile&gt;</i> or <b>--profile</b> <i>&lt;profile&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>Thunderbird</i> with the specified user profile. If the profile does not exist, a new one may be created.<br><br><b><b>-p</b> or <b>--profile-manager</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the Profile Manager, allowing you to choose, create, or delete user profiles before launching <i>Thunderbird</i>.<br><br><b><b>-no-remote</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>Thunderbird</i> from accepting or sending remote commands, useful for running multiple independent instances or debugging.<br><br><b><b>-compose</b> <i>&lt;args&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new message compose window with predefined recipients, subject, body, or attachments. Arguments are specified as a comma-separated list.<br><br><b><b>-url</b> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified URL within <i>Thunderbird</i>, typically used for mailto: links or RSS feeds.<br><br><b><b>-safe-mode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>Thunderbird</i> in Safe Mode, temporarily disabling add-ons and hardware acceleration, useful for troubleshooting issues.<br><br><b><b>-v</b> or <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <i>Thunderbird</i> version information to the console and exits.<br><br><b><b>-h</b> or <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options and exits.<br><br><b><b>--new-instance</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches a new, separate instance of <i>Thunderbird</i> even if another instance is already running, bypassing the default single-instance behavior.<br><br>


title: DESCRIPTION
content:
<i>Thunderbird</i> is a free, open-source, and cross-platform email, news, RSS, and chat client developed by the Mozilla Foundation. It offers robust features for managing multiple email accounts, including support for POP, IMAP, and SMTP protocols. Users benefit from its powerful message filtering, integrated search capabilities, and customizable interface through themes and extensions.<br><br>A key feature is its integration with the <i>Lightning Calendar</i> add-on, providing comprehensive calendar and task management functionalities directly within the client. <i>Thunderbird</i> is designed for security and privacy, incorporating features like phishing protection, digital signing, and message encryption (S/MIME and OpenPGP). Its extensibility via a vast library of add-ons allows users to tailor the software to their specific needs, from enhanced security to productivity tools. It's a widely used alternative to proprietary email clients on Linux systems.


title: CAVEATS
content:
<i>Thunderbird</i> can be resource-intensive, particularly with numerous email accounts, large mailboxes, or a significant number of installed add-ons. Profile corruption, while rare, can lead to data loss or application instability; regular backups of your profile directory are highly recommended.


title: PROFILE LOCATION
content:
<i>Thunderbird</i> stores all user data, settings, and mail in a profile directory. On Linux, this is typically located under <i>~/.thunderbird/</i>. Each profile has a unique identifier (e.g., <i>&lt;random_string&gt;.default</i>), making it easy to manage multiple distinct user environments.


title: ADD-ONS AND CUSTOMIZATION
content:
A significant strength of <i>Thunderbird</i> is its extensibility through add-ons (extensions, themes, and dictionaries). These can dramatically enhance functionality, provide new features, or alter the user interface, and are available from the <i>Mozilla Add-ons</i> website directly within the application or via a web browser.


title: HISTORY
content:
<i>Thunderbird</i> originated from the Mozilla project, initially as a component of the <i>Mozilla Application Suite</i> (later <i>SeaMonkey</i>), and was formally released as a standalone product in 2004. Developed by the Mozilla Foundation, it shares much of its underlying code and heritage with the <i>Firefox</i> web browser, including the Gecko rendering engine. Over the years, its development has seen shifts, with the Mozilla Foundation stepping back from direct day-to-day development in favor of community and external contributions, though they continue to provide infrastructure and oversight. It has consistently remained a popular open-source choice for email, evolving with new features like the integrated calendar and improved security.


title: PARAMETERS
content:
<b><i>file</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input files containing terminfo source descriptions. If no files are given, <b>tic</b> reads from standard input.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only: Parse the input files but do not write any compiled entries. Useful for syntax validation.<br><br><b>-e <i>names</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile only the entries specified by a comma-separated list of <i>names</i> from the input files. Other entries are ignored.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force writing of entries, even if an identical entry already exists in the database. By default, <b>tic</b> will not overwrite identical entries.<br><br><b>-I <i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>dir</i> to the list of directories to search for <b>include</b> files referenced within the terminfo source.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Translate names for old ncurses libraries, ensuring compatibility with older applications or ncurses versions.<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress checks for ncurses extensions when compiling. This might be useful for strict terminfo compliance.<br><br><b>-o <i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output directory where the compiled terminfo entries should be stored. Defaults to the standard terminfo database path.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force recompilation of all entries. This will overwrite existing entries, even if they appear identical.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Silent mode: Suppress warnings during compilation. Only errors will be reported.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unlimit: Allow very long names or string capabilities beyond the traditional terminfo limits. Useful for extended descriptions.<br><br><b>-v[<i>n</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose mode: Increase the verbosity level of output. A higher number <i>n</i> (e.g., -v2, -v3) produces more detailed messages.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version of <b>tic</b> and the ncurses library it uses, then exit.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow extended capabilities: Process terminfo source files that use extended (user-defined) capabilities not standard in the terminfo database.<br><br>


title: DESCRIPTION
content:
The <b>tic</b> (terminfo compiler) command compiles a terminfo source description into a binary format. Terminfo source files describe the capabilities of terminals, allowing applications like <b>ncurses</b>-based programs to adapt their behavior to different terminal types. The compiled entries are stored in a hierarchical database, typically located at <i>/usr/share/terminfo</i> or <i>~/.terminfo</i>. When a program needs to know about a terminal's capabilities (e.g., how to clear the screen, move the cursor, or set colors), it queries this database. <b>tic</b> is an essential tool for maintaining and extending the terminfo database, enabling support for new terminals or custom terminal configurations.


title: CAVEATS
content:
Compiling a terminfo entry overwrites any existing entry with the same name. Always back up your <i>terminfo</i> database or test new entries carefully before deploying to a production environment. Incorrectly compiled or malformed entries can lead to display issues or errors in terminal applications. Be aware of the search order for <i>terminfo</i> databases, as a local entry in <i>~/.terminfo</i> can override a system-wide entry.


title: TERMINFO DATABASE LOCATION
content:
By default, <b>tic</b> compiles entries into the <i>terminfo</i> database located at <i>/usr/share/terminfo</i> (system-wide) or <i>/etc/terminfo</i>. Users can also have a private <i>terminfo</i> database in their home directory, typically at <i>~/.terminfo</i>. The <b>TERMINFO</b> environment variable can be used to specify an alternative base directory for the <i>terminfo</i> database.


title: ENVIRONMENT VARIABLES
content:
<ul><li><b>TERMINFO</b>: Specifies the path to the <i>terminfo</i> database directory. If set, <b>tic</b> will write to this directory.</li><li><b>TERMINFO_DIRS</b>: A colon-separated list of directories to search for <i>terminfo</i> entries, used by applications (not primarily by <b>tic</b> for writing, but relevant for understanding database interaction).</li></ul>


title: HISTORY
content:
The <b>tic</b> command is a fundamental component of the <i>ncurses</i> (new curses) library, which is a free software emulation of the System V Release 4.0 (SVr4) curses library. The <i>curses</i> library itself originated in BSD Unix and was later standardized by POSIX. <i>Terminfo</i> was introduced in SVr2 as a successor to the simpler <i>termcap</i> system, providing a more structured and extensible way to describe terminal capabilities. <b>tic</b> was developed as part of the <i>ncurses</i> project to compile these <i>terminfo</i> source descriptions into the binary format used by terminal-aware applications, ensuring continued compatibility and flexibility for a wide range of terminal types.


title: SYNOPSIS
content:
<b><I>tidy</I></b> [<i>options</i>] [<i>input_file</i>]<br><b><I>tidy</I></b> [<i>options</i>] [<i>input_file</i>] <b>-o</b> <i>output_file</i><br><b><I>cat</I></b> <i>input_file</i> | <b><I>tidy</I></b> [<i>options</i>] > <i>output_file</i><br>The <b><I>tidy</I></b> command processes an HTML, XHTML, or XML file (or standard input) and writes the cleaned, corrected, or converted output to standard output or a specified file. <i>options</i> control the behavior and formatting.


title: PARAMETERS
content:
<b>-o <file>, --output <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file. If omitted, output goes to standard output.<br><br><b>-m, --modify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies the input file(s) in place, overwriting the original with the tidied version. Use with caution.<br><br><b>-i, --indent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables intelligent indentation of elements to improve readability. Can be further configured with --indent-spaces.<br><br><b>-c, --clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes proprietary HTML tags and attributes, often from word processors, to produce cleaner, standard-compliant markup.<br><br><b>-xml, --xml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats the input as generic XML, ensuring well-formedness and pretty-printing XML structures.<br><br><b>-asxml, --asxml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the document as XML, potentially converting HTML to a well-formed XML syntax.<br><br><b>-xhtml, --asxhtml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the document as XHTML, enforcing XHTML syntax rules.<br><br><b>-html, --ashtml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the document as HTML, typically HTML5, correcting syntax to modern HTML standards.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output of warnings and errors, useful for automated scripts where only the tidied output is desired.<br><br><b>-e, --errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays only errors, suppressing warnings. Useful for focusing on critical issues.<br><br><b>-config <file>, --config-file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to load settings from, overriding default or environmental configurations.<br><br><b>--doctype <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the DOCTYPE declaration. Common values include 'auto', 'omit', 'strict', 'transitional', 'html5'.<br><br><b>--wrap <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum column width for wrapping text and tags. A value of 0 disables wrapping.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message listing all command-line options and configuration settings.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <b><I>tidy</I></b> utility.<br><br>


title: DESCRIPTION
content:
The <b><I>tidy</I></b> command is a versatile command-line utility and library designed to clean up, correct, and format HTML, XHTML, and XML documents. Developed by Dave Raggett of the W3C, it serves as an invaluable tool for web developers, content creators, and automated systems. <b><I>tidy</I></b> can fix common markup errors, ensure compliance with web standards, and pretty-print documents for better readability.<br><br>Its core functionalities include error detection and correction (e.g., missing closing tags, unquoted attributes), conversion between different markup standards (like HTML to XHTML), and enforcement of accessibility guidelines. Users can configure <b><I>tidy</I></b> extensively to control output format, tag casing, indentation, and much more, either via command-line options or dedicated configuration files. It's frequently used in automated workflows for validating web content, preparing documents for publication, or simply improving the quality and consistency of markup.


title: CAVEATS
content:
<b><I>tidy</I></b> is a powerful tool, but users should be aware of certain limitations and behaviors:<br><I>Over-correction:</I> While designed to fix errors, in some rare cases, <b><I>tidy</I></b> might interpret unconventional but valid markup as an error and alter it in an unintended way.<br><I>Strictness:</I> For very malformed or proprietary markup, <b><I>tidy</I></b> might struggle to produce perfectly clean output or might report numerous errors that require manual intervention.<br><I>XML Validity vs. Well-formedness:</I> When treating input as XML or outputting as XML, <b><I>tidy</I></b> primarily ensures XML well-formedness (correct syntax) but does not validate against a DTD or XML Schema (which requires a dedicated XML validator like <b><I>xmllint</I></b>).<br><I>Configuration Complexity:</I> With hundreds of possible configuration options, mastering <b><I>tidy</I></b>'s full capabilities and fine-tuning its behavior for specific needs can require significant effort.


title: CONFIGURATION FILES
content:
<b><I>tidy</I></b> can load configuration options from a file, typically named <I>.tidyrc</I> or <I>tidy.conf</I>. This allows users to define a set of default or project-specific settings, avoiding the need to specify numerous command-line options every time. The <I>--config-file</I> option can be used to specify a custom configuration file path.


title: INTEGRATION INTO WORKFLOWS
content:
Due to its command-line interface and robust capabilities, <b><I>tidy</I></b> is frequently integrated into automated build systems, continuous integration pipelines, and text editor plugins. It's used for pre-commit checks, ensuring code quality, converting legacy documents, and preparing content for web publication.


title: ERROR AND WARNING REPORTING
content:
Beyond simply cleaning markup, <b><I>tidy</I></b> provides detailed reports of errors and warnings encountered during processing. This diagnostic output is invaluable for debugging HTML issues, understanding standard violations, and improving overall document quality. The verbosity of these reports can be controlled with options like <I>--quiet</I> or <I>--errors-only</I>.


title: HISTORY
content:
HTML Tidy was originally developed by <b>Dave Raggett</b>, a leading figure at the <b>World Wide Web Consortium (W3C)</b>, with its first public release around 1998. Raggett created <b><I>tidy</I></b> to help web authors produce cleaner, more compliant HTML markup, addressing the common issues of poorly structured or non-standard code prevalent in the early days of the web. It quickly became an indispensable tool for validating web content and ensuring adherence to HTML and XHTML standards.<br><br>While initially developed and maintained by the W3C, its development has since transitioned to an open-source community effort. Various forks and projects have emerged over time to continue its maintenance and evolution, notably the HTML Tidy Project on SourceForge and later on GitHub, ensuring its continued relevance and adaptation to new web standards like HTML5. Its enduring presence underscores its utility in automated web development workflows and quality assurance processes.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print raw tag values (hex and ASCII) for <b>all</b> tags, including private tags.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print header information only; do not scan through image data.<br><br><b>-j</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output information as a single JSON object. This option is available in <i>libtiff</i> versions 4.5.0 and newer.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print tag values literally (e.g., numbers instead of symbolic names).<br><br><b>-o <i>offset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial TIFF directory offset to <i>offset</i>.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress warning messages (quiet mode).<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print raw tag values (hex and ASCII) for <b>known</b> tags only.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the size of each image (width and height).<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print uncompressed data size.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose mode, printing the contents of each TIFF field. This is the default behavior.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable warning messages. This is the default behavior.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Count and print the number of strips or tiles for each image.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print pixel format information (e.g., RGB, CMYK).<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print image dimensions (width, height, samples per pixel, bits per sample).<br><br><b>-M</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print image data organization information (e.g., PlanarConfiguration).<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print prediction scheme information (e.g., Predictor tag).<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print extra samples information.<br><br><b>-y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print YCbCr color space information.<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print ZLib compression information.<br><br>


title: DESCRIPTION
content:
<i>tiffinfo</i> is a powerful command-line utility designed for inspecting and debugging Tagged Image File Format (TIFF) files. It provides a comprehensive breakdown of a TIFF file's structure, starting with its header, and then detailing each individual image (or directory) contained within.<br>For each image, <i>tiffinfo</i> presents a wealth of information, including various tag contents, image dimensions (width, height, bits per sample, samples per pixel), applied compression schemes, and pixel formats.<br>This tool is invaluable for developers, graphic professionals, and users who need to deeply understand the internal structure and properties of TIFF images, making it essential for diagnosing file corruption, verifying metadata, or analyzing image characteristics. It often serves as a foundational inspection tool when working with the broader <i>libtiff</i> utility suite.


title: CAVEATS
content:
The <i>-j</i> (JSON output) option is a relatively new feature introduced in <i>libtiff</i> 4.5.0. It may not be available on older systems or distributions.<br>The command's output can be very verbose, especially without specific filtering options, making it suitable for programmatic parsing or detailed manual inspection.


title: DEFAULT OUTPUT VERBOSITY AND TAG REPRESENTATION
content:
By default, <i>tiffinfo</i> provides a detailed output, including the contents of each TIFF field. The <i>-v</i> option explicitly reiterates this default verbose behavior.<br>Tag values are typically printed symbolically (e.g., "MINISWHITE" for a <i>PhotometricInterpretation</i> value of 0) for better human readability.<br>To view the literal numeric values of tags instead, the <i>-L</i> option can be used.


title: HISTORY
content:
<i>tiffinfo</i> is a core utility of the <i>libtiff</i> software suite, which has been under continuous development since the early 1990s. Its fundamental role in providing detailed insight into TIFF file structures has remained constant, with incremental enhancements and new options (such as JSON output) being added over time to support modern requirements and improved usability.


title: PARAMETERS
content:
<b><b>-alphaout</b>=<I>alpha_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts the alpha (transparency) channel into a separate PGM file specified by <I>alpha_file</I>.<br><br><b><b>-headerdump</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the raw TIFF header information to standard error and then exits, without converting the image.<br><br><b><b>-rowmajor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes image data in row-major order (top to bottom), overriding any internal TIFF strip/tile order.<br><br><b><b>-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interprets color values as linear, not sRGB, which is useful when dealing with ICC color profiles.<br><br><b><b>-colorf</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <b>-color</b> but performs color calculations using floating-point precision for potentially higher accuracy.<br><br><b><b>-truecolor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces 24-bit color output (PPM) even for palette-based TIFF images, expanding the palette to true color.<br><br><b><b>-linear</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables gamma correction, treating color values as linear intensity rather than gamma-corrected values.<br><br><b><b>-gamma</b>=<I>float</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a specific gamma correction factor, specified as a floating-point value.<br><br><b><b>-maxsample</b>=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum sample value for output pixels, overriding the default derived from the TIFF file.<br><br><b><b>-raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a raw PBM, PGM, or PPM image without the Netpbm header, for specific applications that handle raw pixel data directly.<br><br><b><b>-rowsperstrip</b>=<I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum number of rows to process per strip, influencing memory usage during conversion.<br><br><b><b>-nofixg3</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables certain fixes for issues sometimes found in Group 3 (fax) compressed TIFF files.<br><br><b><b>-multipage</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes all pages of a multi-page TIFF file, producing multiple Netpbm outputs, typically concatenated.<br><br><b><b>-page</b>=<I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific page (<I>num</I>) from a multi-page TIFF file to convert. Pages are 0-indexed.<br><br><b><b>-nopretty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables pretty-printing of the Netpbm output header, making it more compact (primarily for internal Netpbm testing).<br><br><b><b>-verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints informative messages about the conversion process and TIFF file details to standard error.<br><br><b><b>-extension</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows specifying a different extension for the input TIFF file, useful for files with non-standard naming.<br><br>


title: DESCRIPTION
content:
<br><b>tifftopnm</b> is a utility from the <I>Netpbm</I> image manipulation suite that converts images in the Tagged Image File Format (TIFF) into one of the Netpbm formats: PBM (Portable Bitmap), PGM (Portable Graymap), or PPM (Portable Pixmap). The specific Netpbm format produced depends on the characteristics of the input TIFF image, such as its color depth and type (e.g., bilevel, grayscale, or color).<br><br>This command is essential for processing TIFF files within the Netpbm ecosystem, allowing users to leverage Netpbm's extensive array of tools for further image manipulation, such as scaling, cropping, or format conversion to other image types. It supports a wide range of TIFF compressions and features, making it a robust solution for integrating TIFF images into script-based or automated workflows. The output is typically directed to standard output, making it suitable for piping to other Netpbm commands.


title: CAVEATS
content:
<b>tifftopnm</b> relies heavily on the <I>libtiff</I> library; limitations or bugs within <I>libtiff</I> may affect its behavior.<br><br>Complex or non-standard TIFF tags might not be fully supported, potentially leading to partial or incorrect conversions.<br><br>Output is to standard output (<I>stdout</I>), so redirection (`>`) is necessary to save the converted image to a file. For multi-page TIFFs with <b>-multipage</b>, this will concatenate all pages' output.


title: OUTPUT FORMAT DETERMINATION
content:
<b>tifftopnm</b> automatically determines the appropriate Netpbm output format (PBM for bilevel, PGM for grayscale, or PPM for color) based on the input TIFF file's characteristics. This automatic detection simplifies usage, as users typically don't need to specify the output type explicitly.


title: PIPING OUTPUT
content:
True to its Unix philosophy, <b>tifftopnm</b> writes its converted image data to standard output. This design allows it to be easily piped as input to other Netpbm commands or standard Unix utilities for further processing, such as <I>pnmscale</I> for resizing, <I>cjpeg</I> for JPEG conversion, or simply redirected to a file for saving the output.


title: HISTORY
content:
<b>tifftopnm</b> is a component of the Netpbm project, a comprehensive toolkit for graphic file conversion and manipulation. Netpbm originated in the early 1990s as a successor to the PBMPLUS package, emphasizing a "toolkit" philosophy: providing small, simple, and powerful tools that can be chained together using Unix pipes. <b>tifftopnm</b> was developed to bridge the gap between the widely used TIFF format and the flexible Netpbm formats, enabling seamless interoperability and leveraging the extensive array of Netpbm utilities for image processing. Its continuous development reflects ongoing support for new TIFF features and compression schemes.


title: SYNOPSIS
content:
<b>tig</b> [<I>options</I>] [<I>rev-list-options</I>] [<I>log-options</I>] [<I>diff-options</I>] [<I>path</I>...]<br><b>tig</b> <I>mode</I> [<I>options</I>] [<I>args</I>]


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of <b>tig</b> and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br><b>--log</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start <b>tig</b> in the log view (this is the default behavior).<br><br><b>--status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start <b>tig</b> in the status view, showing changes in the working tree and index.<br><br><b>--diff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start <b>tig</b> in the diff view, useful for comparing specific commits or branches.<br><br><b>--tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start <b>tig</b> in the tree view, allowing browsing of a tree object's contents at a specific commit.<br><br><b>--blame</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start <b>tig</b> in the blame view, showing line-by-line authorship for a given file.<br><br><b>-p, --patch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the full diff (patch) for each commit directly within the log view.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show commits from all refs (branches, tags, and remote-tracking branches).<br><br><b>-C <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <b>tig</b> as if it was started in the specified directory <I>&#60;path&#62;</I>.<br><br><b>-S <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for commits whose message or diff content matches the given <I>&#60;pattern&#62;</I>.<br><br><b>-L <start>,<end>:<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show line history for <I>&#60;file&#62;</I> from line <I>&#60;start&#62;</I> to <I>&#60;end&#62;</I> in blame view.<br><br>


title: DESCRIPTION
content:
<b>tig</b> is a free and open-source text-mode interface for Git. It functions primarily as a <B>ncurses</B>-based browser for Git repositories, allowing users to navigate commit history, view diffs, browse branches, and much more, all within a terminal window.<br><br>It provides a visual and interactive way to explore a Git repository without needing a graphical interface. <b>tig</b> excels at presenting Git objects like commits, trees, blobs, and diffs in a structured and easily traversable manner. Its capabilities include a <I>log</I> view, <I>diff</I> view, <I>status</I> view, <I>tree</I> view, <I>blame</I> view, and the ability to stage/unstage changes. It is highly configurable and extensible, making it a powerful tool for terminal-centric Git workflows.


title: CAVEATS
content:
<b>tig</b> primarily functions as a viewer; while it offers some write capabilities (like staging/unstaging), it's not a full-fledged Git client for complex operations like interactive rebasing or merging. Performance might degrade slightly on extremely large repositories with millions of commits or very massive diffs, though it's generally highly optimized.<br><br>It requires a <B>ncurses</B>-compatible terminal environment to operate correctly.


title: KEYBINDINGS
content:
<b>tig</b> is highly interactive and relies heavily on keyboard shortcuts for navigation and actions. Common keys include <I>j</I>/<I>k</I> for line-by-line movement, <I>Enter</I> to open an item (e.g., a commit or file), <I>q</I> to quit or go back to the previous view, <I>s</I> for status view, <I>d</I> for diff view, <I>m</I> for main (log) view, and <I>/</I> for searching.


title: CUSTOMIZATION
content:
Users can extensively customize <b>tig</b>'s behavior and appearance via a configuration file (typically located at <I>~/.config/tig/config</I> or <I>~/.tigrc</I>). This allows defining custom keybindings, color schemes, and command aliases to tailor the tool to individual preferences.


title: SCRIPTABILITY
content:
<b>tig</b> supports a <B>--batch</B> mode and related options (<B>--no-quit</B>, <B>--exit-as-pager</B>) for scripting, enabling its use in non-interactive scenarios to extract and process Git repository information.


title: HISTORY
content:
<b>tig</b> was created by <B>Jonas Fonseca</B> and first released around <B>2006</B>. It was designed to provide a lightweight, fast, and intuitive text-mode interface for Git, complementing the command-line tools. Over the years, it has gained significant popularity in the Git community due to its efficiency and rich feature set, becoming a go-to tool for many developers who prefer a terminal-centric workflow. Its development has been community-driven, with contributions from many users worldwide.


title: PARAMETERS
content:
<b><b>-p</b>, <b>--portability</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the portable output format, providing a simpler and standardized report suitable for parsing across different systems.<br><br><b><b>-o</b> <I>FILE</I>, <b>--output=</b><I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the time statistics to <I>FILE</I> instead of standard error. Useful for logging or programmatic access to the results.<br><br><b><b>-a</b>, <b>--append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>-o</b>, append the output to the specified file rather than overwriting it, allowing multiple measurements to be logged.<br><br><b><b>-f</b> <I>FORMAT</I>, <b>--format=</b><I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format using a string that contains special escape sequences (e.g., %U for user time, %S for system time). Gives full control over the displayed metrics.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a verbose output, displaying all available information about the command's resource usage in a human-readable format, including memory and I/O statistics.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not report the exit status of the command itself, only the timing information. This is useful in scripts where the command's success/failure is handled separately.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with command usage and options, then exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information for the GNU <I>time</I> utility and exit.<br><br>


title: DESCRIPTION
content:
The <b>time</b> command executes a specified command and reports a summary of the system resources used by that command. This includes the <I>real</I> (wall clock) time elapsed, the <I>user</I> CPU time spent, and the <I>system</I> CPU time spent. It's an invaluable tool for performance profiling, allowing developers and system administrators to understand how efficiently a program utilizes CPU resources and how much time it spends waiting for I/O or other system operations. While many shells have a built-in <I>time</I> command with basic functionality, the external GNU <I>time</I> utility (typically found at <I>/usr/bin/time</I>) offers more advanced features, such as customizable output formats and the ability to output results to a file, making it more flexible for scripting and detailed analysis.


title: CAVEATS
content:
The behavior and available options of <I>time</I> can vary significantly between shell built-ins (e.g., Bash, Zsh) and the external GNU <I>time</I> utility (<I>/usr/bin/time</I>). Shell built-ins typically offer fewer features and a fixed output format. To ensure you're using the GNU <I>time</I> utility with its full capabilities, always invoke it explicitly as <I>/usr/bin/time</I> or use the <I>command</I> built-in (e.g., <I>command time my_script.sh</I>) to bypass the shell's built-in version.


title: BUILT-IN VS. EXTERNAL <I>TIME</I>
content:
Many modern shells (Bash, Zsh, Dash) include a built-in <I>time</I> command. This built-in is executed directly by the shell, making it faster and sometimes reporting slightly different metrics than the external <I>/usr/bin/time</I> program. The built-in usually has limited options. To force the use of the external GNU <I>time</I> utility, you can specify its full path (<I>/usr/bin/time</I>) or use the <I>command</I> built-in (<I>command time</I>) to bypass the shell's built-in version.


title: UNDERSTANDING TIME METRICS
content:
The output of <I>time</I> typically includes three key metrics:<br><ul><li><b>Real Time:</b> The actual wall-clock time elapsed from the start to the end of the command. This includes time spent waiting for I/O, other processes, or network activity.</li><li><b>User CPU Time:</b> The amount of CPU time spent in user mode (executing the program's own code) by the process. This is the time the CPU spent actively running your code.</li><li><b>System CPU Time:</b> The amount of CPU time spent in kernel mode (performing system calls like file I/O, process creation, or network operations) on behalf of the process.</li></ul>Comparing these values helps identify bottlenecks; high real time with low user/sys time suggests I/O or network waits, while high user/sys time suggests CPU-bound operations.


title: HISTORY
content:
The <I>time</I> command has been a fundamental utility in Unix-like operating systems since their early days, providing a simple way to measure program execution performance. Over time, different implementations emerged, most notably the shell built-in versions (which are typically simpler and faster as they don't require spawning a new process) and the external GNU <I>time</I> utility. The GNU version, developed as part of the GNU Project, significantly expanded its capabilities, introducing customizable output formats and a wider range of reported metrics, making it a more powerful tool for detailed analysis and scripting.


title: SYNOPSIS
content:
<b>timedatectl</b> [<i>OPTIONS...</i>] {<i>COMMAND</i>} [<i>ARGUMENTS...</i>]<br><br><u>Common Commands:</u><br><b>timedatectl status</b><br><b>timedatectl set-time</b> <i>'YYYY-MM-DD HH:MM:SS'</i><br><b>timedatectl set-timezone</b> <i>TIMEZONE</i><br><b>timedatectl list-timezones</b><br><b>timedatectl set-ntp</b> [<i>true|false</i>]<br><b>timedatectl set-local-rtc</b> [<i>true|false</i>] [<i>--adjust-system-clock</i>]


title: PARAMETERS
content:
<b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current system time, date, timezone, NTP synchronization status, and RTC information.<br><br><b>set-time 'YYYY-MM-DD HH:MM:SS'</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the system's date and time. The format must be a valid timestamp string like '2023-10-27 15:30:00'.<br><br><b>set-timezone TIMEZONE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the system's timezone. Use <b>list-timezones</b> to find valid timezone names (e.g., 'America/New_York').<br><br><b>list-timezones</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all known timezones available on the system.<br><br><b>set-ntp [true|false]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables NTP (Network Time Protocol) synchronization. 'true' enables, 'false' disables.<br><br><b>set-local-rtc [true|false]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures whether the RTC (Real Time Clock) is kept in local time ('true') or Coordinated Universal Time (UTC) ('false'). Default is UTC.<br><br><b>--adjust-system-clock</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <b>set-local-rtc</b>) Immediately adjusts the system clock to match the new RTC setting when changing the RTC mode.<br><br><b>show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows properties of the time and date settings in a machine-readable format.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<i>timedatectl</i> is a command-line utility part of the <b>systemd</b> suite, designed to query and change the system clock and its settings. It provides a modern, unified interface for managing time configurations on Linux distributions that use systemd. This includes setting the system's current time and date, configuring the timezone, enabling or disabling Network Time Protocol (NTP) synchronization, and managing the Real Time Clock (RTC) settings.<br><br>It replaces or integrates functionalities previously handled by disparate tools like <i>hwclock</i> and <i>date</i>, offering a more streamlined approach. <i>timedatectl</i> distinguishes between the system clock (a software clock maintained by the kernel) and the hardware clock (RTC) and facilitates their synchronization. Most modifications to time and date settings require superuser privileges.


title: CAVEATS
content:
<ul><li>Most <i>timedatectl</i> commands that modify system settings (e.g., <b>set-time</b>, <b>set-timezone</b>) require root privileges to execute successfully.</li><li>Manually setting the time (<b>set-time</b>) while NTP synchronization is active can cause conflicts, as NTP will continuously attempt to correct the clock. It's generally advised to disable NTP or let NTP manage time entirely.</li><li>Incorrectly configuring <b>set-local-rtc</b> (e.g., setting RTC to local time when the OS expects UTC) can lead to time discrepancies, especially in dual-boot environments with operating systems like Windows that often assume local RTC.</li></ul>


title: HISTORY
content:
<i>timedatectl</i> emerged as a core utility within the <b>systemd</b> project, which began development in 2010. Its inclusion signified a shift towards a more integrated and unified approach to system management in modern Linux distributions. As <b>systemd</b> progressively replaced older init systems like SysVinit, <i>timedatectl</i> became the standard command for time and date configuration on systems running <b>systemd</b>, such as Fedora, CentOS/RHEL 7+, and Ubuntu 15.04+.


title: SYNOPSIS
content:
<I>timeout</I> [<I>OPTION</I>] <I>DURATION</I> <I>COMMAND</I> [<I>ARG</I>]...<br>Where <I>DURATION</I> is a number followed by an optional unit: <I>s</I> (seconds, default), <I>m</I> (minutes), <I>h</I> (hours), <I>d</I> (days).


title: PARAMETERS
content:
<b>--foreground</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not terminate <I>timeout</I> if <I>COMMAND</I> exits; only kill <I>COMMAND</I> itself.<br><br><b>-k <I>DURATION</I>, --kill-after=<I>DURATION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Send <I>SIGKILL</I> after this <I>DURATION</I> if <I>COMMAND</I> is still running after the initial signal.<br><br><b>--preserve-status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with the status of <I>COMMAND</I> if it exits before timeout, otherwise with 124 (timeout status).<br><br><b>-s <I>SIGNAL</I>, --signal=<I>SIGNAL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the signal to send upon timeout. <I>SIGNAL</I> can be a name (e.g., <I>HUP</I>, <I>INT</I>, <I>TERM</I>) or a number. Default is <I>SIGTERM</I> (15).<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more information about status on <I>stderr</I>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
The <I>timeout</I> command is a utility in Linux that allows you to run a command and automatically terminate it if it runs for a specified duration. This is particularly useful for controlling processes that might hang indefinitely, consume excessive resources, or when you need to enforce a maximum execution time for scripts or applications. <br><br>When the specified time limit is reached, <I>timeout</I> sends a <I>SIGTERM</I> signal to the command by default, giving it a chance to gracefully shut down. If the command does not exit after an additional grace period (specified by <I>--kill-after</I>), a <I>SIGKILL</I> signal is sent, which forcibly terminates the process. <br><br>It's an essential tool for robust shell scripting, continuous integration environments, and managing system resources, ensuring that long-running or misbehaving commands do not indefinitely block other operations or exhaust system memory and CPU. It helps in creating more resilient and predictable automation workflows.


title: CAVEATS
content:
<B>Process Groups</B>: By default, <I>timeout</I> sends signals to the entire process group of the <I>COMMAND</I>. If <I>COMMAND</I> spawns background processes not in its original process group, they might not be terminated. Consider using <I>--foreground</I> or managing sub-processes within the command.<br><br><B>Signal Handling</B>: The <I>COMMAND</I> might catch and ignore <I>SIGTERM</I> or other specified signals. The <I>--kill-after</I> option is crucial in such cases to ensure eventual termination with <I>SIGKILL</I>.<br><br><B>Exit Status</B>: <I>timeout</I> returns 124 if the command times out. If the command exits before timeout, <I>timeout</I> returns the command's exit status. This behavior can be altered by <I>--preserve-status</I>.


title: DEFAULT SIGNAL
content:
By default, <I>timeout</I> sends <I>SIGTERM</I> (signal 15) when the time limit expires. This signal can be caught by programs, allowing them to perform cleanup before exiting.


title: FORCED TERMINATION
content:
If a program does not exit after receiving <I>SIGTERM</I> (or the signal specified by <I>--signal</I>), and <I>--kill-after</I> is used, <I>timeout</I> will send <I>SIGKILL</I> (signal 9), which cannot be caught or ignored by the process, ensuring its termination.


title: RETURN CODES
content:
A return code of 124 indicates that the command timed out. Any other return code is typically the exit status of the <I>COMMAND</I> itself, unless <I>timeout</I> itself encountered an error.


title: HISTORY
content:
The <I>timeout</I> command is part of the <B>GNU Coreutils</B> package, a fundamental set of utilities for Unix-like operating systems. It was introduced to provide a standardized and reliable way to enforce execution time limits, filling a common need in scripting and automation where a simple <I>sleep</I> and <I>kill</I> sequence might be race-prone or overly complex to implement robustly for different scenarios. Its inclusion in coreutils ensures its wide availability and consistent behavior across Linux distributions.


title: DESCRIPTION
content:
The <b>times</b> command is a shell built-in that displays the cumulative user and system CPU times consumed by the shell itself and by any child processes that have terminated. <i>User time</i> is the amount of time the CPU spends executing code in user mode, while <i>system time</i> is the amount of time the CPU spends executing code in kernel mode on behalf of the process. This command provides a quick overview of the CPU resources utilized by the current shell session and its completed background jobs or commands. It's particularly useful for understanding the resource consumption of scripts or interactive sessions.<br><br>Unlike the external <b>time</b> utility, <b>times</b> aggregates the statistics for all child processes that have exited since the shell started or since the last <b>times</b> command was executed. It's a fundamental tool for basic performance monitoring within a shell environment.


title: CAVEATS
content:
<b>times</b> is a shell built-in command, meaning its behavior and exact output format can vary slightly between different shells (e.g., Bash, Zsh, Ksh).<br>It reports <i>cumulative</i> CPU times for <i>completed</i> child processes, not for currently running processes.<br>It measures CPU time, not wall-clock (real) time.<br>The times reported for children are for <i>all</i> children that have terminated since the shell started or the last call to <b>times</b>, not just the most recently completed one.


title: OUTPUT FORMAT EXPLAINED
content:
The output typically consists of two lines:<br>The first line displays the cumulative user and system time for the <i>shell itself</i>.<br>The second line, if any children have terminated, shows the cumulative user and system time for <i>all children</i> of the shell that have completed execution since the shell started or the last <b>times</b> command was run.<br><br>For example:<br>0m0.00s 0m0.00s<br>0m0.00s 0m0.00s<br>The format 'minutesmseconds.milliseconds' is common, but some shells might just output total seconds or a different precision. The exact format depends on the shell implementation.


title: HISTORY
content:
The <b>times</b> command is a standard part of the POSIX shell specification, making it available across various Unix-like operating systems and shells compliant with POSIX. Its purpose has remained consistent: to provide an aggregate view of CPU time consumption for the shell and its children. It has been a stable and fundamental feature of shell environments for a long time, evolving as part of the broader shell specifications.


title: SYNOPSIS
content:
<b>timeshift</b> [<b>OPTIONS</b>] [<b>COMMAND</b>]<br><br><b>Common Commands:</b><br><b>timeshift create</b> [--comments "text"] [--tags daily|hourly|weekly|monthly|boot|manual]<br><i>Creates a new snapshot.</i><br><br><b>timeshift restore</b> [--snapshot N] [--target /path/to/restore]<br><i>Restores the system to a specified snapshot.</i><br><br><b>timeshift delete</b> [--all] [--snapshot N] [--tags tag]<br><i>Deletes existing snapshots.</i><br><br><b>timeshift list</b><br><i>Lists all available snapshots.</i><br><br><b>timeshift gui</b><br><i>Launches the graphical user interface.</i><br><br><b>timeshift --check</b><br><i>Performs a system check and setup.</i>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a system check and initial setup, including device and configuration checks.<br><br><b><b>--snapshot N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the index number <b>N</b> of the snapshot to perform an operation on (e.g., restore, delete). The index is shown by <b>timeshift list</b>.<br><br><b><b>--comments "text"</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a descriptive comment to the snapshot being created.<br><br><b><b>--tags tag</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns tags (e.g., <i>daily</i>, <i>hourly</i>, <i>weekly</i>, <i>monthly</i>, <i>boot</i>, <i>manual</i>) to the snapshot for better organization and automation.<br><br><b><b>--delete-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <b>delete</b> command to remove all existing snapshots.<br><br><b><b>-y</b>, <b>--yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assumes 'yes' to all prompts, allowing non-interactive operation.<br><br><b><b>--target /path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative target directory for restore operations, useful for offline restores.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an operation, bypassing some safety checks (use with caution).<br><br>


title: DESCRIPTION
content:
<i>Timeshift</i> is an essential system restore utility for Linux, providing a robust solution for protecting your operating system. <br>It functions by creating incremental snapshots of your file system, which can be used to restore your system to a previous working state in the event of software issues, failed updates, or accidental changes. <br>Two primary snapshot modes are supported: <br>1. <b>Rsync Mode</b>: This mode uses <i>rsync</i> and hard links to create snapshots, making it compatible with most Linux file systems. It effectively saves disk space by only storing new or modified files. <br>2. <b>Btrfs Mode</b>: For systems running on a <i>Btrfs</i> file system, this mode leverages native <i>Btrfs</i> features to create efficient snapshots. <br>By default, <i>Timeshift</i> focuses on system files and configurations (e.g., <b>/</b>, <b>/boot</b>, <b>/etc</b>), excluding user data (e.g., <b>/home</b>, <b>/root</b>) to keep snapshots lean and restoration processes quick. This design ensures that a system can be swiftly reverted to a stable condition without affecting personal files. Both a command-line interface and a graphical user interface are available, catering to different user preferences.


title: CAVEATS
content:
<b>Key Limitations and Considerations:</b><br>1. <b>User Data Exclusion:</b> By default, <i>Timeshift</i> <i>excludes</i> user home directories (e.g., <b>/home/username</b>). This is intentional to keep snapshots small and system restores fast. Users must manually configure inclusions if they wish to snapshot specific user data.<br>2. <b>Disk Space Consumption:</b> Snapshots can consume significant disk space, especially if frequent or large system changes occur. Regular review and deletion of older snapshots are recommended.<br>3. <b>Btrfs-specific Requirements:</b> <i>Btrfs</i> mode only works if your root (<b>/</b>) filesystem is formatted as <i>Btrfs</i>. <i>Rsync</i> mode is more universally compatible.<br>4. <b>Not a Full Backup Solution:</b> <i>Timeshift</i> is primarily a system restore utility, not a comprehensive backup solution for all your data. It does not protect against hardware failures or loss of your entire disk.<br>5. <b>Live Environment for Restore:</b> For a successful system restore, especially if the system is unbootable, it often requires booting into a live Linux environment (e.g., from a USB stick) to run <i>Timeshift</i>.


title: HOW SNAPSHOTS WORK
content:
<i>Timeshift</i> creates snapshots efficiently. In <b>Rsync mode</b>, it uses hard links for unchanged files between snapshots, meaning only new or modified files consume additional space. This makes incremental snapshots very space-efficient. In <b>Btrfs mode</b>, it leverages native <i>Btrfs</i> subvolume features, which are inherently copy-on-write, making snapshots virtually instant and highly efficient in terms of space.


title: RESTORE PROCESS OVERVIEW
content:
When you initiate a restore with <i>Timeshift</i>, it attempts to revert your system files and configurations to the state captured in the selected snapshot. If the system is currently running, <i>Timeshift</i> will often prompt for a reboot into a <i>chroot</i> environment or a live USB session to safely perform the file replacement, ensuring critical system files are not in use during the process. It handles updating the bootloader (<i>GRUB</i>) and generating <i>initramfs</i> images automatically to ensure the restored system is bootable.


title: CONFIGURATION AND AUTOMATION
content:
<i>Timeshift</i> allows users to configure automated snapshot schedules (e.g., hourly, daily, weekly) and retention policies (how many snapshots to keep). These settings can be managed via both the GUI and command-line. Users can also specify custom include/exclude filters to tailor what data is included or excluded from snapshots beyond the defaults.


title: HISTORY
content:
<i>Timeshift</i> was developed by <i>Tony George</i> and first released to the public around 2017. It quickly gained popularity among Linux users looking for a reliable and user-friendly system restore utility, akin to features found in Windows (System Restore) and macOS (Time Machine). Its design philosophy focused on simplicity and effectiveness for system rollbacks, distinguishing it from general-purpose backup tools. Its integration with popular distributions, notably <i>Linux Mint</i> and <i>Ubuntu</i>-based systems, further cemented its role as a standard tool for system stability and recovery.


title: PARAMETERS
content:
<b><b>-i</b>, <b>--input</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input <b>perf.data</b> file to analyze (default: <b>perf.data</b>).<br><br><b><b>--kallsyms</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a path to the <b>kallsyms</b> file for kernel symbol resolution.<br><br><b><b>--vmlinux</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <b>vmlinux</b> file for enhanced kernel symbol resolution and debugging information.<br><br><b><b>--objdump</b> <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <b>objdump</b> utility for disassembling binaries.<br><br><b><b>--no-browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the command from launching the graphical browser, often used in conjunction with <b>--stdio</b> for text-based output.<br><br><b><b>--full-path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the full path of object files in the trace.<br><br><b><b>--cpu-utilization</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a graph of overall CPU utilization over time.<br><br><b><b>--cpu-frequency</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a graph of CPU frequency changes over time.<br><br><b><b>--perf-clock-output</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays output related to the perf clock.<br><br><b><b>--event-graph</b> <i>event</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a graph for a specific event (e.g., <i>sched:sched_switch</i>).<br><br><b><b>--per-cpu-graph</b> <i>event</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays per-CPU graphs for a specified event type.<br><br><b><b>--hide-browser-stats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hides statistical information in the browser interface.<br><br><b><b>--stdio</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the timetrace information in text format to standard output instead of launching the GUI.<br><br><b><b>--output</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an output file name when <b>--stdio</b> is used, storing the text-based trace.<br><br>


title: DESCRIPTION
content:
<b>perf timetrace</b> is a subcommand of the Linux <b>perf</b> utility, designed for graphical visualization and analysis of performance trace data. It processes <b>perf.data</b> files, typically generated by <b>perf record</b>, to display a timeline of system events. This includes CPU activity, context switches, system calls, and function calls across various processes and threads. By presenting a time-ordered view, <b>perf timetrace</b> helps developers and system administrators identify performance bottlenecks, analyze execution flows, and understand system behavior over time. It often utilizes a Python-based graphical user interface to render the trace data, providing an interactive way to explore the captured events. It's an indispensable tool for in-depth performance debugging and optimization on Linux systems.


title: CAVEATS
content:
<b>perf timetrace</b> relies heavily on the <b>perf</b> utility and its underlying infrastructure.<br>It often requires Python with specific graphical libraries (like <i>Tkinter</i> or <i>GTK</i>) to launch its interactive browser interface.<br>For accurate symbol resolution, especially for kernel functions, proper <b>kallsyms</b> or <b>vmlinux</b> files are crucial.<br>Analyzing large <b>perf.data</b> files can be resource-intensive and generate extensive output.<br>Running <b>perf</b> commands typically requires elevated privileges (e.g., <b>sudo</b> or <b>CAP_PERFMON</b> capability).


title: USAGE EXAMPLE
content:
To use <b>perf timetrace</b>, you typically first record performance data using <b>perf record</b>. For instance, to record system-wide data for 5 seconds including callgraphs:<br><b>perf record -a -g sleep 5</b><br>After recording, you can visualize the data with:<br><b>perf timetrace</b><br>This will usually launch an interactive graphical browser displaying the events.


title: GRAPHICAL INTERFACE
content:
The <b>perf timetrace</b> browser presents events on a timeline, allowing users to zoom in/out, pan, and select specific regions or events. It often shows different event types (e.g., <i>sched_switch</i>, <i>syscalls</i>, <i>CPU samples</i>) on separate tracks, along with aggregated graphs for CPU utilization or frequency. Details of selected events, including call stacks, are typically shown in a separate pane.


title: PYTHON DEPENDENCY
content:
The graphical interface of <b>perf timetrace</b> is often implemented in Python. This means that for the interactive browser to function, your system needs to have Python installed along with specific libraries (like <i>python-perf</i> bindings and a GUI toolkit such as <i>Tkinter</i> or <i>GTK</i>). If these dependencies are not met, you might need to use the <b>--stdio</b> option for text-based output.


title: HISTORY
content:
The <b>perf</b> tool, which <b>timetrace</b> is a part of, was introduced into the Linux kernel in version 2.6.31, evolving from earlier profiling tools. The <b>timetrace</b> subcommand specifically emerged to address the need for a more intuitive, graphical representation of complex, time-ordered performance events captured by <b>perf record</b>. Its development has focused on enhancing visualization capabilities, often leveraging Python for its interactive browser interface. It represents a significant step towards making detailed performance analysis more accessible and understandable than purely text-based reports, continuously being refined within the Linux kernel development cycle.


title: SEE ALSO
content:
perf(1): The primary Linux <b>perf</b> utility suite., perf-record(1): Used to collect performance data that <b>perf timetrace</b> visualizes., perf-report(1): Generates textual reports and summary statistics from <b>perf.data</b> files., perf-script(1): Allows scripting and detailed analysis of <b>perf.data</b> for custom reports., ftrace(1): The underlying kernel tracing framework used by <b>perf</b>., strace(1): Traces system calls and signals for a process.


title: PARAMETERS
content:
<b><b>tt start</b> [<i>project_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Begins tracking time for a new entry. If <i>project_name</i> is specified, it assigns that project to the entry. If an entry is currently active, it will automatically stop the existing one before starting the new entry.<br><br><b><b>tt stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ceases time tracking for the currently active entry.<br><br><b><b>tt status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current time tracking status, including the ID of the active entry, its project, start time, and elapsed duration.<br><br><b><b>tt display</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a summary of time entries. By default, it shows entries for the current day or a recent period. This command offers numerous options to filter, sort, and format the output.<br><br><b><b>tt today</b> / <b>tt week</b> / <b>tt month</b> / <b>tt year</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convenience commands to display time entries specifically for the current day, week, month, or year, respectively.<br><br><b><b>tt total</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Calculates and displays the cumulative tracked time for all entries on the current sheet.<br><br><b><b>tt sum</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Presents the total time spent per project for the current sheet and the specified time period (e.g., current day, week).<br><br><b><b>tt sheet</b> [<i>sheet_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches to an existing time tracking sheet or creates a new one. If <i>sheet_name</i> is omitted, it lists all available sheets. Sheets help organize time tracking into distinct contexts (e.g., 'Work', 'Personal').<br><br><b><b>tt list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available time tracking sheets.<br><br><b><b>tt edit</b> [<i>ID</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a text editor (configured via the <b>$EDITOR</b> environment variable) to modify the details of a specific time entry identified by its <i>ID</i>. This allows adjusting start/end times, project names, or adding/editing notes.<br><br><b><b>tt delete</b> [<i>ID</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a time entry specified by its <i>ID</i> from the database.<br><br><b><b>tt punch</b> [<i>ID</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If an <i>ID</i> is provided, it stops the current entry (if any) and restarts the specified entry. If no <i>ID</i> is given, it restarts the most recently stopped entry.<br><br><b><b>-m</b> <i>&lt;message&gt;</i> (with <b>start</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a message or note to the time entry when it is started.<br><br><b><b>--at</b> <i>&lt;time&gt;</i> (with <b>start</b>/<b>stop</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom start or stop time for the entry, useful for backdating or correcting records. Time can be in various common formats (e.g., 'HH:MM', 'YYYY-MM-DD HH:MM').<br><br><b><b>-l</b> <i>&lt;limit&gt;</i> (with <b>display</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restricts the number of time entries shown in the display output.<br><br><b><b>-s</b> <i>&lt;start_date&gt;</i>, <b>-e</b> <i>&lt;end_date&gt;</i> (with <b>display</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters displayed entries to a specific date range, using various date formats.<br><br><b><b>--csv</b> (with <b>display</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the displayed time data in Comma Separated Values (CSV) format, suitable for spreadsheet applications.<br><br><b><b>--json</b> (with <b>display</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the displayed time data in JSON (JavaScript Object Notation) format, suitable for programmatic parsing.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed version information of the <i>timetrap</i> utility.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the general help message or detailed help for a specific command.<br><br>


title: DESCRIPTION
content:
<i>timetrap</i>, commonly invoked as <b>tt</b>, is a simple and flexible command-line utility designed for tracking time spent on various projects and tasks. It enables users to quickly punch in when starting a task, punch out when finishing, and generate comprehensive reports on their time spent. Its lightweight nature and command-line interface make it an ideal tool for developers, freelancers, or anyone who prefers managing their time efficiently without a bulky graphical application.<br><br>The tool stores data locally, typically in a SQLite database, providing users with full control over their timekeeping records. Key features include the ability to manage multiple 'sheets' for different contexts, add descriptive notes to entries, easily edit past records, and display time logs in various formats, such as human-readable tables, CSV, or JSON. <i>timetrap</i> focuses on simplicity and efficiency, allowing seamless integration of time tracking into one's daily workflow.


title: CAVEATS
content:
<i>timetrap</i> is exclusively a command-line tool, meaning it does not offer a graphical user interface. While efficient for CLI-savvy users, newcomers might experience a slight learning curve. Data is stored locally in a SQLite database, typically at <i>~/.timetrap.db</i>, which simplifies management but necessitates manual backup for cross-device synchronization or cloud storage. It relies on the system's timezone settings for accurate timekeeping. Although generally very fast, managing exceptionally large datasets over extended periods might eventually lead to minor performance considerations.


title: CONFIGURATION AND DATA STORAGE
content:
<i>timetrap</i> stores all its time entry data in a single SQLite database file, which defaults to <i>~/.timetrap.db</i> in the user's home directory. This makes the data highly portable and straightforward to back up. Users can override the default database location by setting the <b>TIMETRAP_DB</b> environment variable, allowing for custom database paths or the management of multiple distinct databases. Other configuration preferences, such as the default text editor for modifying entries (used by <b>tt edit</b>), are typically managed through standard shell environment variables like <b>$EDITOR</b> or by defining shell aliases, ensuring deep integration with a user's preferred shell environment.


title: EXTENSIBILITY AND REPORTING
content:
A significant strength of <i>timetrap</i> lies in its highly flexible reporting capabilities. Beyond the versatile built-in <b>display</b> command, which supports various output formats (including CSV and JSON), users can leverage external tools or custom scripts to process the raw data. Since the data resides in a standard SQLite database, it can be directly queried using SQL commands or parsed programmatically to generate highly specialized reports, integrate with invoicing systems, or feed into analytics dashboards. This extensibility makes <i>timetrap</i> a powerful backend for more complex and customized time management workflows.


title: HISTORY
content:
<i>timetrap</i> was initially created by Scott Chacon, a prominent figure in the Git community, driven by his personal need for a simple, non-intrusive method to track project time directly from the terminal. Its design adheres to the Unix philosophy of doing one thing well, focusing on robust time-tracking without unnecessary features. As a Ruby-based application, it quickly gained traction among developers due to its ease of installation via RubyGems and its inherent hackability. Over the years, the tool has been actively maintained and enhanced by the open-source community, incorporating new features like multiple sheets and improved reporting while steadfastly retaining its core simplicity and command-line focus.


title: PARAMETERS
content:
<b><b>start</b> <i>[tags...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Begins tracking time for a task, optionally with descriptive tags. For example, <i>timew start project:task meeting</i>.<br><br><b><b>stop</b> <i>[id|tags...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the currently active time tracking, or a specific entry using its ID or matching tags.<br><br><b><b>track</b> <i><duration></i> <i>[tags...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a past time entry of a specified duration (e.g., <i>15min</i>, <i>2h</i>), with optional tags.<br><br><b><b>summary</b> <i>[filters...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a summarized report of time entries based on specified filters (e.g., <i>:day</i>, <i>:week</i>, <i>project:alpha</i>).<br><br><b><b>gaps</b> <i>[filters...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identifies and displays periods of untracked time within a specified range or filters.<br><br><b><b>annotate</b> <i><id></i> <i>[tags...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds or modifies tags and descriptions for an existing time entry identified by its ID.<br><br><b><b>tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all unique tags used across your time entries, providing an overview of your activity categories.<br><br><b><b>export</b> <i>[filters...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports time data in a machine-readable format (e.g., JSON), useful for backups or integrations.<br><br><b><b>import</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports time data from a file, allowing for data migration or restoration.<br><br><b><b>undo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverts the last modification made to time entries, providing a safety net for errors.<br><br><b><b>config</b> <i>[name [value]]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Timewarrior configuration settings, allowing customization of behavior and output.<br><br><b><b>extensions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists available extensions and their status, enabling enhanced functionality.<br><br><b><b>help</b> <i>[command]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays comprehensive help information for Timewarrior or a specific subcommand.<br><br>


title: DESCRIPTION
content:
Timewarrior (<b>timew</b>) is a powerful, lightweight command-line utility for tracking time spent on tasks or projects. It allows users to record, annotate, and analyze time entries directly from the terminal.<br><br>Designed for efficiency and privacy, <b>timew</b> stores all data locally in plain text files, ensuring complete control over your information. It supports a wide range of features, including starting and stopping timers, logging past entries, adding tags, and generating detailed reports based on sophisticated query filters. Its extensibility through hooks and extensions makes it a versatile tool for personal and professional time management.


title: CAVEATS
content:
<b>Timewarrior</b> is primarily a command-line tool, which might present a learning curve for users unfamiliar with terminal interfaces or its specific query syntax. While its local data storage enhances privacy, it means there is no built-in cloud synchronization; users needing multi-device access must implement their own syncing solutions (e.g., using `git` or `rsync`).


title: DATA STORAGE AND PRIVACY
content:
All <b>timew</b> data is stored locally in plain-text files, typically located in <i>~/.timewarrior</i>. This design choice prioritizes user privacy and control, making data easy to backup, inspect, and manually edit if necessary.


title: EXTENSIBILITY THROUGH HOOKS
content:
<b>Timewarrior</b> supports a powerful hook system, allowing users to execute custom scripts (written in any language) before or after certain commands. This enables deep customization, integration with other tools, or automated actions based on time-tracking events.


title: HISTORY
content:
<b>Timewarrior</b> was developed by the same team behind Taskwarrior, a popular command-line task management tool. It emerged from a desire to provide a dedicated, robust, and accurate time-tracking solution that integrates well with Taskwarrior's philosophy. First publicly released around 2016, it has since grown into a stable and actively maintained project, focusing on precision, flexibility, and extensibility.


title: PARAMETERS
content:
<b>-A <level>, --amplification=<level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the amplification level for playback.<br><br><b>-o <filetype>, --output-file=<filetype></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the synthesized audio to a file (e.g., WAV) instead of playing it live. <I>filetype</I> can be 'wav', 'aiff', 'au', etc.<br><br><b>-s <freq>, --sampling-freq=<freq></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the sampling frequency for the output audio (e.g., 44100 for CD quality).<br><br><b>-B <bufsize>, --buffer-size=<bufsize></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the size of the output audio buffer in milliseconds. Larger buffers can reduce glitches but increase latency.<br><br><b>-i <interface>, --interface=<interface></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user interface or output driver to use (e.g., 'a' for ALSA, 'c' for curses, 'w' for WAV file output).<br><br><b>-p <port>, --port=<port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a specific ALSA sequencer port for real-time MIDI input.<br><br><b>-q <quality>, --resample=<quality></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the resampling quality. Higher values provide better sound but use more CPU.<br><br><b>-S <soundfont>, --soundfont=<soundfont></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an additional soundfont file to load. Can be used multiple times.<br><br><b>-U <volume>, --volume=<volume></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the master volume for playback (0-127).<br><br><b>-F <file>, --config-file=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<b>timidity</b> is a powerful and versatile software synthesizer that can play MIDI files without requiring a dedicated hardware MIDI device. It achieves this by synthesizing audio waveforms from digital instrument "patches" (soundfonts), which typically follow the Gravis UltraSound format. It can play MIDI files in real-time through various audio devices (like ALSA, OSS), or convert them into standard audio formats such as WAV, AIFF, or Au files, making it useful for creating audio tracks from MIDI compositions.<br><br>Beyond simple playback, <b>timidity</b> offers extensive customization options, allowing users to control aspects like amplification, sampling frequency, buffer size, and the quality of resampling. It's an indispensable tool for musicians, developers, and anyone needing robust MIDI playback or conversion capabilities on a Linux system, especially in environments where hardware MIDI synthesizers are unavailable or inconvenient.


title: CAVEATS
content:
Proper operation requires soundfont files to be installed and correctly configured in the <b>timidity</b> configuration file (e.g., <i>/etc/timidity/timidity.cfg</i>). Without soundfonts, <b>timidity</b> will not produce audible output.<br><br>Real-time playback performance can be demanding on system resources, especially with high sampling frequencies or complex MIDI files. The quality of synthesized audio is highly dependent on the quality of the loaded soundfonts.


title: CONFIGURATION FILES
content:
<b>timidity</b> typically uses a global configuration file, often located at <i>/etc/timidity/timidity.cfg</i> or <i>/etc/timidity.cfg</i>. This file specifies the default soundfonts, their locations, and other playback parameters. Users can override these settings using command-line options or by specifying a personal configuration file.


title: SOUNDFONTS
content:
<b>timidity</b> relies on soundfonts (e.g., <i>.sf2</i>, <i>.pat</i> files) which contain samples of musical instruments. The quality and variety of these soundfonts directly impact the realism and richness of the synthesized audio. Many high-quality soundfonts are available for download online and are essential for optimal <b>timidity</b> performance.


title: HISTORY
content:
<b>timidity</b> originated from an earlier program called <i>playmidi</i> by Tuomas J. Lukka in the early 1990s. It was later significantly rewritten and enhanced, becoming <b>timidity++</b>. It has been a cornerstone for MIDI playback on Unix-like systems, particularly Linux, providing a robust and flexible software-based alternative to hardware MIDI synthesizers. Its development has focused on improving audio quality, performance, and compatibility with various audio backends and MIDI standards.


title: DESCRIPTION
content:
The command <I>tkiptun-ng</I> does not appear to be a standard, commonly recognized, or publicly documented Linux utility. Extensive searches across official Linux documentation, common package repositories, and community resources yield no information pertaining to a command with this specific name. It is highly probable that <I>tkiptun-ng</I> is a typo, a custom-developed internal tool, or a non-existent command. As such, a detailed functional description, specific parameters, or usage examples cannot be provided. Users are advised to double-check the command name for any misspellings or to confirm its source if it's a custom application.


title: CAVEATS
content:
The analysis is based on the premise that <I>tkiptun-ng</I> is not a standard Linux command. Consequently, all sections like parameters, history, and related commands are unfillable with factual information. If this command is part of a specific custom environment or a particular software suite, its documentation should be consulted directly.


title: HISTORY
content:
No historical data or development information is available for an unrecognized command like <I>tkiptun-ng</I>.


title: SYNOPSIS
content:
<b>tldr</b> [<i>options</i>] <i>command</i><br><b>tldr</b> [<i>options</i>] <b>--list</b><br><b>tldr</b> [<i>options</i>] <b>--update</b><br><b>tldr</b> [<i>options</i>] <b>--version</b><br><b>tldr</b> [<i>options</i>] <b>--help</b>


title: PARAMETERS
content:
<b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available commands in the cache.<br><br><b>-u, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update the local cache of <i>tldr</i> pages from the remote repository.<br><br><b>-p <platform>, --platform <platform></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the platform (e.g., linux, osx, windows, common) for which to show pages.<br><br><b>-c <color>, --color <color></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the color theme for output.<br><br><b>-r <repository>, --repository <repository></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative repository URL for pages.<br><br><b>-s <language>, --language <language></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the language for pages (e.g., en, es, fr).<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version of the <i>tldr</i> client.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br>


title: DESCRIPTION
content:
The <i>tldr</i> command provides simplified, community-maintained examples of common command-line tools. Unlike traditional <i>man</i> pages, which can be exhaustive and intimidating, <i>tldr</i> focuses on practical, real-world use cases, offering a concise cheatsheet for quick reference.<br><br>It aims to distill the most frequent and useful invocations of a command into a few easy-to-understand examples, often showing how to perform common tasks without requiring users to sift through extensive documentation. The name itself is an acronym for "Too Long; Didn't Read", reflecting its purpose to provide immediate, actionable information.<br><br>Users can easily find examples for almost any common Linux command, making it an invaluable resource for both beginners and experienced users looking for a quick reminder or a new trick.


title: CAVEATS
content:
The <i>tldr</i> pages are community-maintained, meaning they are not official documentation and might occasionally contain inaccuracies or be incomplete for very niche use cases. They focus on common scenarios, so advanced or less frequent command options might not be covered. Additionally, the client typically requires an internet connection to update its local cache of pages.


title: CONTRIBUTION MODEL
content:
Users can contribute new pages or improve existing ones by submitting pull requests to the official <i>tldr</i> GitHub repository, fostering a collaborative and ever-growing knowledge base.


title: CLIENT IMPLEMENTATIONS
content:
While the core <i>tldr</i> pages are just markdown files, there are numerous client implementations available in various programming languages (Node.js, Python, Go, Rust, etc.), allowing users to interact with the pages using their preferred environment.


title: HISTORY
content:
The <i>tldr</i> project emerged from the internet culture's "Too Long; Didn't Read" acronym, reflecting a desire for concise information. It began as a collaborative open-source effort, primarily hosted on GitHub, to address the common frustration with the verbosity of traditional <i>man</i> pages. The goal was to provide quick, example-driven documentation that's immediately useful for practical command-line tasks, rapidly gaining popularity within the developer community since its inception around 2015.


title: PARAMETERS
content:
<b><B>-o</B> <I>&lt;DIR&gt;</I>, <B>--output</B> <I>&lt;DIR&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where the generated <I>tldr pages</I> cache will be saved.<br><br><b><B>-s</B> <I>&lt;URL&gt;</I>, <B>--source</B> <I>&lt;URL&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the URL of the <I>tldr-pages</I> repository (e.g., GitHub) to fetch command examples from.<br><br><b><B>-f</B> <I>&lt;TYPE&gt;</I>, <B>--format</B> <I>&lt;TYPE&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output format for the generated pages, such as <I>json</I> or <I>plain</I> text, depending on the client's needs.<br><br><b><B>-c</B>, <B>--clean</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes any existing local <I>tldr pages</I> cache before generating a new one.<br><br><b><B>-v</B>, <B>--verbose</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the generation process.<br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
The <B>tldr-generate</B> command, though often an internal function of <B>tldr</B> clients, serves the crucial purpose of creating or updating a local cache of <I>tldr pages</I>.<BR><BR>This local cache allows users to access concise command-line examples even without an internet connection and significantly speeds up page retrieval. The process typically involves fetching the latest community-contributed Markdown files from the <I>tldr-pages</I> GitHub repository, processing them into a client-readable format (such as plain text or JSON), and storing them in a designated directory on the user's system.<BR><BR>While a standalone <B>tldr-generate</B> might exist in specific client implementations or development setups, its functionality is most commonly invoked via an <B>update</B> or <B>sync</B> option within the main <B>tldr</B> command (e.g., <I>tldr --update</I> or <I>tldr sync</I>), ensuring users always have access to the most current and relevant command examples.


title: CAVEATS
content:
The <B>tldr-generate</B> command is often not a universally distributed standalone utility. Its functionality is typically integrated into popular <B>tldr</B> clients (like the Node.js or Python clients) as an <B>update</B> or <B>sync</B> feature (e.g., <I>tldr --update</I> or <I>tldr sync</I>).<BR><BR>The specific options and behavior of such a generation process can vary between different <B>tldr</B> client implementations or custom scripts. Users should consult the documentation of their specific <B>tldr</B> client for precise cache generation instructions.


title: <B>PURPOSE OF LOCAL CACHE</B>
content:
Generating a local cache of <I>tldr pages</I> is essential for enabling offline access to command examples and significantly speeding up the retrieval time. Instead of fetching pages from the internet every time, the client can serve them instantly from the local store.


title: <B>INTEGRATION WITH TLDR CLIENTS</B>
content:
For most users, the functionality of <B>tldr-generate</B> is accessed directly through their preferred <B>tldr</B> client. Commands like <I>tldr --update</I> (for the Node.js client) or <I>tldr update</I> (for the Python client) handle the entire process of fetching, parsing, and caching the latest <I>tldr pages</I> without requiring a separate <B>tldr-generate</B> command.


title: HISTORY
content:
The <I>tldr-pages</I> project was conceived around 2014-2015 as a more approachable alternative or complement to traditional <B>man</B> pages, focusing on practical command examples.<BR><BR>As the project gained popularity and the number of pages grew, the need for efficient local caching mechanisms became evident. This led to the development of integrated generation features within various <B>tldr</B> client implementations, allowing users to quickly synchronize and store the latest community-contributed content for offline access and improved performance. While early versions might have relied on simpler external scripts, the trend has been towards seamless, built-in update functionalities.


title: SYNOPSIS
content:
<b>tldr-lint</b> [<i>options</i>] [<i>files...</i>]<br><b>tldr-lint</b> [<i>options</i>] <i>&lt;path_to_page_or_directory&gt;</i>


title: PARAMETERS
content:
<b><i>files...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more <i><b>tldr</b></i> page files or directories to lint. If directories are specified, all <i><b>.md</b></i> files within them will be linted recursively.<br><br><b>-s, --spec <i>&lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Validate against a specific <i><b>tldr</b></i> specification version. Defaults to the latest supported version.<br><br><b>-o, --output-format <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for linting results (e.g., <i>text</i>, <i>json</i>). Default is <i>text</i>.<br><br><b>-p, --platform <i>&lt;platform&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the platform for which pages are being linted (e.g., <i>common</i>, <i>linux</i>, <i>osx</i>, <i>windows</i>). This helps in validating platform-specific rules.<br><br><b>-e, --exclude <i>&lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching the specified glob pattern from linting.<br><br><b>--color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force color output, even if stdout is not a TTY.<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable color output.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide more detailed output, including skipped files and additional linting information.<br><br><b>--error-on-warning</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with a non-zero status code if any warnings are found, treating warnings as errors.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <i><b>tldr-lint</b></i> version number.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<i><b>tldr-lint</b></i> is a command-line utility designed to validate and lint <i><b>tldr</b></i> pages. It ensures that contribution pages adhere to the official <i><b>tldr</b></i> contributing guidelines and specifications. This tool is crucial for maintaining the quality, consistency, and uniformity of the community-driven <i><b>tldr</b></i> documentation project. It performs various checks, including Markdown syntax validation, proper use of command examples, correct section headers, and adherence to specific formatting rules. By catching errors and inconsistencies early in the development process, <i><b>tldr-lint</b></i> helps contributors submit high-quality pages that are easily readable and useful to end-users across different platforms.


title: CAVEATS
content:
<i><b>tldr-lint</b></i> typically requires <i><b>Node.js</b></i> and <i><b>npm</b></i> to be installed for its installation and execution, as it's often distributed as an <i><b>npm</b></i> package. The linting rules are based on the current <i><b>tldr</b></i> project's contributing guidelines, which may evolve over time. It performs static analysis and does not execute the commands described in the pages.


title: INSTALLATION
content:
<i><b>tldr-lint</b></i> is commonly installed via <i><b>npm</b></i> (Node Package Manager). You can install it globally using: <br><code>npm install -g tldr-lint</code>


title: EXIT STATUS
content:
<i><b>tldr-lint</b></i> exits with a status of <i>0</i> if all linting checks pass without errors. It exits with a non-zero status (e.g., <i>1</i>) if any errors are found, or if <i>--error-on-warning</i> is used and warnings are present.


title: HISTORY
content:
<i><b>tldr-lint</b></i> emerged as an essential tool within the <i><b>tldr</b></i> project, a collaborative, community-driven effort to create simplified and community-maintained man pages. As the project grew, maintaining consistency and quality across thousands of contributed pages became crucial. <i><b>tldr-lint</b></i> was developed to automate the enforcement of the project's strict contributing guidelines, ensuring all new and updated pages meet the required Markdown syntax, formatting, and content standards. It significantly streamlined the review process for contributions and empowered contributors to self-validate their work, fostering a higher standard of documentation within the <i><b>tldr</b></i> ecosystem.


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


title: PARAMETERS
content:
<b><i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the command for which to retrieve simplified examples (e.g., <b>ls</b>, <b>grep</b>, <b>tar</b>).<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available <b>tldr</b> pages in the local cache.<br><br><b><b>-r</b>, <b>--random</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a random <b>tldr</b> page, useful for discovering new commands or learning.<br><br><b><b>-p</b> <i>&lt;platform&gt;</i>, <b>--platform</b> <i>&lt;platform&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the operating system platform for which to display the page (e.g., <i>linux</i>, <i>osx</i>, <i>windows</i>, <i>android</i>, <i>sunos</i>). By default, it detects the current platform.<br><br><b><b>-s</b> <i>&lt;query&gt;</i>, <b>--search</b> <i>&lt;query&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for <b>tldr</b> pages containing the specified keyword(s) in their names or descriptions.<br><br><b><b>-u</b>, <b>--update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the local cache of <b>tldr</b> pages by downloading the latest versions from the repository.<br><br><b><b>-c</b>, <b>--clear-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears the locally stored <b>tldr</b> pages cache, forcing a fresh download on the next query.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the installed <b>tldr</b> client.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message and available options for the <b>tldr</b> client.<br><br>


title: DESCRIPTION
content:
<b>tldr</b> (Too Long; Didn't Read) is a community-driven collection of simplified and practical examples for common Linux, macOS, and Windows command-line utilities. <br><br> It serves as a quick-reference alternative to traditional <b>man</b> pages, which can often be exhaustive and overwhelming for users just looking for basic syntax or common use cases. Instead of providing every possible option and detail, <b>tldr</b> focuses on showing practical, real-world examples of how commands are used, making it much faster to grasp essential functionality. <br><br> The project is maintained by a global community of contributors, ensuring that the content is current, relevant, and covers a wide array of commands and platforms. This collaborative nature makes <b>tldr</b> a highly valuable resource for developers and system administrators seeking concise, actionable command-line guidance.


title: CAVEATS
content:
<b>tldr</b> pages are community-contributed and focus on common use cases, so they may not cover every obscure option or edge case. For exhaustive documentation, the traditional <b>man</b> pages are still the definitive source. An internet connection is required for initial setup and updates of the page cache.


title: COMMUNITY DRIVEN
content:
The content of <b>tldr</b> pages is entirely community-contributed and maintained. This collaborative model ensures that the pages are practical, up-to-date, and cover a wide range of real-world scenarios and commands across various operating systems.


title: INSTALLATION
content:
<b>tldr</b> clients are available in various programming languages (e.g., Node.js, Python, Rust, Go) and can typically be installed via platform-specific package managers (e.g., <b>apt install tldr</b> on Debian/Ubuntu, <b>brew install tldr</b> on macOS) or language-specific package managers (e.g., <b>npm install -g tldr</b>, <b>pip install tldr</b>).


title: HISTORY
content:
The <b>tldr</b> project was initiated by Romain Coeur in 2017 with the goal of creating a more accessible and example-driven complement to standard manual pages. Its simple, practical approach quickly resonated with developers and system administrators. Since its inception, a diverse community has grown around it, contributing new pages and maintaining existing ones, solidifying its role as a go-to resource for quick command-line assistance.


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of <i>tlmgr</i>.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate the execution of a command without making any actual changes to the system. Useful for previewing updates or installations.<br><br><b>--repository <URL|PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative repository URL or local path to fetch packages from, instead of the default online CTAN mirrors.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most of the output messages during command execution.<br><br><b>--no-execute-actions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent <i>tlmgr</i> from executing auxiliary programs (like <i>updmap-sys</i> or <i>fmtutil-sys</i>) automatically after installs or updates. Useful for manual control.<br><br><b>update [options]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update installed packages or the entire TeX Live distribution. Common options include <b>--all</b> to update everything, and <b>--self</b> to update <i>tlmgr</i> itself.<br><br><b>install <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install one or more new packages from the configured repositories. E.g., <b>tlmgr install pgf</b>.<br><br><b>remove <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove one or more installed packages from the TeX Live system. This also handles dependencies if specified.<br><br><b>search [--file] [--global] <what></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for packages. Can search by package name, description, or files contained within packages (with <b>--file</b>). E.g., <b>tlmgr search --file hyperref.sty</b>.<br><br><b>info <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed information about specified packages, including description, dependencies, and installed files.<br><br><b>option <key> [value]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Get or set configuration options for <i>tlmgr</i>, such as default paper size or package download methods.<br><br><b>repository [add|remove|list|set]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage TeX Live package repositories. Allows adding custom local or remote repositories, listing existing ones, or setting the current primary repository.<br><br><b>gui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launch the graphical user interface for <i>tlmgr</i>, providing an interactive way to manage packages.<br><br><b>path [add|remove|set]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage the system's PATH environment variable to ensure TeX Live binaries are accessible. Typically handled during installation.<br><br><b>shell</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter an interactive <i>tlmgr</i> shell, where multiple commands can be executed without repeatedly typing <i>tlmgr</i>.<br><br><b>help [subcommand]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display general help information for <i>tlmgr</i> or detailed help for a specific <i>subcommand</i>.<br><br>


title: DESCRIPTION
content:
<i>tlmgr</i> (TeX Live Manager) is the essential command-line utility for managing a TeX Live installation, the most widely used TeX distribution. It provides comprehensive functionalities for maintaining the TeX system, including installing new packages, updating existing ones to their latest versions, and removing unnecessary components. Users can also leverage <i>tlmgr</i> to search for specific packages or files, inspect package information, and manage the repositories from which packages are downloaded. By connecting to official TeX Live online repositories (CTAN mirrors), <i>tlmgr</i> ensures that your TeX environment remains current, stable, and customized to your specific needs, streamlining the otherwise complex task of TeX system administration.


title: CAVEATS
content:
<b>Caveats and Limitations:</b><br><i>tlmgr</i> typically requires internet access for online updates and installations from CTAN mirrors.<br>Administrative/root privileges are often needed for system-wide TeX Live installations and updates.<br>A full <i>tlmgr update --all</i> can be time-consuming and download a significant amount of data.<br>Always consider backing up critical files or configuration before major updates.


title: COMMON USAGE EXAMPLES
content:
<b>To update all installed packages:</b> <i>tlmgr update --all</i><br><b>To install a new package, e.g., tikz:</b> <i>tlmgr install pgf</i> (<i>tikz</i> is part of <i>pgf</i>)<br><b>To find which package provides a specific file, e.g., amsmath.sty:</b> <i>tlmgr search --file amsmath.sty</i><br><b>To list all available packages:</b> <i>tlmgr list --only-installed</i> or <i>tlmgr list --all</i>


title: OFFLINE INSTALLATIONS
content:
While primarily used for online management, <i>tlmgr</i> can also manage installations from local TeX Live ISO images (e.g., DVD installations) or custom local repositories, enabling offline updates and installations after the initial setup.


title: HISTORY
content:
<i>tlmgr</i> was developed as the comprehensive package manager for TeX Live, which emerged as the successor to other TeX distributions like teTeX. Its goal was to provide a robust, cross-platform solution for managing the increasingly large and complex TeX Live collection. It unified package management, which was previously handled by more fragmented tools or manual processes, making TeX Live easier to install, update, and maintain across different operating systems.


title: PARAMETERS
content:
<b><i>install &lt;package&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a TeX Live package or collection not managed by <i>pacman</i>. E.g., <i>tlmgr-arch install a0poster</i>.<br><br><b><i>update [--all|--self|--force]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates TeX Live packages. Use <i>--all</i> to update all packages, <i>--self</i> to update <i>tlmgr</i> itself, or <i>--force</i> to force updates. This applies to <i>tlmgr</i>-managed components, not <i>pacman</i>-managed ones.<br><br><b><i>remove &lt;package&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a TeX Live package previously installed via <i>tlmgr-arch</i>. E.g., <i>tlmgr-arch remove a0poster</i>.<br><br><b><i>gui</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the graphical user interface for <i>tlmgr</i>, providing an interactive way to manage TeX Live packages.<br><br><b><i>search --file &lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for files within the TeX Live installation. E.g., <i>tlmgr-arch search --file article.cls</i>.<br><br><b><i>show &lt;package&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specified TeX Live package.<br><br><b><i>option [key] [value]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages <i>tlmgr</i>'s configuration options. E.g., <i>tlmgr-arch option repository ctan</i>.<br><br><b><i>path add</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds TeX Live paths to the system's PATH environment variable (usually handled by Arch's TeX Live package).<br><br><b><i>repository add|remove|list</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages TeX Live package repositories.<br><br><b><i>version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for <i>tlmgr</i>.<br><br><b><i>help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message for <i>tlmgr</i>, including available subcommands and options.<br><br>


