# CommandSection

title: CAVEATS
content:
<b>ntpd</b> typically requires root privileges to bind to privileged ports (UDP 123) and to adjust the system clock.<br>While robust, configuring <b>ntpd</b> for optimal performance and security can be complex, especially with access restrictions.<br>On modern Linux systems, <b>chronyd</b> (from the <i>chrony</i> project) is often recommended as an alternative to <b>ntpd</b> due to its faster synchronization times, better performance on intermittently connected systems, and lower resource consumption.


title: CONFIGURATION FILE (<I>/ETC/NTP.CONF</I>)
content:
The primary configuration for <b>ntpd</b> is read from <i>/etc/ntp.conf</i> (or a path specified by <b>-c</b>). This file defines NTP servers to query, access restrictions, logging options, and other operational parameters. Key directives include <b>server</b> (to specify upstream time sources), <b>restrict</b> (for access control), <b>driftfile</b> (to store clock frequency offset), and <b>logfile</b> (for logging daemon activity).


title: DRIFT FILE
content:
The drift file (typically <i>/var/lib/ntp/ntp.drift</i> or <i>/var/lib/ntp/drift/ntp.drift</i>) is used by <b>ntpd</b> to store the estimated frequency offset of the local system clock. This allows the daemon to quickly correct for clock drift even when not synchronized with an NTP server, reducing initial synchronization time and improving accuracy.


title: SECURITY CONSIDERATIONS
content:
NTP services can be exploited in denial-of-service (DoS) attacks, particularly amplification attacks. It is crucial to properly configure <b>restrict</b> directives in <i>ntp.conf</i> to limit access to your NTP server, preventing unauthorized queries and abuse. Public NTP servers should follow best practices for security hardening.


title: HISTORY
content:
The Network Time Protocol (NTP) and its reference implementation, <b>ntpd</b>, were developed by David L. Mills at the University of Delaware, beginning in the early 1980s. NTP has evolved through several versions (NTPv1, v2, v3, and the current NTPv4), becoming a cornerstone of internet infrastructure for precise timekeeping. <b>ntpd</b> has been the standard daemon for NTP synchronization on Unix-like systems for decades, providing a robust and highly accurate method for maintaining system clocks. Its long history underscores its fundamental role in ensuring consistent time across distributed systems and the global internet.


title: SYNOPSIS
content:
<b>ntpdate</b> [<i>-bBdqsvu</i>] [<i>-a keyid</i>] [<i>-e authdelay</i>] [<i>-k keyfile</i>] [<i>-p samples</i>] [<i>-P localport</i>] [<i>-t timeout</i>] <i>server</i> [...]


title: PARAMETERS
content:
<b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Force a time step.</b> Even if the offset is small, force a large time adjustment immediately rather than slewing.<br><br><b>-B</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Force a time slew.</b> Even if the offset is large, force a gradual adjustment (slewing) over time. This option can cause the system clock to be temporarily incorrect.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Debug mode.</b> Prints detailed debugging information to standard output, but does not modify the system clock.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Query only.</b> Queries the NTP servers and prints the offset, but does not modify the system clock.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Log to syslog.</b> Sends all output, including prompts and errors, to the syslog facility instead of standard output/error.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Unprivileged port.</b> Sends outgoing NTP packets from an unprivileged port. Useful when firewalls block privileged ports.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Verbose output.</b> Prints more detailed information about the time synchronization process.<br><br><b>-a <i>keyid</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Authentication key.</b> Specifies the key identifier to use for NTP authentication. Requires the <i>-k</i> option.<br><br><b>-e <i>authdelay</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Authentication delay.</b> Specifies the processing delay added to the roundtrip delay for authentication.<br><br><b>-k <i>keyfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Key file.</b> Specifies the path to the NTP authentication key file.<br><br><b>-p <i>samples</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Number of samples.</b> Specifies the number of samples to be acquired from each server. Defaults to 4.<br><br><b>-P <i>localport</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Local port.</b> Specifies the UDP port number for outgoing NTP packets. Defaults to an ephemeral port.<br><br><b>-t <i>timeout</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Timeout.</b> Specifies the maximum time to wait for a response from an NTP server. Defaults to 1 second.<br><br><b><i>server</i> [...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>NTP Server(s).</b> One or more hostnames or IP addresses of NTP servers to query.<br><br>


title: DESCRIPTION
content:
The <i>ntpdate</i> command is a legacy utility designed to set the local system's date and time by querying one or more Network Time Protocol (NTP) servers. Unlike continuous NTP daemons like <i>ntpd</i> or <i>chronyd</i>, <i>ntpdate</i> performs a one-shot synchronization. It queries the specified NTP servers, calculates the time offset between the local clock and the server's clock, and then adjusts the system time. If the offset is large, it will 'step' the clock (i.e., immediately jump the time). If the offset is small, it might 'slew' the clock (gradually adjust it). However, <i>ntpdate</i> is now largely <b>deprecated</b>.<br>Abrupt clock jumps can cause various issues, including corrupted log entries, transactional database problems, and issues with distributed applications. Modern best practice recommends using NTP daemons, which can smoothly adjust the clock and handle large offsets safely at boot (e.g., via <i>ntpd -gq</i> or <i>chronyc -s</i>), or in scenarios where a full daemon is not feasible, like some container environments for initial sync.


title: CAVEATS
content:
The <i>ntpdate</i> command is now largely considered <b>deprecated</b>. Modern Linux distributions and best practices recommend using a continuous NTP daemon like <i>ntpd</i> or <i>chronyd</i>. Abrupt time changes caused by <i>ntpdate</i> can lead to several issues, including: <br><i>log file inconsistencies</i> (entries appearing out of chronological order), <br><i>data corruption</i> in transactional systems (databases, distributed file systems) where time synchronization is critical, and <br>problems with applications sensitive to time jumps. <br>For initial synchronization at boot, it is strongly advised to use the `<i>-gq</i>` option with <i>ntpd</i> (e.g., `ntpd -gq`) or `<i>chronyc -s</i>` which are designed to handle large time offsets gracefully and then transition to continuous synchronization.


title: IMPACT OF TIME JUMPS
content:
When <i>ntpdate</i> performs a 'step' adjustment (a large, immediate jump in time), it can disrupt various system processes and applications. This includes: <br><i>File system timestamps</i>: Files created or modified during a backwards jump in time might appear to be from the future. <br><i>Log file integrity</i>: Log entries might appear out of chronological order, making debugging difficult. <br><i>Transaction processing</i>: Databases and other transactional systems rely on consistent time, and abrupt jumps can lead to data integrity issues or deadlocks. <br><i>Security mechanisms</i>: Time-sensitive authentication protocols (e.g., Kerberos, some SSL/TLS certificates) can fail if the clock is abruptly reset.


title: ALTERNATIVES FOR INITIAL SYNC
content:
For a one-time synchronization that handles large offsets gracefully, consider these alternatives: <br><i>ntpd</i>: Use `<b>ntpd -gq</b>` to step the clock once if the offset is large enough, then exit. This is generally safer than <i>ntpdate</i>. <br><i>chronyc</i>: Use `<b>chronyc -s</b>` to perform a one-shot synchronization. <i>chronyc</i> is known for its quick synchronization and robust behavior.


title: HISTORY
content:
<i>ntpdate</i> originated as part of the official NTP reference implementation, serving as a simple client to synchronize the system clock with a remote NTP server in a non-continuous fashion. Its primary role was for initial clock setup, particularly on systems where the clock was significantly off or after a reboot. Over time, as NTP daemon implementations like <i>ntpd</i> matured, they gained the ability to handle large initial offsets gracefully (e.g., via the `-gq` option, which steps the clock if needed and then exits). <br>The development of <i>chrony</i> (with `chronyc -s`) also provided a more robust and faster alternative for one-shot synchronization. Due to the potential for negative system impact from abrupt clock changes, <i>ntpdate</i>'s use has been actively discouraged by the NTP project and various Linux distributions, leading to its removal or deprecation in many modern OS versions.


title: DESCRIPTION
content:
<b>ntpdate-debian</b> is a wrapper script primarily found on Debian-based Linux distributions, designed to perform a one-shot synchronization of the system clock with Network Time Protocol (NTP) servers. It essentially automates the use of the <b>ntpdate</b> command, reading its configuration from files such as <i><b>/etc/default/ntpdate</b></i> or <i><b>/etc/ntp.conf</b></i> to determine which NTP servers to query.<br><br>Unlike continuous NTP daemons like <b>ntpd</b> or <b>chronyd</b>, <b>ntpdate-debian</b> performs a single, immediate adjustment to the system time. Its main use cases include setting the system clock accurately during boot-up, especially when the hardware clock is significantly off, or on systems that do not run a persistent NTP service.


title: CAVEATS
content:
<b>ntpdate</b> (and by extension <b>ntpdate-debian</b>) is considered largely deprecated for routine, continuous time synchronization in favor of more robust NTP daemons like <b>ntpd</b> or <b>chronyd</b>, which "slew" (gradually adjust) the time rather than "step" (jump) it. Stepping the clock can cause issues for applications sensitive to time continuity.<br><br>It requires root privileges to modify the system clock. Its primary role has shifted to initial synchronization at boot or when the clock is severely out of sync.


title: CONFIGURATION
content:
The behavior of <i>ntpdate-debian</i> is primarily controlled by settings in the file <i><b>/etc/default/ntpdate</b></i>. This file can specify the NTP servers to use (via the <i>NTPDATE_NTP_SERVERS</i> variable) or instruct the script to read server lists from <i><b>/etc/ntp.conf</b></i> (by setting <i>NTPDATE_USE_NTP_CONF=yes</i>). When executed, it consults these settings to determine which NTP servers to query for time synchronization.


title: UNDERLYING OPERATION
content:
<i>ntpdate-debian</i> itself is a shell script that executes the <b>ntpdate</b> command. It often passes arguments like <b>-s</b> (silent mode, logging to syslog) to <b>ntpdate</b> implicitly. While the script itself doesn't expose many command-line options, the underlying <b>ntpdate</b> command has various options for debugging, specifying ports, or forcing adjustments, which are typically configured within the system rather than passed directly to <i>ntpdate-debian</i> by a user.


title: HISTORY
content:
The <b>ntpdate-debian</b> script was developed as a Debian-specific wrapper around the standard <b>ntpdate</b> utility. Its creation aimed to integrate one-shot NTP synchronization smoothly into the Debian boot process and system administration practices, particularly by leveraging common configuration files like <i><b>/etc/default/ntpdate</b></i>. While <b>ntpdate</b> has been a long-standing tool for immediate time adjustments, <b>ntpdate-debian</b> streamlined its usage within the Debian ecosystem.<br><br>Over time, as continuous NTP daemons became the preferred method for accurate timekeeping, the role of <b>ntpdate-debian</b> has largely shifted to an initial synchronization step rather than a regular time-sync mechanism.


title: PARAMETERS
content:
<b><b>-c <i>command</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>command</i> on the remote host or local daemon. This allows running a single query without entering interactive mode.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays host addresses numerically rather than attempting to look up their symbolic hostnames, which can speed up queries and avoid DNS issues.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of configured peers and their synchronization status, including stratum, poll interval, reachability, and offset. This is one of the most frequently used options.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of local NTP associations, useful for understanding how <b>ntpd</b> is interacting with local reference clocks.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <b>ntpq</b> into interactive mode, providing a prompt to enter commands. This is the default behavior if no command or host is specified on the command line.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the debugging output level, providing more verbose information that can be helpful for troubleshooting complex issues.<br><br><b><b>-r <i>refid</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the reference ID to use for local clock reference, primarily for testing purposes or specific configuration scenarios.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a summary of the association list, offering a concise overview of peer status without the full detail of the <b>-p</b> option.<br><br>


title: DESCRIPTION
content:
<b>ntpq</b> is a standard command-line utility used for monitoring and querying the <b>ntpd</b> (Network Time Protocol daemon) or other remote NTP servers. It allows administrators to inspect the current state of NTP synchronization, including details about configured peers, their reachability, stratum, and synchronization status. <b>ntpq</b> can operate in an interactive mode, providing a prompt for issuing commands, or in a batch mode by supplying commands directly on the command line. It's an essential tool for diagnosing NTP issues, verifying time synchronization, and understanding the network's timekeeping performance, ensuring the accuracy and reliability of system clocks across a network. It's often used to check which server is currently being used for synchronization, analyze jitter and offset, and gather statistics about time sources.


title: CAVEATS
content:
Using <b>ntpq</b> effectively requires an NTP daemon (like <b>ntpd</b>) to be running and accessible, either locally or on a remote host. Communication typically occurs over UDP port 123, so firewall rules must permit this traffic. Interpreting <b>ntpq</b> output, particularly the metrics related to offset, jitter, and reachability, requires a basic understanding of NTP concepts. Querying remote NTP servers might expose details about their configuration or network topology, and access might be restricted by the server's NTP access control settings.


title: COMMON INTERACTIVE COMMANDS
content:
When run in interactive mode (e.g., <b><code>ntpq -i</code></b> or just <b><code>ntpq</code></b> without arguments), <b>ntpq</b> provides a prompt where users can issue several commands to query the NTP daemon.<br><br>Examples include:<br><b><code>peers</code></b>: Displays a list of all configured NTP peer associations and their status.<br><b><code>as</code></b>: Shows all associations, including local clock references.<br><b><code>rv <i>&lt;associd&gt;</i> [<i>variable</i>]</code></b>: Reads specific variables (e.g., system variables, peer variables) from a given association ID.<br><b><code>lopeers</code></b>: Lists local peer associations, typically used for reference clocks.<br><b><code>quit</code></b>: Exits the <b>ntpq</b> interactive session.<br><b><code>host <i>&lt;hostname&gt;</i></code></b>: Connects to a different NTP host or daemon.


title: UNDERSTANDING PEER OUTPUT (<CODE>-P</CODE> OPTION)
content:
The output of the <b><code>-p</code></b> (peers) option is crucial for diagnosing NTP synchronization. Each column provides specific information:<br><b><code>remote</code></b>: The hostname or IP address of the peer.<br><b><code>refid</code></b>: The source of the peer's time, often an IP or a special ID for reference clocks (e.g., GPS, PPS).<br><b><code>st</code></b>: Stratum of the peer, indicating its distance from a reference clock. Lower stratum means closer to the source.<br><b><code>t</code></b>: Type of association (e.g., 'u' for unicast, 'l' for local, 'b' for broadcast).<br><b><code>when</code></b>: The time, in seconds, since the last packet was received from the peer.<br><b><code>poll</code></b>: The polling interval, in seconds, at which queries are sent to the peer.<br><b><code>reach</code></b>: An octal bitmask indicating the reachability of the peer over the last eight polls. A value of 377 indicates full reachability.<br><b><code>delay</code></b>: The round-trip delay to the peer, in milliseconds.<br><b><code>offset</code></b>: The estimated time offset between the local system and the peer, in milliseconds. This is the value <b>ntpd</b> tries to minimize.<br><b><code>jitter</code></b>: A measure of the statistical dispersion of the offset values. Lower jitter indicates more stable time synchronization.


title: HISTORY
content:
<b>ntpq</b> is an integral part of the NTP suite, which was originally developed by Dr. David L. Mills at the University of Delaware in the 1980s. As NTP evolved through various versions (NTPv1, NTPv2, NTPv3, NTPv4), <b>ntpq</b> has consistently served as the primary diagnostic and monitoring tool for the <b>ntpd</b> daemon. Its design reflects the long-standing need for detailed operational insight into time synchronization networks, adapting to new features and protocol extensions over decades of development.


title: SYNOPSIS
content:
<b>nu</b> [<i>options</i>] [<i>script_file</i>] [<i>args...</i>]<br><b>nu</b> -c <i><commands_string></i>


title: PARAMETERS
content:
<b><b>-c</b>, <b>--commands</b> <i><commands></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes commands provided as a string argument, then exits.<br><br><b><b>-e</b>, <b>--execute</b> <i><commands></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>--commands</b>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays comprehensive help information for the <b>nu</b> command and its options.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed Nushell version number.<br><br><b><b>-l</b>, <b>--login</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Nushell as a login shell, loading login-specific configurations.<br><br><b><b>-n</b>, <b>--no-config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents Nushell from loading any default configuration files on startup.<br><br><b><b>--env-file</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads environment variables from the specified file path.<br><br><b><b>--config-file</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads configuration settings from the specified file path.<br><br><b><b>--testbin</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used internally for Nushell testing and development purposes; not for general use.<br><br>


title: DESCRIPTION
content:
Nushell, often invoked as <b>nu</b>, is a modern, cross-platform shell designed to work natively with <i>structured data</i>. Unlike traditional Unix shells that primarily operate on streams of text, Nushell processes data in formats like tables, enabling powerful data manipulation directly within its pipelines. This approach allows users to easily query, filter, and transform data from various sources (e.g., JSON, CSV, YAML, databases) without relying on external parsing tools. It features a rich type system, a comprehensive set of built-in commands, and a user-friendly syntax. Nushell aims to provide a more intuitive and powerful environment for developers and system administrators, offering consistent data structures across its commands and simplifying complex data workflows. Its focus on readability and robust error handling makes it a compelling alternative to traditional shells.


title: CAVEATS
content:
<b>nu</b> (Nushell) is not a standard utility pre-installed on most Linux distributions; it requires explicit installation. Its command philosophy and syntax differ significantly from traditional POSIX shells like Bash or Zsh, necessitating a learning curve for new users. Users should also be aware that its ecosystem of external tools and integrations, while growing, may not yet be as extensive as older, more established shells.


title: STRUCTURED DATA PIPELINES
content:
The core distinction of Nushell is its ability to treat all data—from files, external commands, or built-in functions—as structured data (e.g., tables, records) rather than raw text. This enables powerful, intuitive manipulation with commands resembling database queries, facilitating direct work with JSON, CSV, YAML, and other formats within the shell.


title: CROSS-PLATFORM COMPATIBILITY
content:
Nushell is engineered to function seamlessly across multiple operating systems, including Linux, macOS, and Windows. This cross-platform design guarantees a consistent shell experience and script portability for developers operating in diverse environments, offering a notable advantage over certain platform-specific shell features.


title: HISTORY
content:
Nushell began development in 2019, conceived by the desire for a modern shell capable of natively handling <i>structured data</i>, thereby addressing limitations of text-based pipelines in traditional Unix shells. Written in <i>Rust</i>, it has rapidly gained traction within the developer community due to its innovative approach, active development, and strong cross-platform compatibility. Its ongoing evolution prioritizes refining data-oriented features, enhancing performance, and expanding its ecosystem of built-in commands and external tool integrations.


title: SYNOPSIS
content:
<b>nuclei</b> [<i>options</i>] [<i>-u</i> | <i>-l</i>] <i>target(s)</i> [<i>-t</i>] <i>template(s)</i><br><br>Common usage examples:<br><b>nuclei</b> <i>-u</i> <i>https://example.com</i> <i>-t</i> <i>cves/2023/</i><br><b>nuclei</b> <i>-l</i> <i>targets.txt</i> <i>-t</i> <i>http/technologies/</i> <i>-json</i> <i>-o</i> <i>results.json</i><br><b>nuclei</b> <i>-update-templates</i><br><b>nuclei</b> <i>-version</i>


title: PARAMETERS
content:
<b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help message for <b>nuclei</b>.<br><br><b><i>-u</i>, <i>--target</i> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Target URL or IP address to scan. Can be repeated for multiple targets.<br><br><b><i>-l</i>, <i>--list</i> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of target URLs/IPs (one per line).<br><br><b><i>-t</i>, <i>--templates</i> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path(s) to <b>nuclei</b> template files or directories. Can be a comma-separated list.<br><br><b><i>-update-templates</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the installed <b>nuclei</b> templates to the latest version from the <i>ProjectDiscovery</i> repository.<br><br><b><i>-tags</i> <i>&lt;tag1,tag2,...&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs templates that match the specified tags (e.g., <i>cve,exposed</i>).<br><br><b><i>-exclude-tags</i> <i>&lt;tag1,tag2,...&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes templates that match the specified tags from the scan.<br><br><b><i>-severity</i> <i>&lt;info,low,medium,high,critical&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters templates by their severity levels. Can be a comma-separated list.<br><br><b><i>-json</i>, <i>-jsonl</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON or JSONL (line-by-line JSON) format.<br><br><b><i>-o</i>, <i>--output</i> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;File to write scan results to. If not specified, results are printed to stdout.<br><br><b><i>-rl</i>, <i>--rate-limit</i> <i>&lt;rate&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum requests per second to send (default: 150).<br><br><b><i>-c</i>, <i>--concurrency</i> <i>&lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum number of concurrent hosts to scan (default: 10).<br><br><b><i>-proxy</i> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;HTTP/Socks proxy to use for all requests (e.g., <i>http://127.0.0.1:8080</i>).<br><br><b><i>-silent</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational and banner messages, only showing results.<br><br><b><i>-version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of <b>nuclei</b>.<br><br>


title: DESCRIPTION
content:
<b>nuclei</b> is an open-source, fast, and customizable vulnerability scanner developed by <i>ProjectDiscovery</i>. It is widely used by security researchers, penetration testers, and bug bounty hunters for rapidly identifying security vulnerabilities, misconfigurations, and exposed assets across a multitude of targets.<br><br>Unlike traditional scanners, <b>nuclei</b> operates by executing specialized, YAML-based "templates" against specified targets. These templates define various security checks, ranging from identifying known CVEs and insecure configurations to detecting specific technologies and sensitive information disclosure. The extensive and constantly growing community-driven template library allows users to perform a wide array of checks efficiently.<br><br>Its strength lies in its flexibility, allowing users to write custom templates for specific needs, and its speed, enabling large-scale scanning operations. <b>nuclei</b> supports scanning single targets, lists of targets, or even output from other reconnaissance tools, making it an an integral part of automated security workflows. It's often integrated into CI/CD pipelines or used for continuous monitoring of an organization's attack surface.


title: CAVEATS
content:
<b>nuclei</b> is not a default system utility in Linux distributions and must be installed separately.<br><br>Effective use relies heavily on having up-to-date templates, which are regularly maintained by the <i>ProjectDiscovery</i> team and the community. Outdated templates may lead to missed vulnerabilities.<br><br>When performing scans, especially against external targets, always ensure you have explicit authorization. Unauthorized scanning can be illegal and unethical, potentially causing disruption or legal repercussions. Be mindful of the network traffic and load generated, as aggressive scanning can impact target systems.


title: TEMPLATE SYSTEM
content:
The core of <b>nuclei</b>'s functionality is its highly flexible and extensible template system. Templates are written in YAML and define the logic for a specific security check, including HTTP requests, response patterns, and vulnerability conditions. This allows users to create custom checks for virtually any scenario, from detecting specific software versions to identifying complex logical vulnerabilities. The <i>ProjectDiscovery</i> team maintains a public repository of thousands of community-contributed templates covering a wide range of CVEs, misconfigurations, and information disclosures, which are automatically updated by the <b>nuclei</b> tool.


title: INSTALLATION
content:
<b>nuclei</b> is typically installed via <i>go install</i> if you have Go language environment set up (e.g., <i>go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest</i>), or by downloading pre-compiled binaries from the <i>ProjectDiscovery</i> GitHub releases page. After installation, it's crucial to run <i>nuclei -update-templates</i> to fetch the latest vulnerability definitions.


title: ETHICAL USE
content:
Due to its powerful scanning capabilities, it is imperative to use <b>nuclei</b> responsibly and ethically. Always obtain explicit permission from target system owners before initiating any scans. Unauthorized scanning can lead to legal consequences and ethical breaches. <b>nuclei</b> is a tool intended for authorized security assessments and bug bounty programs.


title: HISTORY
content:
<b>nuclei</b> was developed by <i>ProjectDiscovery</i>, a group known for creating various open-source reconnaissance and security testing tools. Since its initial release, <b>nuclei</b> has rapidly gained traction within the cybersecurity community due to its innovative template-based approach, high performance, and the active contributions from its community.<br><br>It emerged as a powerful alternative and complement to traditional vulnerability scanners, offering unparalleled flexibility through its YAML-based template engine. This design allows security researchers and developers to quickly define and share custom checks for newly discovered vulnerabilities or specific organizational requirements, fostering a collaborative environment for security research and automation.


title: SYNOPSIS
content:
<b>numactl</b> [<i>options</i>] [<i>command</i> [<i>arguments...</i>]]<br><b>numactl</b> --hardware<br><b>numactl</b> --show


title: PARAMETERS
content:
<b><b>--hardware</b>, <b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports the NUMA hardware configuration of the system, including available nodes, their memory sizes, and CPU mappings.<br><br><b><b>--show</b>, <b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the default NUMA policy that would apply to a new process or the current policy for the running process.<br><br><b><b>--preferred=nodes</b>, <b>-p nodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a preferred node for memory allocation. The system will try to allocate memory from this node first, falling back to other nodes if necessary. <i>nodes</i> can be a comma-separated list or a range (e.g., '0', '0,1', '0-3').<br><br><b><b>--cpunodebind=nodes</b>, <b>-N nodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Binds the process to the CPUs of the specified NUMA <i>nodes</i>. The process will only run on CPUs belonging to these nodes. <i>nodes</i> can be 'all' or a list/range.<br><br><b><b>--membind=nodes</b>, <b>-m nodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Binds memory allocation strictly to the specified NUMA <i>nodes</i>. Memory will only be allocated from these nodes. If allocation fails, it will not fall back to other nodes unless <b>--strict</b> is not used.<br><br><b><b>--interleave=nodes</b>, <b>-i nodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interleaves memory allocation across the specified NUMA <i>nodes</i>. This is useful for workloads that benefit from spreading memory evenly across multiple nodes to maximize bandwidth.<br><br><b><b>--localalloc</b>, <b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always allocates memory on the NUMA node where the thread is currently executing. This is typically the default policy for new pages but can be explicitly enforced.<br><br><b><b>--physcpubind=cpus</b>, <b>-C cpus</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Binds the process to a specific set of physical CPUs. <i>cpus</i> can be a comma-separated list or a range (e.g., '0', '0,2', '0-3').<br><br><b><b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enforces strict memory binding. If a memory allocation request cannot be satisfied on the bound nodes, the allocation will fail instead of falling back to other nodes.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the specified NUMA policy to all pages in the current process's address space, not just new allocations. This is typically used with `set-*` options.<br><br><b><b>--offset=offset</b>, <b>-o offset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an offset into a shared memory segment for policy application.<br><br><b><b>--length=length</b>, <b>-L length</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the length of a shared memory segment for policy application, in bytes.<br><br><b><b>--shmmode=shmmode</b>, <b>-M shmmode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the shared memory mode (e.g., 'shm_open' for <i>shm_open()</i> or 'mmap' for <i>mmap()</i> based segments).<br><br><b><b>--huge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the policy to huge pages. Requires system configuration for huge pages.<br><br><b><b>--set-preferred=node</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the preferred node policy for the current process without executing a new command.<br><br><b><b>--set-localalloc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the local allocation policy for the current process without executing a new command.<br><br><b><b>--set-membind=nodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the memory bind policy for the current process without executing a new command.<br><br><b><b>--set-interleave=nodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the interleave policy for the current process without executing a new command.<br><br>


title: DESCRIPTION
content:
The <b>numactl</b> command provides a powerful interface for controlling NUMA (Non-Uniform Memory Access) policies for processes or shared memory segments on Linux systems. In NUMA architectures, memory access times can vary depending on which CPU accesses which memory bank. Memory physically closer to a CPU (on the same NUMA node) is faster to access than memory on a different node.<br><br><b>numactl</b> allows users to fine-tune where processes execute (CPU affinity) and from which NUMA nodes memory is allocated (memory affinity). This is critical for optimizing performance in multi-socket server environments, especially for High-Performance Computing (HPC) and large database systems. By intelligently placing processes and their data on the same NUMA node, <b>numactl</b> helps reduce remote memory access latency, thereby improving application throughput and responsiveness.<br><br>It can be used to launch a new command with specific NUMA policies or to inspect and modify the NUMA policy of an already running process.


title: CAVEATS
content:
Using <b>numactl</b> effectively requires a good understanding of the system's NUMA topology and the application's memory access patterns. Misconfigured policies can lead to degraded performance or even application failures (especially with <b>--strict</b>). Policies set by <b>numactl</b> are inherited by child processes by default. Ensure your kernel has NUMA support enabled.


title: NODES AND CPUS SPECIFICATION
content:
Arguments for <i>nodes</i> and <i>cpus</i> can be specified as a comma-separated list (e.g., '0,2,4'), a range (e.g., '0-3'), or a combination thereof. The keyword 'all' can be used to select all available nodes or CPUs. A leading '+' can be used to add nodes/cpus to the current set (e.g., '+0' to add node 0).


title: POLICY INHERITANCE
content:
When <b>numactl</b> is used to launch a command, the specified NUMA policies are inherited by that command and any of its child processes. This behavior is crucial for ensuring that an entire application stack adheres to the desired NUMA placement strategies. Policies can be overridden by child processes if they explicitly call NUMA-aware functions or themselves invoke <b>numactl</b>.


title: MEMORY ALLOCATION POLICIES EXPLAINED
content:
<i>Preferred</i>: Attempts to allocate from the specified node first, but will fall back to other nodes if the preferred node is full or unavailable.<br><br><i>Bind</i>: Strictly allocates from the specified nodes. If these nodes cannot satisfy the request (and <b>--strict</b> is used), the allocation fails.<br><br><i>Interleave</i>: Distributes memory pages evenly across the specified nodes in a round-robin fashion. Useful for applications that access large data sets uniformly across multiple nodes.<br><br><i>Localalloc</i>: Always allocates memory on the NUMA node where the current thread is running. This minimizes latency for data local to the executing CPU.


title: HISTORY
content:
The advent of multi-socket server architectures led to the development of NUMA (Non-Uniform Memory Access) systems, where processors have faster access to local memory than to remote memory. Linux kernel developers gradually introduced robust NUMA awareness and management capabilities.<br><br>The <b>numactl</b> utility emerged as a user-space tool to expose these kernel features. It provides a convenient way for system administrators and developers to apply CPU and memory placement policies without modifying application code. Its development paralleled the increasing need for performance optimization in data centers and HPC environments, becoming an essential tool for maximizing resource utilization on NUMA hardware.


title: PARAMETERS
content:
<b><b>-b TYPE</b>, <b>--body-numbering=TYPE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects numbering style for body lines. <i>TYPE</i> can be <i>a</i> (all lines), <i>t</i> (non-empty lines, default), <i>n</i> (no numbering), or <i>pREGEX</i> (lines matching regex).<br><br><b><b>-f TYPE</b>, <b>--footer-numbering=TYPE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects numbering style for footer lines. Same <i>TYPE</i> options as for body lines.<br><br><b><b>-h TYPE</b>, <b>--header-numbering=TYPE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects numbering style for header lines. Same <i>TYPE</i> options as for body lines.<br><br><b><b>-l N</b>, <b>--line-increment=N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of lines to count before numbering again (e.g., number every <i>N</i>th line).<br><br><b><b>-s STRING</b>, <b>--separator=STRING</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the string appended to the line number, separating it from the text line. Default is a tab character.<br><br><b><b>-v N</b>, <b>--starting-line-number=N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the starting line number for the first line. Default is 1.<br><br><b><b>-w N</b>, <b>--width=N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of characters to use for line numbers. Default is 6.<br><br><b><b>-n FORMAT</b>, <b>--number-format=FORMAT</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inserts line numbers according to <i>FORMAT</i>. Options include <i>ln</i> (left justified, no leading zeros), <i>rn</i> (right justified, no leading zeros), <i>rz</i> (right justified, leading zeros, default).<br><br><b><b>-p</b>, <b>--no-renumber</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not renumber at logical page breaks (defined by section delimiters).<br><br><b><b>-d CC</b>, <b>--section-delimiter=CC</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses <i>CC</i> (two characters) as the logical page delimiter characters instead of the default <i>\:\:</i>.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs version information and exits.<br><br>


title: DESCRIPTION
content:
The command '<b>number</b>' is not a standard, standalone Linux command. This analysis assumes the user was referring to <i>nl</i> (number lines), a common utility for adding line numbers to text files. <br><br>The <i>nl</i> command numbers lines of files, writing the result to standard output. It is highly useful for displaying source code, log files, or any text where line numbers are beneficial for reference. It can number all lines, non-empty lines, or only lines that match a regular expression. Various formatting options are available, such as number width, leading zeros, and different numbering styles.


title: CAVEATS
content:
The primary function of <i>nl</i> is line numbering, not general numeric processing. For generating sequences of numbers or performing arithmetic operations, commands like <i>seq</i> or scripting with <i>awk</i> are more suitable. While <i>nl</i> is part of GNU coreutils and widely available on Linux, it's specific to text line manipulation.


title: CLARIFICATION ON 'NUMBER' COMMAND
content:
The command '<b>number</b>' is not a standard, standalone Linux command found in typical distributions. This document has provided information based on the highly related and commonly used <i>nl</i> command, which directly deals with assigning and formatting numbers (line numbers) to text content. If you were looking for general numeric processing or sequence generation, please consider commands like <i>seq</i> or scripting capabilities within tools like <i>awk</i> or shell arithmetic.


title: HISTORY
content:
The <i>nl</i> command is a standard Unix utility, part of the POSIX standard. Its functionality has been stable for many decades. It is included in GNU coreutils, which provides the standard utilities for Linux systems, ensuring its widespread availability and consistent behavior.


title: PARAMETERS
content:
<b>--from=<i>UNIT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input unit for numbers. Common units include <i>auto</i> (detects common suffixes), <i>si</i> (powers of 1000, e.g., 'K' for 1000), or <i>iec-bytes</i> (powers of 1024, e.g., 'K' for 1024).<br><br><b>--to=<i>UNIT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output unit for numbers. Similar to <i>--from</i>, allows conversion to different scales and unit systems.<br><br><b>-d, --delimiter=<i>DELIM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>DELIM</i> as the field delimiter for input and output, instead of the default whitespace.<br><br><b>-f, --fields=<i>FIELDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select specific fields (columns) to convert. Fields can be a comma-separated list or a range (e.g., '1,3-5' or '2-').<br><br><b>--format=<i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a <i>printf</i>-style <i>FORMAT</i> string for the output number (e.g., '%.2f' for two decimal places, or '%' to add a percentage sign).<br><br><b>--round=<i>METHOD</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the rounding method to use. Options include <i>up</i> (round towards positive infinity), <i>down</i> (round towards negative infinity), <i>nearest</i> (round to nearest, ties to even), and <i>from-zero</i> (round away from zero).<br><br><b>--suffix=<i>SUFFIX</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append a <i>SUFFIX</i> to the end of each converted number in the output.<br><br><b>--invalid=<i>METHOD</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define behavior for invalid numbers encountered in input. Methods include <i>fail</i> (exit with error), <i>warn</i> (print warning), <i>ignore</i> (skip conversion), or <i>abort</i> (exit immediately).<br><br><b>-H, --header</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat the first line of input as a header and skip its conversion, passing it through unchanged.<br><br>


title: DESCRIPTION
content:
<i>numfmt</i> is a GNU Coreutils command-line utility designed for formatting and converting numbers between various human-readable formats and raw numerical values. It's particularly useful when dealing with file sizes, memory quantities, or other large numbers that are often expressed with suffixes like 'K', 'M', 'G' (for kilobytes, megabytes, gigabytes).<br><br>The command can interpret numbers with these suffixes (e.g., '1.5G') and convert them into their byte equivalent, or vice-versa. It supports both SI units (powers of 1000) and IEC binary units (powers of 1024), allowing precise control over how numbers are interpreted and displayed.<br><br><i>numfmt</i> excels in scripting contexts, allowing developers and system administrators to process numerical data from command outputs or log files, ensuring consistent formatting for display or further calculations. It provides options for specifying input/output units, field selection, rounding methods, and custom output formatting.


title: CAVEATS
content:
<i>numfmt</i> primarily operates on numbers expressed with standard SI or IEC binary prefixes. It may not handle arbitrary complex numerical expressions or scientific notation outside of these contexts without specific formatting.<br><br>The default interpretation for units is IEC binary (powers of 1024) for input and output, which can sometimes lead to confusion if SI units (powers of 1000) are expected and not explicitly specified with <i>--from=si</i> or <i>--to=si</i>. Always be mindful of the unit system being used.


title: TYPICAL USE CASES
content:
<i>numfmt</i> is frequently used by system administrators and developers to:<br><ul><li>Convert output from commands like <i>ls -lh</i> or <i>df -h</i> (which use human-readable formats) into raw bytes for calculations or sorting.</li><li>Format raw byte counts into human-readable sizes (e.g., '1048576' to '1M').</li><li>Process logs or data files where numerical values are embedded with various unit suffixes to normalize the data.</li></ul>


title: UNIT INTERPRETATION
content:
By default, <i>numfmt</i> uses IEC binary prefixes (Ki, Mi, Gi representing powers of 1024). This is common in computing for memory and disk sizes.<br><br>To use standard SI decimal prefixes (K, M, G representing powers of 1000), which are more common in general measurements and some networking contexts, the <i>--from=si</i> or <i>--to=si</i> option must be explicitly used. Understanding this distinction is crucial for accurate and expected conversions.


title: HISTORY
content:
<i>numfmt</i> is a relatively modern addition to the GNU Coreutils package, which provides essential command-line utilities for Linux and other Unix-like operating systems. It was introduced to standardize and simplify the conversion of human-readable numbers, particularly sizes, making it easier to script and automate tasks involving such data. Its development aligns with the GNU project's goal of providing robust and flexible tools for system administration and data processing.


title: SYNOPSIS
content:
<b>numlockx</b> [<i>on</i> | <i>off</i> | <i>toggle</i> | <i>status</i>] [<b>--display</b> <i>display</i>]


title: PARAMETERS
content:
<b>on</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns the Num Lock key on.<br><br><b>off</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns the Num Lock key off.<br><br><b>toggle</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Toggles the current state of the Num Lock key (if it's on, it turns it off; if it's off, it turns it on).<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current state of the Num Lock key to standard output (e.g., &quot;Numlock is on&quot;).<br><br><b>--display <i>display</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to connect to. This is useful when controlling Num Lock on a remote or specific display other than the default.<br><br>


title: DESCRIPTION
content:
numlockx is a lightweight command-line utility for the X Window System designed to manage the state of the Num Lock key. It allows users to explicitly enable, disable, or toggle the Num Lock status on their X session's keyboard. This tool is particularly useful for ensuring that Num Lock is in a desired state (e.g., always on) when an X session starts, often by being included in startup scripts like <i>.xinitrc</i> or <i>.xprofile</i>. It interacts directly with the X server's keyboard settings to modify the key's behavior, providing a simple yet effective way to maintain consistent Num Lock functionality across various desktop environments or login managers that might otherwise leave it off by default.


title: CAVEATS
content:
numlockx operates within the X Window System environment and therefore requires an active X server. It will not function in a text-only console. In some complex keyboard setups or environments where other applications are constantly remapping keys, its effects might be overridden or appear inconsistent.


title: <B>DEFAULT BEHAVIOR</B>
content:
When invoked without any arguments (e.g., <b>numlockx</b>), the command defaults to the <i>toggle</i> action, changing the Num Lock state from its current setting.


title: <B>STARTUP INTEGRATION</B>
content:
A common use case is to add <b>numlockx</b> <i>on</i> to user-specific X startup scripts (like <i>~/.xinitrc</i>, <i>~/.xprofile</i>, or desktop environment specific autostart locations) to ensure Num Lock is always enabled upon graphical session login.


title: HISTORY
content:
numlockx is a well-established utility within the Linux and Unix-like operating systems' X Window System ecosystem. Its purpose has remained consistent since its inception: to provide a simple command-line interface for managing the Num Lock key state. It fills a common need for users who prefer Num Lock to be enabled by default, especially on systems where desktop environments or login managers might not consistently set this preference. Its development reflects a focus on stability and straightforward functionality, with minimal changes to its core behavior over the years.


title: PARAMETERS
content:
<b><b>-o</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the name of the output file.</i><br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Compile and assemble only; do not link. Produces object files.</i><br><br><b><b>-arch=sm_<i>XX</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the target NVIDIA GPU architecture (e.g., <b>sm_70</b> for Volta, <b>sm_80</b> for Ampere).</i><br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generate host debugging information (for CPU code).</i><br><br><b><b>-G</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generate device debugging information (for GPU code). Enables profiling.</i><br><br><b><b>-I</b> <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Add a directory to the list of paths searched for include files.</i><br><br><b><b>-L</b> <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Add a directory to the list of paths searched for libraries.</i><br><br><b><b>-l</b> <i>&lt;lib&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Link with the specified library (e.g., <b>-lcudart</b>).</i><br><br><b><b>-Xcompiler</b> <i>&lt;opts&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Pass options directly to the host C++ compiler.</i><br><br><b><b>-Xlinker</b> <i>&lt;opts&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Pass options directly to the linker.</i><br><br><b><b>-Xptxas</b> <i>&lt;opts&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Pass options directly to the PTX optimizing assembler (ptxas).</i><br><br><b><b>-maxrregcount=<i>N</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the maximum number of registers that a GPU kernel can use.</i><br><br><b><b>-rdc=true</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable relocatable device code, required for device-side linking.</i><br><br>


title: DESCRIPTION
content:
<i>nvcc</i> is the <b>NVIDIA CUDA Compiler driver</b>, a powerful tool for compiling CUDA C/C++ source files. It acts as a wrapper around a host C++ compiler (like <i>gcc</i> or <i>MSVC</i>) and the NVIDIA PTX assembler/optimizing compiler (<i>ptxas</i>).<br><br>Its primary function is to orchestrate the entire compilation process, which involves separating host code from device code. It first extracts the device code, compiles it into PTX (Parallel Thread Execution) assembly or SASS (GPU assembly code), and then uses the host compiler to compile the remaining host code. Finally, it links all compiled components—host object files, device object files, and necessary CUDA runtime libraries—to produce an executable or a shared library.<br><br><i>nvcc</i> supports various compilation targets, including different NVIDIA GPU architectures, and allows developers to optimize code for specific hardware. It is an essential tool for building high-performance computing applications that leverage the parallel processing capabilities of NVIDIA GPUs.


title: CAVEATS
content:
<i>Building CUDA applications can be complex due to the interplay between host and device compilation environments. Debugging GPU code often requires specialized tools (like NVIDIA Nsight). Compatibility between CUDA toolkit versions, GPU drivers, and target hardware architectures must be carefully managed. Cross-compilation for different CPU architectures (e.g., ARM) or GPU architectures also introduces additional complexities.</i>


title: <B>CUDA COMPILATION WORKFLOW</B>
content:
<i>A typical <b>nvcc</b> compilation involves several stages:<br>1. <b>Preprocessing</b>: Handles directives like <b>#include</b>.<br>2. <b>CUDA Compilation</b>: <b>nvcc</b> extracts device code and compiles it to PTX (virtual assembly) or SASS (native GPU assembly). This may involve multiple PTX generations for different architectures.<br>3. <b>Host Compilation</b>: The remaining host code is compiled by the underlying host C++ compiler (e.g., <b>gcc</b>).<br>4. <b>Linking</b>: Host object files, device object files, and necessary CUDA runtime libraries are linked to form the final executable or library.</i>


title: <B>JUST-IN-TIME (JIT) COMPILATION</B>
content:
<i>If <b>nvcc</b> includes PTX code for a newer architecture not supported by the current driver, the driver can perform <b>JIT compilation</b>. The PTX code is compiled to SASS at runtime on the target GPU, allowing binaries compiled for older architectures to run on newer hardware, albeit potentially with a slight performance overhead during the first kernel launch.</i>


title: HISTORY
content:
<i><b>nvcc</b> emerged with the introduction of NVIDIA's CUDA platform in 2007, marking a pivotal shift in general-purpose GPU computing. Prior to CUDA, GPGPU programming was often done using graphics APIs. <b>nvcc</b> provided a more familiar C/C++ development environment for parallel programming, abstracting away much of the low-level GPU details. Since its inception, <b>nvcc</b> has evolved significantly with each new generation of NVIDIA GPUs and CUDA toolkit releases, adding support for new architectural features, programming models (e.g., dynamic parallelism, cooperative groups), and compilation optimizations, solidifying its role as the cornerstone of CUDA development.</i>


title: SYNOPSIS
content:
<b>nvim</b> [<I>options</I>] [<I>file</I> ...] <br><b>nvim</b> -o[<I>N</I>] [<I>file</I> ...] <br><b>nvim</b> -O[<I>N</I>] [<I>file</I> ...] <br><b>nvim</b> -q [<I>errorfile</I>] <br><b>nvim</b> -S [<I>sessionfile</I>]


title: PARAMETERS
content:
<b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edits a file in binary mode.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts in diff mode, useful for comparing files.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts in Ex mode, for line-oriented editing.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not use a swap file, useful for temporary edits or slow network drives.<br><br><b>-o[N]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens <I>N</I> windows horizontally, with <I>N</I> files if specified. Default is one window per file.<br><br><b>-O[N]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens <I>N</I> windows vertically, similar to -o.<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts in read-only mode, preventing accidental writes.<br><br><b>-S <sessionfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores the editor state from the specified session file.<br><br><b>-u <init.lua></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the specified file as the initialization file instead of the default <I>init.lua</I>.<br><br><b>--cmd <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the given <I>command</I> before processing <I>init.lua</I>.<br><br><b>--headless</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Neovim without a UI, useful for scripting or as a server.<br><br><b>--clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Neovim with an empty configuration, ignoring user <I>init.lua</I> and plugins.<br><br>


title: DESCRIPTION
content:
<b>nvim</b> is a refactor of Vim, aiming to be more extensible, user-friendly, and maintainable. It's built on a strong foundation, inheriting Vim's powerful modal editing paradigm, which distinguishes between various modes (normal, insert, visual, etc.) for efficient text manipulation. <br><br>Key features of Neovim include an asynchronous job control API, allowing plugins to run tasks in the background without freezing the editor, and a remote plugin architecture. This enables plugins to be written in any language (Python, Node.js, Ruby, etc.) and communicate with Neovim over a MsgPack-RPC interface, significantly expanding its capabilities and the plugin ecosystem. <br><br>Neovim also provides a built-in terminal emulator, a powerful configuration system often utilizing Lua for its modern plugin ecosystem, and improved default settings. It aims to accelerate innovation in the Vim ecosystem by improving the core and providing a robust API for developers. While retaining strong compatibility with Vim's configuration and features, Neovim often feels faster and more responsive, especially with complex setups or large files, making it a popular choice for developers and power users.


title: CAVEATS
content:
Neovim, like its predecessor Vim, has a <I>steep learning curve</I> for users new to modal editing. Its powerful configuration, while highly flexible, often relies on Lua for advanced setups, requiring some familiarity with the language. <br>While striving for Vim compatibility, some legacy Vim plugins or highly specific configurations might require <I>minor adjustments</I> to function optimally within the Neovim environment. Additionally, performance can be influenced by the quantity and complexity of loaded plugins.


title: LUA CONFIGURATION
content:
Neovim strongly encourages and supports <I>Lua</I> for its configuration and plugin development, offering a more modern and powerful scripting alternative to Vimscript.


title: ASYNCHRONOUS JOB CONTROL
content:
A core feature is the ability to run external commands and plugins <I>asynchronously</I>, preventing the editor from freezing during long-running tasks and improving responsiveness.


title: BUILT-IN TERMINAL EMULATOR
content:
Neovim includes a powerful <I>:terminal</I> command, allowing users to run shell commands or interact with other tools directly within an editor buffer.


title: HISTORY
content:
Neovim originated in 2014, conceived by Thiago de Moraes and successfully crowdfunded. The project's primary goal was to thoroughly <I>refactor Vim</I>'s codebase to enable a more modern, extensible architecture. Key innovations included introducing an asynchronous job control API and a remote plugin architecture using MsgPack-RPC, which allowed plugins to be written in any language and run out-of-process. This addressed some of Vim's architectural limitations and significantly expanded its capabilities, fostering a vibrant new ecosystem of plugins and integrations. Its development has been community-driven, focusing on a stable, performant core while maintaining high compatibility with Vim's extensive feature set and configuration.


title: SYNOPSIS
content:
<b>nvm</b> <i>&lt;command&gt;</i> [<i>&lt;arguments&gt;</i>]<br>Common commands:<br><b>nvm</b> <b>install</b> <i>&lt;version&gt;</i><br><b>nvm</b> <b>use</b> <i>&lt;version&gt;</i><br><b>nvm</b> <b>ls</b> [<i>&lt;remote|installed&gt;</i>]<br><b>nvm</b> <b>alias</b> <i>&lt;name&gt;</i> <i>&lt;version&gt;</i><br><b>nvm</b> <b>uninstall</b> <i>&lt;version&gt;</i>


title: PARAMETERS
content:
<b>install <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specified Node.js version (e.g., <i>18.17.1</i>, <i>lts/gallium</i>, <i>node</i>).<br><br><b>use <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches to and uses the specified Node.js version in the current shell.<br><br><b>ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all Node.js versions installed by <b>nvm</b>.<br><br><b>ls-remote</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available Node.js versions for remote installation.<br><br><b>alias <name> <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates or manages aliases for installed Node.js versions (e.g., <i>default</i>, <i>lts</i>).<br><br><b>uninstall <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed Node.js version from your system.<br><br><b>current</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the currently active Node.js version managed by <b>nvm</b>.<br><br><b>which <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the path to the Node.js executable for a given version.<br><br><b>run <version> <script> [args]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a script with a specific Node.js version.<br><br><b>deactivate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undoes the effect of <b>nvm use</b> by removing <b>nvm</b> from your shell's <b>PATH</b>.<br><br><b>set-default <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the specified Node.js version as the default for new shells.<br><br>


title: DESCRIPTION
content:
<b>nvm</b> (Node Version Manager) is a command-line tool that allows you to easily install, manage, and switch between different Node.js versions on a single machine. It addresses common development challenges where various projects require specific Node.js or npm versions for compatibility. <b>nvm</b> works by modifying your shell's <b>PATH</b> environment variable to point to the desired Node.js installation. This enables developers to seamlessly switch contexts without manual uninstallation and reinstallation, ensuring project dependencies are met and avoiding version conflicts. It's particularly useful for maintaining legacy applications, working on new projects with cutting-edge Node.js features, or collaborating in diverse development environments.


title: CAVEATS
content:
<b>Shell Function:</b> <b>nvm</b> is implemented as a shell function, not a binary. This means it must be sourced into your shell (e.g., in <i>.bashrc</i>, <i>.zshrc</i>) to function correctly.<br><b>PATH Manipulation:</b> It modifies your shell's <b>PATH</b> environment variable. Issues can arise if <b>nvm</b> is not sourced correctly or if other Node.js installations are prioritized in <b>PATH</b>.<br><b>Windows Incompatibility:</b> The official <b>nvm</b> script is designed for Unix-like systems (Linux, macOS). For Windows, a separate project, <i>nvm-windows</i>, is available, which operates differently.<br><b>Global npm packages:</b> When switching Node.js versions, globally installed npm packages are not automatically migrated. You might need to reinstall them for each version.


title: INSTALLATION AND SOURCING
content:
<b>nvm</b> is typically installed by curling a script from its GitHub repository, which then places the <i>nvm.sh</i> script in your home directory (e.g., <i>~/.nvm</i>). For <b>nvm</b> to work, you must add a line to your shell's startup file (e.g., <i>~/.bashrc</i>, <i>~/.zshrc</i>) to source this script (e.g., <i>export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"</i>). This ensures <b>nvm</b>'s functions are available in your shell session.


title: .NVMRC FILES
content:
<b>nvm</b> supports <i>.nvmrc</i> files, which are plain text files in a project's root directory specifying the required Node.js version for that project (e.g., <i>v18.17.1</i> or <i>lts/gallium</i>). When you navigate into a directory containing an <i>.nvmrc</i> file and run <i>nvm use</i>, <b>nvm</b> automatically detects and switches to the specified version, streamlining multi-project development workflows.


title: HISTORY
content:
<b>nvm</b> was created by <i>Tim Caswell</i> and released in <i>2010</i>, shortly after Node.js itself gained popularity. Its development aimed to address the growing need for developers to manage multiple Node.js environments for different projects without conflicts. Over the years, it has evolved into the de facto standard tool for Node.js version management in Unix-like environments, accumulating a large community of contributors and users due to its flexibility and robustness.


title: SYNOPSIS
content:
<i>nvm.fish</i> itself is typically sourced or loaded via a Fish plugin manager (e.g., Fisher, Oh My Fish).<br><br>Once loaded, <i>nvm</i> commands become available:<br><br><b>nvm</b> <i>[<command>] [<args>]</i><br><br>Examples:<br><b>nvm install node</b><br><b>nvm use 16</b><br><b>nvm ls</b>


title: PARAMETERS
content:
<b>install <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specific Node.js version or the latest stable version.<br><br><b>use <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the active Node.js version for the current shell session.<br><br><b>ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all installed Node.js versions and indicates the current one.<br><br><b>alias <name> <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates or updates an alias for a specific Node.js version.<br><br><b>uninstall <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstalls a specific Node.js version.<br><br><b>current</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the currently active Node.js version.<br><br><b>exec <version> <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a command with a specific Node.js version without changing the current shell's version.<br><br><b>deactivate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates <i>nvm</i>, reverting to the system's default Node.js (if any).<br><br>


title: DESCRIPTION
content:
<i>nvm.fish</i> is a community-contributed Fish shell plugin that provides seamless integration for Node Version Manager (<i>nvm</i>) functionality within the friendly interactive shell. Unlike <i>nvm</i> which is primarily designed for Bash and Zsh, <i>nvm.fish</i> handles the intricacies of Fish's path and function management, allowing users to install, switch, and manage multiple Node.js versions without leaving their Fish environment. It smartly loads <i>nvm</i> on demand to improve shell startup performance, ensuring that common <i>nvm</i> commands like <b>nvm install</b>, <b>nvm use</b>, <b>nvm ls</b>, and <b>nvm alias</b> work as expected. This makes Node.js development in Fish a much smoother and more efficient experience, bridging the gap between a popular version manager and a modern shell.


title: CAVEATS
content:
Requires the core <i>nvm</i> (Node Version Manager) to be installed and accessible, as <i>nvm.fish</i> acts as a wrapper, not a standalone replacement. Due to Fish shell's distinct function and path handling, its behavior can sometimes differ from <i>nvm</i>'s native operation in Bash/Zsh. While designed for lazy loading, frequent Node.js version switches can still incur some performance overhead. Its functionality is intrinsically linked to and dependent on the underlying <i>nvm</i> Bash/Zsh scripts.


title: INSTALLATION
content:
<i>nvm.fish</i> is most commonly installed using a Fish plugin manager like Fisher. For example, to install with Fisher:<br><b>fisher install jorgebucaran/nvm.fish</b><br>Alternatively, it can be manually sourced in your <i>~/.config/fish/config.fish</i> file.


title: LAZY LOADING
content:
A key design principle of <i>nvm.fish</i> is 'lazy loading'. It avoids loading the full <i>nvm</i> script into memory during shell startup. Instead, <i>nvm</i> is sourced only when an actual <b>nvm</b> command is invoked for the first time, ensuring fast shell initialization times.


title: HISTORY
content:
<i>nvm.fish</i> emerged from the community's need to leverage the popular <i>nvm</i> tool within the Fish shell, which has different scripting paradigms compared to Bash or Zsh. Early solutions often involved manual hacks or incomplete functions. This project streamlined the process, providing a robust and well-maintained bridge. Its development focuses on ensuring ongoing compatibility with <i>nvm</i>'s evolving feature set and adapting to Fish shell's unique environment management system, making <i>nvm</i> a first-class citizen in Fish.


title: SYNOPSIS
content:
<b>nvme</b> <<i>command</i>> [<i>options</i>] [<i>arguments</i>]<br><br>The <i>nvme</i> utility acts as a meta-command, where <<i>command</i>> refers to a specific subcommand (e.g., <i>identify</i>, <i>smart-log</i>, <i>format</i>) that performs a particular operation on an NVMe device. Each subcommand typically has its own specific set of options and arguments.


title: PARAMETERS
content:
<b><b>--device</b>, <b>-d</b> <i><device></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the NVMe device path (e.g., <i>/dev/nvme0</i> or <i>/dev/nvme0n1</i>). This is often a mandatory or highly common option for subcommands.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help for the <i>nvme</i> command, or help for a specific subcommand if provided immediately after the subcommand (e.g., <i>nvme identify --help</i>).<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the command results in JSON format, which is useful for scripting and programmatic parsing.<br><br><b><b>--output-format</b>, <b>-o</b> <i><format></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format, e.g., 'normal' (default), 'json', 'binary'. Not all subcommands support all formats.<br><br><b><b>--human-readable</b>, <b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays sizes and capacities in human-readable units (e.g., GB, TB).<br><br><b><b>--verbose</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, showing more details about the operation.<br><br>


title: DESCRIPTION
content:
<i>nvme</i> is a powerful command-line interface tool used for managing Non-Volatile Memory Express (NVMe) devices. It provides a comprehensive set of functionalities for interacting with NVMe SSDs, including administrative tasks like firmware updates, namespace management, health monitoring, error logging, and I/O operations. This utility allows users and administrators to configure, debug, and monitor NVMe storage devices, making it an essential tool for systems utilizing modern high-performance storage that leverages the PCIe interface for faster data transfer.


title: CAVEATS
content:
Most <i>nvme</i> commands require root privileges to execute, as they interact directly with hardware devices. Improper use of commands like <i>nvme format</i> or <i>nvme firmware activate</i> can lead to data loss or render the NVMe device unusable. Always ensure you are targeting the correct device and understand the implications of the subcommand being executed.


title: KEY SUBCOMMANDS
content:
The <i>nvme</i> command's power comes from its various subcommands, each performing a specific task:<br><i><b>nvme list</b></i>: Lists all NVMe devices and their basic information.<br><i><b>nvme identify</b></i>: Displays detailed information about a specific NVMe controller or namespace.<br><i><b>nvme smart-log</b></i>: Retrieves and displays S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) and health information.<br><i><b>nvme format</b></i>: Securely formats an NVMe namespace, erasing all data.<br><i><b>nvme firmware activate/download</b></i>: Manages firmware updates for the NVMe device.<br>


title: DEVICE NAMING CONVENTION
content:
NVMe devices in Linux typically follow the naming convention <i>/dev/nvmeXnYmP</i>, where:<br><i><b>X</b></i>: The controller ID (e.g., 0, 1).<br><i><b>n</b></i>: Denotes a namespace.<br><i><b>Y</b></i>: The namespace ID (e.g., 1, 2).<br><i><b>mP</b></i>: (Optional) Denotes a partition on a namespace (e.g., p1, p2).


title: HISTORY
content:
The Non-Volatile Memory Express (NVMe) specification emerged in 2011, designed to overcome the limitations of older storage interfaces (like SATA and SAS) by leveraging the high-speed PCI Express (PCIe) bus. This allowed SSDs to achieve significantly higher performance. The <i>nvme-cli</i> project, which provides the <i>nvme</i> command-line utility, was developed to provide user-space control and management capabilities for these advanced devices in Linux. Its development has closely tracked the increasing adoption of NVMe technology in data centers, enterprise servers, and consumer systems, becoming the standard tool for NVMe device interaction.


title: SYNOPSIS
content:
<I>nxplayer</I> [<i>OPTIONS</i>] [<i>SESSION_FILE</i> | --url <I>URL</I>]<br><i>Note:</i> Running <I>nxplayer</I> without arguments typically launches the graphical user interface to create or manage connections.


title: PARAMETERS
content:
<b>--session <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads a specific NoMachine session configuration file (.nxs).<br><br><b>--url <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a remote host specified by a NoMachine URL (e.g., <I>nx://host:port</I>).<br><br><b>--attach <session_id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches to an existing remote session by its ID.<br><br><b>--login <username></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for authentication without prompting.<br><br><b>--password <password></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the password for authentication directly (use with caution due to security).<br><br><b>--key <private_key_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to an SSH private key for key-based authentication.<br><br><b>--full-screen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the remote desktop session in full-screen mode.<br><br><b>--geometry <WxH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial resolution of the remote desktop window (e.g., <I>1024x768</I>).<br><br><b>--protocol <protocol></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the connection protocol (e.g., <I>NX</I>, <I>SSH</I>, <I>VNC</I>, <I>RDP</I>).<br><br><b>--display <display></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a specific X display on the local machine.<br><br><b>--disable-audio</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables audio redirection for the session.<br><br><b>--enable-mic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables microphone redirection.<br><br><b>--file-transfer disable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables file transfer capabilities.<br><br><b>--print-transfer disable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables printer redirection.<br><br><b>--usb-transfer disable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables USB device redirection.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise help message with common command-line options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed NoMachine client version.<br><br>


title: DESCRIPTION
content:
<I>NoMachine NX</I> is a powerful, cross-platform remote desktop technology designed for fast and secure graphical access over networks. The <I>nxplayer</I> command on Linux launches the NoMachine client application, enabling users to establish highly responsive connections to remote NoMachine NX servers. It excels at delivering a smooth graphical experience even on high-latency or low-bandwidth connections, leveraging sophisticated compression, caching, and display rendering techniques. Beyond basic remote access, it supports features like session recording, desktop sharing, file transfer, and device redirection (e.g., USB, printers). While primarily a graphical application, <I>nxplayer</I> can also be driven with command-line arguments for specific session configurations or automation. It serves as a robust alternative to traditional X11 forwarding, VNC, or RDP for those prioritizing performance and security.


title: CAVEATS
content:
<I>nxplayer</I> is part of the proprietary NoMachine software suite, not a standard open-source utility bundled with most Linux distributions. Installation requires downloading the NoMachine package from their official website. While robust, its functionality is tightly coupled with the NoMachine server software. Command-line usage for complex scenarios can be extensive, and the primary mode of interaction for most users is via its intuitive graphical interface. Providing sensitive information like passwords directly on the command line is generally discouraged due to security risks.


title: SESSION FILES (.NXS)
content:
<I>nxplayer</I> often uses `.nxs` files to store connection configurations. These XML-based files can be created and managed through the GUI, or manually edited for advanced settings. They encapsulate details like the remote host, port, authentication methods, display settings, and redirected devices, simplifying the process of re-connecting to frequently used sessions.


title: GUI-CENTRIC OPERATION
content:
While <I>nxplayer</I> accepts command-line arguments, its primary design emphasizes a rich graphical user interface. The GUI provides an intuitive way to discover servers, create and manage sessions, configure advanced options, and interact with features like file transfers and device redirection, making it highly accessible for users who prefer visual interaction over command-line scripting.


title: HISTORY
content:
The NX technology was originally developed by <I>NoMachine</I>. Early versions gained significant traction through the <I>FreeNX</I> project, an open-source implementation of the NX server, and <I>NXClient</I> which was also provided by NoMachine. This period saw widespread adoption, particularly on Linux, due to its superior performance over VNC. Over time, NoMachine shifted its focus more towards its proprietary solutions, and while the core technology evolved, the open-source FreeNX project became less actively maintained. The modern <I>nxplayer</I> command represents the evolution of the official NoMachine client, offering enhanced features, broader platform support, and tighter integration within the NoMachine ecosystem.


title: PARAMETERS
content:
<b><i>&lt;protocol&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network protocol to use (e.g., <b>smb</b>, <b>winrm</b>, <b>mssql</b>, <b>ldap</b>, <b>ssh</b>, <b>rdp</b>, <b>wmi</b>).<br><br><b><i>&lt;target(s)&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more target specifications: IP addresses, CIDR ranges, hostnames, or a file containing targets (e.g., <b>-f targets.txt</b>).<br><br><b><b>-u &lt;USERNAME&gt;, --username &lt;USERNAME&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Username or a file containing a list of usernames for authentication.<br><br><b><b>-p &lt;PASSWORD&gt;, --password &lt;PASSWORD&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Password or a file containing a list of passwords for authentication.<br><br><b><b>--hashes &lt;LM:NT&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;NTLM hashes for authentication (LM hash is optional).<br><br><b><b>-d &lt;DOMAIN&gt;, --domain &lt;DOMAIN&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the domain name for authentication.<br><br><b><b>--local-auth</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses local authentication on targets, bypassing domain authentication.<br><br><b><b>--module &lt;MODULE&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a module to load and execute against the targets. Use <b>--list-modules</b> to see available modules.<br><br><b><b>--list-modules</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available <i>nxc</i> modules and their descriptions.<br><br><b><b>-x &lt;COMMAND&gt;, --exec-shell &lt;COMMAND&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute an arbitrary command on the target system using the selected protocol's execution method.<br><br><b><b>--shares</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate accessible SMB shares on the target(s).<br><br><b><b>--users</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate domain users from the target(s).<br><br><b><b>--groups</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate domain groups from the target(s).<br><br><b><b>-v, --verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, providing more detailed information during execution.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output, showing internal workings and errors for troubleshooting.<br><br>


title: DESCRIPTION
content:
<i>nxc</i> (NetExec, formerly <i>CrackMapExec</i>) is a comprehensive post-exploitation tool designed for penetration testers and red teamers. It automates the assessment and exploitation of large Windows Active Directory environments. <i>nxc</i> leverages various protocols like SMB, WinRM, MSSQL, LDAP, and SSH to discover active hosts, enumerate shares, identify vulnerable configurations, and facilitate lateral movement.<br><br>Its capabilities include credential dumping, executing commands, interacting with various services, and performing sophisticated attacks such as Pass-the-Hash, Pass-the-Ticket, and Kerberoasting. The tool is known for its modular design, allowing users to extend its functionality with custom modules. <i>nxc</i> aims to simplify and accelerate post-exploitation activities, making it an indispensable asset for evaluating the security posture of Windows networks. It's written in Python and is highly configurable.


title: CAVEATS
content:
<i>nxc</i> requires Python 3 to run. It can be noisy on networks and potentially trigger alerts on security solutions (EDR/AV), depending on the techniques used. It is a powerful penetration testing tool and should only be used on systems with explicit authorization, as misuse is illegal. Its extensive functionality necessitates a good understanding of Windows networking and security concepts for effective and responsible usage.


title: MODULES
content:
A core strength of <i>nxc</i> is its modular architecture. Users can leverage a vast array of built-in modules or develop custom ones to extend its capabilities. Modules enable diverse actions, including credential dumping, privilege escalation checks, specific vulnerability exploitation, and advanced enumeration, allowing for highly targeted post-exploitation activities.


title: PROTOCOL SUPPORT
content:
Beyond its primary focus on SMB, <i>nxc</i> offers robust support for multiple network protocols. This includes WinRM, MSSQL, LDAP, SSH, RDP, and WMI. This broad protocol support allows <i>nxc</i> to interact with various services and systems, making it a versatile tool for comprehensive network assessments, not limited to traditional Windows file sharing.


title: INSTALLATION
content:
<i>nxc</i> is not typically included in standard Linux distribution repositories. It is most commonly installed via Python's package installer, <b>pip</b> (e.g., <b>pip install nxc</b>), or by cloning its official GitHub repository and running the setup script. This allows users to easily get the latest version and contribute to its development.


title: HISTORY
content:
<i>nxc</i> is the spiritual successor and rewritten version of the popular post-exploitation tool <i>CrackMapExec</i> (CME). <i>CrackMapExec</i> was initially developed by @byt3bl33d3r and quickly became a staple for Active Directory assessments. Over time, to address technical debt, improve performance, ensure better Python 3 compatibility, and enhance modularity, a community effort led to a major rewrite, culminating in <i>NetExec</i> (<i>nxc</i>). This rewrite builds upon CME's strong foundation, maintaining its core functionality while introducing significant improvements. <i>nxc</i> continues to be actively developed and is widely adopted by penetration testers for its efficiency in Windows network exploitation.


title: SYNOPSIS
content:
<b>nxc</b> <b>ftp</b> <I>target(s)</I> [<i>protocol_options</i>] [<i>authentication_options</i>] [<i>general_options</i>]<br><br>Examples:<br><i>nxc ftp 192.168.1.100</i><br><i>nxc ftp 192.168.1.0/24 --module ftp_anon_enum</i><br><i>nxc ftp targets.txt --users user.txt --passwords pass.txt</i>


title: PARAMETERS
content:
<b><I>target(s)</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;IP address(es), CIDR range(s), hostnames, or a file containing targets specified with <b>--targets-file</b>. This is the primary input for which systems to audit.<br><br><b>--targets-file <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file containing a list of targets (one per line) to be scanned.<br><br><b>--port <I>PORT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom FTP port to connect to, overriding the default port 21.<br><br><b>--anonymous</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly attempt an anonymous FTP login. This is often the default behavior if no other authentication is provided.<br><br><b>--users <I>USERS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a username or a path to a file containing a list of usernames to attempt for authentication.<br><br><b>--passwords <I>PASSWORDS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a password or a path to a file containing a list of passwords to attempt for authentication. Often used in conjunction with <b>--users</b> for bruteforcing.<br><br><b>--no-bruteforce</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable brute-forcing attempts. Useful when only testing anonymous access or provided credentials.<br><br><b>--module <I>MODULE_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specific <b>NetExec</b> module against the target(s) via the FTP protocol. Use <b>--list-modules</b> to see available options for FTP.<br><br><b>--list-modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available <b>NetExec</b> modules that can be run against FTP services.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity of output, showing more details about the ongoing scan and findings.<br><br><b>--output <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the command's output to a specified file.<br><br><b>--lootdir <I>DIRECTORY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a directory to store collected loot (e.g., credentials, files) from successful operations.<br><br>


title: DESCRIPTION
content:
The <b>nxc-ftp</b> command is a module within the powerful <b>NetExec</b> (formerly CrackMapExec) security auditing tool. It is designed to interact with File Transfer Protocol (FTP) services on target systems, primarily for enumeration and vulnerability assessment during penetration testing engagements. Unlike a standard FTP client, <b>nxc-ftp</b> focuses on identifying common misconfigurations, such as anonymous login availability, and can be used to execute specialized <b>NetExec</b> modules against accessible FTP services. It simplifies the process of scanning multiple targets and can be integrated into broader security assessments to discover exploitable FTP endpoints.


title: CAVEATS
content:
<b>nxc-ftp</b> is a powerful penetration testing tool. It should only be used on systems for which you have explicit permission to test. Unauthorized use against any system is illegal and unethical. The success of its operations depends heavily on the target's network configuration and the specific FTP server implementation. Firewall rules, IDS/IPS systems, and strong security configurations can limit its effectiveness.


title: MODULE-BASED FUNCTIONALITY
content:
One of <b>nxc-ftp</b>'s key strengths is its ability to execute specialized <b>NetExec</b> modules. While the base command can test for anonymous access, modules provide more in-depth functionality, such as enumerating directories, identifying specific server versions, or attempting to exploit known vulnerabilities through the FTP protocol. This modularity makes <b>nxc-ftp</b> highly extensible for various testing scenarios.


title: INTEGRATION WITH NETEXEC WORKFLOW
content:
As part of the <b>NetExec</b> suite, <b>nxc-ftp</b> seamlessly integrates with other protocol modules (e.g., SMB, WinRM, SSH). This allows security professionals to use a consistent command-line interface and shared credential/target management across different network services, streamlining multi-protocol auditing and penetration testing workflows.


title: HISTORY
content:
The <b>nxc-ftp</b> command is an integral part of <b>NetExec</b>, a successor to the highly popular <b>CrackMapExec</b> (CME) tool. CrackMapExec itself evolved from prior security tools, aiming to consolidate and improve on post-exploitation and enumeration techniques for various network protocols. <b>NetExec</b>'s development continues this trajectory, providing a unified framework for pentesters. The FTP module specifically was developed to address the need for efficient and automated enumeration and exploitation of FTP services within this comprehensive toolkit, allowing users to leverage common NetExec features like module execution and credential management against FTP targets.


title: SYNOPSIS
content:
nxc ldap <I>TARGETS</I> [OPTIONS]<br><br><I>TARGETS</I> can be a single IP address, a comma-separated list of IPs, a CIDR range, a hostname, or a path to a file containing a list of targets.


title: PARAMETERS
content:
<b>--users</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate domain users.<br><br><b>--groups</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate domain groups.<br><br><b>--computers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate domain computers.<br><br><b>--asreproast</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to perform AS-REP Roasting against eligible user accounts.<br><br><b>--kerberoast</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to perform Kerberoasting against eligible Service Principal Names (SPNs).<br><br><b>--gpp-passwords</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for Group Policy Preferences (GPP) XML files with stored passwords.<br><br><b>--bloodhound</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps data for ingestion into BloodHound for attack path analysis.<br><br><b>--laps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to dump LAPS (Local Administrator Password Solution) passwords if permissions allow.<br><br><b>--rid-brute <I>START_RID</I> <I>END_RID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Brute forces RID numbers to find valid accounts within a specified range.<br><br><b>-u <I>USERNAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for authentication.<br><br><b>-p <I>PASSWORD</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the password for authentication.<br><br><b>-H <I>HASH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an NTLM hash for pass-the-hash authentication.<br><br><b>-d <I>DOMAIN</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the domain name for authentication.<br><br><b>--no-bruteforce</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>nxc</b> from attempting to brute force credentials (useful with provided credentials).<br><br><b>--continue-on-success</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues enumeration and exploitation attempts even after successful authentication or initial compromise.<br><br><b>--threads <I>NUM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of concurrent threads to use for operations.<br><br>


title: DESCRIPTION
content:
<b>nxc-ldap</b> is a module of NetExec (formerly CrackMapExec, or CME), a powerful post-exploitation framework designed for penetration testers. It specializes in interacting with LDAP (Lightweight Directory Access Protocol) services, primarily found in Active Directory environments. This module allows security professionals to enumerate various Active Directory objects such as users, groups, and computers, identify misconfigurations, and exploit vulnerabilities like AS-REP Roasting or Kerberoasting to gain credentials or further insights into the domain.<br><br><b>nxc-ldap</b> is used for reconnaissance, privilege escalation, and lateral movement within Windows domains by leveraging authenticated and unauthenticated LDAP queries. It streamlines the process of gathering critical domain information, making it an indispensable tool for AD security assessments.


title: CAVEATS
content:
<ul><li><b>Ethical Use:</b> <b>nxc-ldap</b> is a powerful tool designed for authorized security assessments. Unauthorized use against any system is illegal and unethical.</li><li><b>Network Impact:</b> Enumeration and exploitation activities can generate significant network traffic and potentially trigger security alerts or IPS/IDS systems.</li><li><b>Permissions:</b> Many advanced features (e.g., LAPS dumping, sensitive attribute enumeration) require specific elevated permissions within the Active Directory domain.</li><li><b>Dependency:</b> Requires Python and the NetExec framework to be installed.</li></ul>


title: AUTHENTICATION METHODS
content:
<b>nxc-ldap</b> supports various authentication methods, including username/password, NTLM hashes (pass-the-hash), and unauthenticated access for specific queries. This flexibility is crucial for different testing scenarios.


title: INTEGRATION WITH OTHER MODULES
content:
While <b>nxc-ldap</b> focuses on LDAP, <b>nxc</b> itself is modular, allowing seamless integration with other protocols like SMB, WinRM, and RDP for a comprehensive assessment.


title: HISTORY
content:
<b>nxc</b> (NetExec) is the successor to <b>CrackMapExec</b> (CME), a popular penetration testing tool initially developed by @byt3bl33d3r. CME gained significant traction for its versatile capabilities in enumerating and exploiting various network services, especially within Windows domains. The transition to NetExec (NXC) aimed to address maintenance issues and community support, continuing its legacy as a go-to tool for red teamers and pentesters. The <b>ldap</b> module has been a core component since its early days, continuously updated to include new attack techniques and enumeration methods relevant to Active Directory security.


title: SYNOPSIS
content:
<b>nxc mssql</b> <I>target(s)</I> [<I>options</I>]<br><b>nxc mssql</b> <I>-L</I> <I>target_list_file</I> [<I>options</I>]<br><b>nxc mssql</b> <I>192.168.1.0/24</I> <I>-u</I> <I>user</I> <I>-p</I> <I>password</I> <I>--enumerate-sql</I>


title: PARAMETERS
content:
<b>target(s)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>IP addresses, hostnames, CIDR ranges, or a file containing targets.</I><br><br><b><b>-L</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>File containing a list of targets.</I><br><br><b><b>-u</b>, <b>--username</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Username(s) or a file containing usernames.</I><br><br><b><b>-p</b>, <b>--password</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Password(s) or a file containing passwords.</I><br><br><b><b>-H</b>, <b>--hashes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>NTLM hashes (e.g., LM:NT or :NT).</I><br><br><b><b>--pass-the-hash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Shorthand for using `-H` with current user context.</I><br><br><b><b>--port</b> <I>PORT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify a custom SQL Server port (default 1433).</I><br><br><b><b>--local-auth</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Authenticate using local accounts instead of domain accounts.</I><br><br><b><b>--enumerate-sql</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enumerate various SQL Server details including users, databases, and version.</I><br><br><b><b>--xpcmdshell</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Attempts to enable and use xp_cmdshell for command execution.</I><br><br><b><b>--enable-xp_cmdshell</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enables xp_cmdshell on the target server.</I><br><br><b><b>--disable-xp_cmdshell</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Disables xp_cmdshell on the target server.</I><br><br><b><b>--mssql-query</b> <I>QUERY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Executes an arbitrary SQL query on the target.</I><br><br><b><b>--query-exec</b> <I>COMMAND</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Executes a command via xp_cmdshell or sp_oacreate.</I><br><br><b><b>--get-info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Retrieves SQL Server instance information.</I><br><br><b><b>--get-users</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enumerates SQL database users.</I><br><br><b><b>--get-databases</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enumerates SQL databases.</I><br><br><b><b>--get-links</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enumerates linked servers.</I><br><br>


title: DESCRIPTION
content:
<b>nxc-mssql</b> is a potent module within the NetExec (formerly CrackMapExec) framework, specifically engineered for auditing and exploiting Microsoft SQL Server instances. Its primary role is to assist penetration testers and security auditors in discovering and leveraging vulnerabilities. The module streamlines various reconnaissance and post-exploitation tasks, including comprehensive credential testing against SQL logins, in-depth enumeration of databases, users, and linked servers, and crucially, remote command execution on compromised SQL Server hosts. It boasts support for diverse authentication methods, such as cleartext username/password, NTLM hashes for pass-the-hash scenarios, and integrated Windows authentication. Security professionals extensively employ <b>nxc-mssql</b> to pinpoint common misconfigurations, weak credentials, and potential command execution flaws, often leveraging powerful features like xp_cmdshell or sp_oacreate to gain deeper access within target environments. Its capabilities make it an indispensable tool for assessing the security posture of SQL Server deployments.


title: CAVEATS
content:
<b>nxc-mssql</b> is a penetration testing tool and should only be used on systems you have explicit permission to test. Unauthorized use is illegal and unethical.<br>Using this tool can generate significant network traffic and leave forensic artifacts, potentially triggering security alerts or defensive measures.<br>Certain actions, like enabling <i>xp_cmdshell</i>, modify the target system's configuration.<br>Effectiveness depends on proper network connectivity, target configuration, and available credentials.


title: AUTHENTICATION METHODS
content:
Supports various authentication methods including cleartext username/password, NTLM hash-based authentication (pass-the-hash), and integrated Windows authentication where applicable. This flexibility allows testers to leverage different types of compromised credentials.


title: PRIVILEGE ESCALATION & COMMAND EXECUTION
content:
One of its key features is the ability to enable and utilize <i>xp_cmdshell</i> or <i>sp_oacreate</i> to execute arbitrary operating system commands on the SQL Server host. This capability is crucial for gaining initial access or escalating privileges on the underlying Windows machine.


title: HISTORY
content:
NetExec (nxc) is the successor to <i>CrackMapExec</i> (CME), a popular open-source post-exploitation tool. It was rebranded and rewritten to improve performance, maintainability, and expand its capabilities. The <b>mssql</b> module has been a core component, evolving with new features and exploitation techniques for Microsoft SQL Server, reflecting common vulnerabilities and attack paths identified in enterprise environments. Its development continues to be community-driven, adapting to new Windows and SQL Server versions.


title: PARAMETERS
content:
<b><I>target(s)</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more targets specified as an IP address, CIDR range (e.g., 192.168.1.0/24), hostname, or a path to a file containing a list of targets.<br><br><b>--shares</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all exported NFS shares on the target(s) and displays their respective options. This is the primary enumeration option.<br><br><b>--port <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the NFS port to connect to. Defaults to 2049.<br><br><b>--rpc-port <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the RPC port (portmapper) to connect to. Defaults to 111.<br><br><b>--show-versions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the supported NFS versions on the target system.<br><br><b>--show-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows additional NFS server information, often including mount points and other details.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity of output, showing more details about the operations.<br><br><b>--threads <threads></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of concurrent threads to use for scanning multiple targets. Defaults to 10.<br><br><b>--timeout <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the connection timeout in seconds for target hosts. Defaults to 20.<br><br>


title: DESCRIPTION
content:
<i>nxc-nfs</i> is a module within the <I>NetExec</I> (formerly <I>CrackMapExec</I>) framework, a powerful post-exploitation tool primarily used by penetration testers for auditing large networks. While NetExec is best known for its Windows/SMB/Active Directory capabilities, the <I>nfs</I> module specifically targets Network File System (NFS) services.<br><br>This module allows users to enumerate NFS exports on target systems, identify accessible shares, and gather information that could potentially lead to unauthorized access or data exposure. It's commonly used to discover weakly configured NFS shares, such as those with anonymous access (no_root_squash, insecure shares) or wide-open permissions, which are common vulnerabilities in network environments. It helps security professionals quickly assess the security posture of NFS implementations.


title: CAVEATS
content:
The `nxc-nfs` command is not a standalone Linux utility but a module within the `netexec` framework. It requires NetExec to be installed. It is primarily a penetration testing and security auditing tool; improper use may lead to unauthorized access or disruption of services. Always ensure you have explicit authorization before scanning any network or system.


title: INSTALLATION AND USAGE
content:
To use `nxc nfs`, NetExec must first be installed. It can typically be installed via `pipx install nxc` or through package managers like `apt` (for Kali Linux) if available. After installation, the common usage pattern is `nxc nfs <IP_address> --shares` to quickly enumerate available NFS shares.


title: SECURITY IMPLICATIONS
content:
NFS shares, if misconfigured (e.g., world-readable, no_root_squash, or exported to untrusted networks), can pose significant security risks. `nxc nfs` is instrumental in identifying these misconfigurations, allowing administrators to secure their environments before they are exploited by malicious actors.


title: HISTORY
content:
The `nxc` (NetExec) tool evolved from `CrackMapExec` (CME), a widely used penetration testing framework. The NFS module was integrated to provide comprehensive network service auditing capabilities beyond its initial focus on SMB/AD. Its development is community-driven, continually adding new modules and features to address various network protocols and vulnerabilities, including NFS.


title: PARAMETERS
content:
<b><i>&lt;target(s)&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more targets specified as IP addresses, CIDR ranges, hostnames, or a path to a file containing targets.<br>Example: '192.168.1.1', '192.168.1.0/24', 'target.txt'.<br><br><b><b>-u</b> <i>&lt;USERNAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Single username for authentication.<br><br><b><b>-p</b> <i>&lt;PASSWORD&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Single password for authentication. If omitted with <b>-u</b>, a blank password will be used.<br><br><b><b>-H</b> <i>&lt;HASH&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;NTLM hash for authentication (e.g., 'aad3b435b514a04eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0').<br><br><b><b>-L</b> <i>&lt;USER_FILE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of usernames to try.<br><br><b><b>-P</b> <i>&lt;PASS_FILE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of passwords to try.<br><br><b><b>--local-auth</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces authentication using local accounts, bypassing domain authentication where applicable.<br><br><b><b>--enum-rdp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerates various RDP details such as RDP version, NLA status, certificate information, and more.<br><br><b><b>--screenshot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to take a screenshot of the RDP login screen. Requires Xvfb and imagemagick to be installed.<br><br><b><b>--threads</b> <i>&lt;THREADS&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of concurrent threads to use for scanning/attacking targets. Default is 10.<br><br><b><b>--timeout</b> <i>&lt;SECONDS&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connection timeout in seconds.<br><br>


title: DESCRIPTION
content:
<i>nxc rdp</i> is a module of the NetExec (formerly CrackMapExec) post-exploitation tool, specialized in interacting with Remote Desktop Protocol (RDP) services. It's primarily used for network enumeration and assessing RDP endpoint security. This module can discover RDP service configurations, check for Network Level Authentication (NLA) status, and attempt credential-based login attempts using various authentication methods. It helps penetration testers gather intelligence about RDP environments, identify misconfigurations, and validate access through available credentials or hashes. It can also perform advanced actions like taking screenshots of RDP login screens.


title: CAVEATS
content:
Usage of <i>nxc rdp</i> requires the NetExec framework to be installed. Certain advanced features, such as screenshotting, depend on additional system utilities like <i>Xvfb</i> and <i>imagemagick</i>. Be aware that extensive scanning or brute-force attempts can generate significant network traffic and may trigger intrusion detection/prevention systems (IDS/IPS). Unauthorized access attempts are illegal.


title: AUTHENTICATION FLEXIBILITY
content:
The module supports various authentication methods, including plaintext usernames and passwords, NTLM hashes, and the ability to specify user and password lists for brute-forcing or dictionary attacks. This makes it highly versatile for leveraging different types of compromised credentials.


title: INFORMATION GATHERING
content:
Beyond basic enumeration, <i>nxc rdp</i> can provide valuable insights into the RDP service's configuration, including whether Network Level Authentication (NLA) is enabled or disabled, which significantly impacts the attack surface. This information is crucial for planning further exploitation steps.


title: HISTORY
content:
<i>nxc rdp</i> is an integral module of <b>NetExec</b>, which is the community-maintained fork and successor to the widely popular <b>CrackMapExec (CME)</b> tool. CME initially gained prominence for its versatile capabilities in Active Directory and Windows network post-exploitation. The RDP module has been consistently developed alongside the main project, adapting to new RDP features and security mechanisms, ensuring its relevance for modern penetration testing scenarios.


title: SYNOPSIS
content:
<i><b>nxc smb</b></i> &lt;<i>target</i>&gt; [<i>authentication_options</i>] [<i>module_or_enumeration_options</i>] [<i>general_options</i>]<br><br><b>Examples:</b><br><i><b>nxc smb</b></i> 192.168.1.0/24 -u user -p pass --shares<br><i><b>nxc smb</b></i> 10.0.0.5 -u Administrator -H AABBCCDDEEFF00112233445566778899 --module secretsdump<br><i><b>nxc smb</b></i> @targets.txt --local-auth --exec-method smbexec -x "whoami"


title: PARAMETERS
content:
<b>&lt;<i>target</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target host(s). Can be an IP address, CIDR range (e.g., 192.168.1.0/24), IP range (e.g., 192.168.1.1-254), or a file containing a list of targets (e.g., @targets.txt).<br><br><b>-u &lt;<i>USERNAME</i>&gt;, --user &lt;<i>USERNAME</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Username(s) to authenticate with. Can be a single user or a comma-separated list.<br><br><b>-p &lt;<i>PASSWORD</i>&gt;, --password &lt;<i>PASSWORD</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Password(s) for authentication. Can be a single password or a comma-separated list.<br><br><b>-H &lt;<i>HASH</i>&gt;, --hash &lt;<i>HASH</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;NTLM hash(es) for pass-the-hash authentication.<br><br><b>--local-auth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt authentication as a local user account on the target system.<br><br><b>-M &lt;<i>MODULE</i>&gt;, --module &lt;<i>MODULE</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run a specific module against the target(s). Use <i><b>nxc smb --list-modules</b></i> to see available modules.<br><br><b>-o &lt;<i>OPTIONS</i>&gt;, --options &lt;<i>OPTIONS</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide specific options for a selected module. Format is KEY=VALUE,KEY2=VALUE2.<br><br><b>--shares</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate accessible SMB shares and their permissions.<br><br><b>--users</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate users via SAMR (Security Account Manager Remote protocol).<br><br><b>--sessions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate active sessions on the target system.<br><br><b>--loggedon-users</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate users currently logged on to the target system via NetWkstaUserEnum.<br><br><b>--pass-pol</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieve the password policy of the target system.<br><br><b>--exec-method &lt;<i>METHOD</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the command execution method (e.g., <i>psexec</i>, <i>wmi</i>, <i>smbexec</i>).<br><br><b>-x &lt;<i>COMMAND</i>&gt;, --exec &lt;<i>COMMAND</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specified command on the target system using the chosen execution method.<br><br><b>--no-pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt authentication with a blank password.<br><br><b>--continue-on-success</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not stop after finding valid credentials for a target. Continue trying other credentials/modules.<br><br>


title: DESCRIPTION
content:
<i><b>nxc-smb</b></i> refers to the Server Message Block (SMB) protocol module within the <b>NetExec</b> (<i>nxc</i>) framework. NetExec, a successor to <i>CrackMapExec (CME)</i>, is a versatile post-exploitation tool designed for network enumeration and exploitation, primarily targeting Windows environments over various protocols.<br><br>The <i><b>nxc smb</b></i> module allows penetration testers and security professionals to interact with SMB services on remote hosts. Its capabilities include, but are not limited to, enumerating accessible shares, users, sessions, and group memberships; dumping password hashes (e.g., LAPS); executing commands remotely via methods like PsExec, WMI, or SmbExec; and performing credential attacks such as pass-the-hash or credential spraying.<br><br>It provides a streamlined way to automate many common post-exploitation tasks, making it highly effective for lateral movement and privilege escalation on Windows networks. Users can specify target hosts, provide credentials (usernames, passwords, NTLM hashes), and select various built-in modules or custom scripts to perform specific actions against SMB services.


title: CAVEATS
content:
<i><b>nxc-smb</b></i> is a powerful tool designed for legitimate penetration testing and ethical hacking. Unauthorized use against systems you do not have explicit permission to test is illegal and unethical. It can generate significant network traffic, potentially triggering Intrusion Detection/Prevention Systems (IDS/IPS) and creating logs. Some features might require elevated privileges on the attacking machine, and success is dependent on the target's network configuration and security posture.


title: INSTALLATION
content:
<i><b>NetExec</b></i> can typically be installed using <i>pipx</i>, which manages applications in isolated environments:<br><i>pipx install nxc</i><br>Alternatively, it might be available through your Linux distribution's package manager or can be installed directly from its GitHub repository.


title: MODULE SYSTEM
content:
A core strength of <i><b>nxc-smb</b></i> (and <i>nxc</i> in general) is its modular design. Users can load and execute various Python scripts (modules) to perform specific tasks. These modules range from information gathering (e.g., enumerating LAPS passwords) to highly targeted exploits or post-exploitation activities. New modules can be easily created and integrated, extending the tool's capabilities. Use <i><b>nxc smb --list-modules</b></i> to see all available SMB modules.


title: HISTORY
content:
<i><b>NetExec</b></i> (<i>nxc</i>) emerged as a spiritual successor and active fork of the popular <i><b>CrackMapExec</b></i> (<i>CME</i>) framework, originally developed by byt3bl33d3r. As CME's development slowed, a need arose for continued maintenance and feature expansion within the community. <i>nxc</i> aims to provide a robust, up-to-date, and actively maintained tool for network enumeration and exploitation, building upon CME's strong foundation while introducing new features and improvements. It remains written in Python, leveraging various libraries for its diverse protocol support.


title: SEE ALSO
content:
<i>crackmapexec(1)</i>, <i>impacket(1)</i> (suite of tools, e.g., <i>psexec.py</i>, <i>smbclient.py</i>), <i>smbclient(1)</i>, <i>enum4linux(1)</i>, <i>nmap(1)</i>


title: SYNOPSIS
content:
<b>nxc ssh</b> &lt;target(s)&gt; [options]<br><br><b>Examples:</b><br>&nbsp;&nbsp;nxc ssh 192.168.1.10 -u admin -p password<br>&nbsp;&nbsp;nxc ssh 192.168.1.0/24 --user-file users.txt --pass-file passwords.txt<br>&nbsp;&nbsp;nxc ssh servers.txt --key-file ~/.ssh/id_rsa -x "uname -a"


title: PARAMETERS
content:
<b>&lt;target(s)&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target(s) for the SSH module. This can be a single IP address, a CIDR range (e.g., 192.168.1.0/24), a hostname, or a path to a file containing a list of targets.<br><br><b>-u &lt;USERNAME&gt;, --username &lt;USERNAME&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a single username for authentication. Can be combined with a single password or a password file.<br><br><b>-p &lt;PASSWORD&gt;, --password &lt;PASSWORD&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a single password for authentication. Can be combined with a single username or a username file.<br><br><b>--user-file &lt;FILE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of usernames, one per line. Used for password spraying or bruteforcing.<br><br><b>--pass-file &lt;FILE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of passwords, one per line. Used for password spraying or bruteforcing.<br><br><b>--key-file &lt;FILE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to an SSH private key file for key-based authentication. Can be used instead of or in conjunction with username/password.<br><br><b>-M &lt;MODULE_NAME&gt;, --module &lt;MODULE_NAME&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an SSH module to run after successful authentication. Modules perform various post-exploitation tasks (e.g., 'enum_sudo', 'get_users').<br><br><b>-x &lt;COMMAND&gt;, --execute &lt;COMMAND&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a shell command on the target system upon successful authentication. The command output will be displayed.<br><br><b>--port &lt;PORT&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom SSH port to connect to, if it's not the default (22).<br><br><b>--no-bruteforce</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the bruteforce process if credentials are provided via -u/-p or files. Only attempts the specified credentials.<br><br><b>--threads &lt;THREADS&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of concurrent threads to use, affecting the speed of scanning and attacks. Default is often 10.<br><br><b>--timeout &lt;SECONDS&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout for connection attempts in seconds.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the scanning and attack process.<br><br>


title: DESCRIPTION
content:
<i>nxc-ssh</i> is the SSH protocol module of the powerful <i>NetExec</i> (nxc) framework, a successor to <i>CrackMapExec</i> (CME). It's designed for efficient network reconnaissance, authentication testing, and post-exploitation against SSH services.<br><br><i>nxc-ssh</i> facilitates tasks such as password spraying, bruteforcing credentials, enumerating users, and executing arbitrary commands on targeted Linux/Unix systems. It supports various authentication methods including username/password pairs, password lists, username lists, and SSH private keys. Its modular design allows users to leverage specific functionalities for tasks like privilege escalation enumeration or data collection.<br><br>This tool is widely used by penetration testers and red teamers to automate aspects of their assessments.


title: CAVEATS
content:
Using <i>nxc-ssh</i> for unauthorized access is illegal and unethical. Ensure you have explicit permission before using this tool against any system you do not own or are not authorized to test. It can be noisy on the network, potentially triggering intrusion detection systems (IDS) or logging mechanisms. Network connectivity issues, firewalls, and SSH server configurations (e.g., rate limiting, strict modes) can prevent successful operations.


title: USING MODULES AND COMMAND EXECUTION
content:
<i>nxc-ssh</i> offers a flexible way to extend its functionality through modules. These modules, specified with the <i>-M</i> or <i>--module</i> flag, can perform various post-authentication tasks, such as enumerating sudo privileges ('enum_sudo') or extracting system information ('get_users').<br><br>Additionally, the <i>-x</i> or <i>--execute</i> flag allows for direct execution of shell commands on the target system upon successful authentication, making it a powerful tool for rapid command execution during an engagement. This is often used to confirm access, gather quick intelligence, or deploy further tools.


title: HISTORY
content:
<i>NetExec</i> (nxc) is the actively maintained successor to <i>CrackMapExec</i> (CME). <i>CME</i> was originally developed by @byt3bl33d3r and gained significant popularity for its comprehensive post-exploitation capabilities, primarily targeting Windows SMB and other services. Over time, the community-driven <i>NetExec</i> project emerged, continuing the development, adding new features, improving performance, and expanding protocol support, including a robust SSH module, addressing the evolving needs of network security assessments.


title: SYNOPSIS
content:
<code>nxc vnc &lt;target(s)&gt; [authentication_options] [vnc_module_options]</code><br><br>Where <code>&lt;target(s)&gt;</code> can be:<br>&nbsp;&nbsp;<code>IP_ADDRESS</code> (e.g., 192.168.1.10)<br>&nbsp;&nbsp;<code>IP_RANGE</code> (e.g., 192.168.1.0/24)<br>&nbsp;&nbsp;<code>HOSTNAME</code><br>&nbsp;&nbsp;<code>FILENAME</code> (a file containing a list of targets)<br>&nbsp;&nbsp;<code>all</code> (all hosts discovered within the specified scope)


title: PARAMETERS
content:
<b>--username <user></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Username to authenticate with on the target system.<br><br><b>--password <pass></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Password to authenticate with on the target system.<br><br><b>--hash <hash></b><br>&nbsp;&nbsp;&nbsp;&nbsp;NTLM hash to authenticate with (LM:NTLM format).<br><br><b>--no-pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates with an empty password.<br><br><b>--local-auth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces local authentication on the target system (not domain).<br><br><b>--vnc-port <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the VNC service port (default is 5900).<br><br><b>--vnc-dump-hash</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to dump VNC authentication hashes from the target.<br><br><b>--vnc-screenshot <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Takes a screenshot of the VNC desktop and saves it to the specified local path.<br><br><b>--vnc-password <password></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the VNC password directly for VNC authentication (separate from Windows/SMB authentication).<br><br><b>--vnc-connect</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to connect to the VNC service. This is often an implicit action if no other VNC-specific action (like dumping hash or screenshot) is specified.<br><br>


title: DESCRIPTION
content:
<code>nxc-vnc</code> is not a standalone command but a specific module within the <i>NetExec</i> (<code>nxc</code>) framework, a powerful post-exploitation tool primarily used in network security assessments, penetration testing, and red teaming operations. This module focuses on interacting with VNC (Virtual Network Computing) services found on target systems. It allows security professionals to enumerate VNC servers, attempt authentication, dump VNC authentication hashes (typically NTLMv1 or NTLMv2 hashes if VNC is configured to use Windows authentication), and even capture screenshots of the remote VNC session. The <code>nxc vnc</code> module leverages <i>NetExec</i>'s capabilities to authenticate against target systems (e.g., via SMB/RPC) and then, if successful, attempts to interact with VNC services. Its primary use cases include reconnaissance, credential harvesting, and visual verification of VNC access on compromised or vulnerable systems within an enterprise network. It streamlines the process of assessing VNC security posture across multiple hosts.


title: CAVEATS
content:
<code>nxc-vnc</code> is a module of the <i>NetExec</i> framework and requires <i>NetExec</i> to be installed. Successful interaction relies on network connectivity to the target's VNC service and valid authentication credentials. Usage without explicit authorization is illegal and unethical. This tool is intended for legitimate security assessments and penetration testing. Some functionalities, particularly screenshot capture, may require additional Python dependencies (e.g., <code>vncdotool</code>) to be installed.


title: USAGE EXAMPLES
content:
<code>nxc vnc 192.168.1.10 --username administrator --password 'P@ssw0rd1' --vnc-dump-hash</code><br><i>Description:</i> Dumps VNC hashes from a single target using specified credentials.<br><br><code>nxc vnc 192.168.1.0/24 --local-auth --vnc-screenshot /tmp/vnc_screens/</code><br><i>Description:</i> Takes screenshots from all VNC services in the subnet, authenticating locally and saving to a directory.<br><br><code>nxc vnc hosts.txt --vnc-password 'vncpass' --vnc-connect</code><br><i>Description:</i> Connects to VNC services listed in <code>hosts.txt</code> using a direct VNC password.


title: HISTORY
content:
The <code>nxc</code> framework, of which <code>vnc</code> is a module, was originally known as <i>CrackMapExec</i> (<code>CME</code>), developed by @byt3bl33d3r. It gained significant popularity in the cybersecurity community for its comprehensive suite of post-exploitation capabilities against various network protocols, especially SMB. The project was later renamed to <i>NetExec</i> (<code>nxc</code>) due to a trademark dispute. The <code>vnc</code> module was integrated into the framework to extend its reach to VNC services, offering specialized functionalities like hash dumping and screenshot capture, thereby enhancing its utility for red team operations and security assessments.


title: SEE ALSO
content:
nxc(1): The main <i>NetExec</i> command for various network protocol interactions., vncviewer(1): A generic VNC client for connecting to VNC servers., CrackMapExec(1): The previous name for <i>NetExec</i>, still widely recognized.


title: SYNOPSIS
content:
<B>nxc-winrm</B> &lt;target(s)&gt; [options]<br><br>Examples:<br><br><B>nxc-winrm</B> 192.168.1.10 <B>-u</B> user <B>-p</B> 'Password123!' <B>-M</B> whoami<br><B>nxc-winrm</B> 192.168.1.0/24 <B>--users</B> users.txt <B>--passwords</B> passwords.txt <B>--local-auth</B><br><B>nxc-winrm</B> targets.txt <B>-u</B> administrator <B>--hash</B> AAD3B435B51404EEAAD3B435B51404EE:C234F0C0F7604F43F96248C5B3208754 <B>--execute-powershell</B> 'Invoke-Mimikatz'<br><B>nxc-winrm</B> 10.0.0.0/16 <B>-M</B> enum_logged_on_users <B>--port</B> 5986 <B>--ssl</B>


title: PARAMETERS
content:
<b><target(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target(s) as IP addresses, hostname, IP ranges (e.g., 192.168.1.0/24), or a file containing targets (e.g., targets.txt).<br><br><b>-u <username>, --username <username></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the username to authenticate with.<br><br><b>-p <password>, --password <password></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the password for authentication. Can be an empty string for blank password, or ' ' to prompt.<br><br><b>--hash <LM:NT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the NTLM hash for authentication (LM:NT format). Example: AAD3B435B51404EEAAD3B435B51404EE:C234F0C0F7604F43F96248C5B3208754.<br><br><b>--aesKey <key></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Kerberos AES key for authentication (hex string).<br><br><b>-d <domain>, --domain <domain></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the domain name for authentication. Defaults to the target's domain.<br><br><b>--local-auth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces authentication against the local machine's SAM database, useful for standalone hosts or local user accounts.<br><br><b>--no-pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts authentication with a blank password for the specified username.<br><br><b>-M <module>, --module <module></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load and execute a specific WinRM module (e.g., 'whoami', 'enum_logged_on_users', 'powershell_execute').<br><br><b>--list-modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available WinRM modules and their descriptions.<br><br><b>--execute <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a raw command on the target system via WinRM. Output is returned.<br><br><b>--execute-powershell <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a PowerShell command/script on the target system via WinRM. Output is returned.<br><br><b>--port <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative WinRM port (default is 5985 for HTTP, 5986 for HTTPS).<br><br><b>--ssl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force SSL connection for WinRM (usually on port 5986).<br><br><b>--timeout <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the connection timeout in seconds (default is 10).<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show verbose output, displaying more details about the operations.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show debug output, useful for troubleshooting connection or module issues.<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output.<br><br>


title: DESCRIPTION
content:
nxc-winrm is a specialized module within the <I>NetExec</I> framework, designed for interacting with the Windows Remote Management (WinRM) service. WinRM is Microsoft's implementation of WS-Management, enabling remote administration of Windows systems. <br><br>This command allows security professionals and system administrators to enumerate, authenticate, and execute commands or modules against one or more Windows targets over the WinRM protocol. It supports various authentication methods, including plaintext credentials, NTLM hashes, and Kerberos. <br><br>Its primary use cases include: discovering active WinRM services on a network range; testing user credentials (bruteforcing or spraying) against WinRM; enumerating system information (e.g., local users, groups, installed applications); executing arbitrary commands or PowerShell scripts on remote hosts; and leveraging built-in modules for common post-exploitation tasks, such as dumping SAM/LSA hashes, creating services, or retrieving network information. <br><br><I>nxc-winrm</I> streamlines lateral movement and post-exploitation activities in Windows environments, particularly within Active Directory domains, by providing a robust and flexible interface to WinRM.


title: CAVEATS
content:
nxc-winrm relies on the WinRM service being active and configured on the target Windows system, which is not always the default. <br>Firewall rules on the target or network can block WinRM ports (5985/TCP for HTTP, 5986/TCP for HTTPS). <br>User Account Control (UAC) on newer Windows versions can restrict administrative actions, even with valid credentials, if the user is not the built-in Administrator. <br>Antivirus and EDR solutions may detect and block malicious activities initiated via WinRM, particularly PowerShell executions or module payloads. <br>Authentication issues can arise from incorrect domain/workgroup settings or network time synchronization problems for Kerberos.


title: DEFAULT PORTS
content:
WinRM typically operates on port <I>5985/TCP</I> for HTTP and <I>5986/TCP</I> for HTTPS. <I>nxc-winrm</I> defaults to 5985 but can be explicitly told to use SSL on 5986 with the <B>--ssl</B> flag.


title: MODULES
content:
<I>nxc-winrm</I>'s power is significantly extended by its modular architecture. Users can leverage existing modules (e.g., <I>whoami</I>, <I>enum_logged_on_users</I>, <I>powershell_execute</I>) or develop custom ones to perform specific enumeration, exploitation, or post-exploitation tasks. Modules are loaded using the <B>-M</B> or <B>--module</B> option.


title: HISTORY
content:
<I>NetExec</I> (<I>nxc</I>) is the spiritual successor and rebranded version of <I>CrackMapExec</I> (<I>CME</I>), a widely-used penetration testing tool. <I>CME</I> was originally developed by @byt3bl33d3r and gained significant popularity for its effectiveness in Active Directory enumeration and lateral movement. <br><br>The project was forked and rebranded to <I>NetExec</I> to address maintenance challenges, introduce new features, improve code quality, and expand its capabilities beyond its initial SMB focus. <I>nxc-winrm</I> represents the continued development of robust WinRM interaction functionalities within this powerful framework.


title: SYNOPSIS
content:
nxc smb &lt;TARGETS&gt; [-u &lt;USERNAME&gt; -p &lt;PASSWORD&gt; | -H &lt;HASH&gt;] [-d &lt;DOMAIN&gt;] [NXC_OPTIONS] -M wmi &lt;WMI_MODULE_OPTION&gt; [MODULE_ARGUMENTS]


title: PARAMETERS
content:
<b><b>--wmi-query</b> <I>WMI_QUERY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a custom WMI Query Language (WQL) query.<br><br><b><b>--wmi-namespace</b> <I>WMI_NAMESPACE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a WMI namespace for queries (default: root\cimv2).<br><br><b><b>--wmi-list-namespaces</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available WMI namespaces on the target.<br><br><b><b>--wmi-exec</b> <I>WMI_EXEC</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a WMI method on a specified class, e.g., "CLASSNAME@METHODNAME@ARG1=VAL1".<br><br><b><b>--wmi-enum-class</b> <I>WMI_ENUM_CLASS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate properties of a specified WMI class.<br><br><b><b>--wmi-enum-methods</b> <I>WMI_ENUM_METHODS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate methods of a specified WMI class.<br><br><b><b>--wmi-enum-privs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate token privileges of the authenticated user.<br><br><b><b>--wmi-enum-sessions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate active sessions on the target.<br><br><b><b>--wmi-enum-share</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate available network shares.<br><br><b><b>--wmi-enum-users</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate local users on the target system.<br><br><b><b>--wmi-enum-groups</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate local groups on the target system.<br><br><b><b>--wmi-enum-loggedon-users</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate currently logged on users.<br><br><b><b>--wmi-enum-rdp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate RDP sessions on the target.<br><br><b><b>--wmi-enum-services</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate running services on the target.<br><br><b><b>--wmi-enum-processes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate active processes on the target.<br><br><b><b>--wmi-enum-patches</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate installed patches and hotfixes.<br><br><b><b>--wmi-enum-hotfixes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate installed hotfixes.<br><br><b><b>--wmi-enum-uac</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate User Account Control (UAC) settings.<br><br><b><b>--wmi-enum-winlogon</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate Winlogon settings.<br><br><b><b>--wmi-enum-startup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate programs configured to run at startup.<br><br><b><b>--wmi-enum-dns</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate DNS client settings and entries.<br><br><b><b>--wmi-enum-software</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enumerate installed software on the target system.<br><br>


title: DESCRIPTION
content:
The "nxc-wmi" command refers to the Windows Management Instrumentation (WMI) module within the versatile <I>NetExec</I> (formerly <I>CrackMapExec</I> or <I>CME</I>) framework. It's a powerful tool designed for interacting with Windows systems remotely over the Server Message Block (SMB) protocol. WMI is a core Windows technology used for managing local and remote computers, providing a standardized way to access system information and execute management tasks.<br><br>The <I>nxc-wmi</I> module allows security professionals, penetration testers, and system administrators to perform a wide array of actions, including executing custom WMI Query Language (WQL) queries, listing WMI namespaces, enumerating classes and methods, and performing various enumeration tasks such as listing users, groups, shares, services, processes, and installed software.<br><br>It's widely used for reconnaissance, lateral movement, and privilege escalation within Windows environments, often proving effective even when traditional remote execution methods are blocked. By leveraging valid credentials (username/password or NTLM hashes), <I>nxc-wmi</I> provides a flexible and often stealthy mechanism to gather intelligence and perform actions on target machines without necessarily requiring administrative shares or direct code execution.


title: CAVEATS
content:
The effective use of <I>nxc-wmi</I> is contingent on several factors:<br><b>1. Credentials:</b> Requires valid SMB authentication credentials (username/password or NTLM hash) to access the target.<br><b>2. Network Connectivity:</b> The target must be reachable over SMB (port 445 by default), and firewall rules must permit WMI traffic.<br><b>3. WMI Service:</b> The WMI service must be running and accessible on the target Windows machine.<br><b>4. Permissions:</b> Specific WMI queries or method executions may require local administrator privileges or specific WMI permissions on the target system.<br><b>5. Detection:</b> Extensive or unusual WMI activity might be logged or detected by Endpoint Detection and Response (EDR) solutions or antivirus software.


title: WQL (WMI QUERY LANGUAGE)
content:
Many <I>nxc-wmi</I> operations, particularly the <B>--wmi-query</B> option, rely on WQL. WQL is a SQL-like query language used for retrieving information from WMI classes and instances. It allows for highly specific and flexible data extraction from Windows systems.


title: AUTHENTICATION METHODS
content:
<I>nxc-wmi</I>, via <I>NetExec</I>, supports various authentication methods for SMB, including clear-text passwords (<b>-p</b>) and NTLM hashes (<b>-H</b>). This flexibility is crucial for adapting to different security postures and credential types found during penetration tests.


title: TYPICAL USE CASES
content:
Beyond basic enumeration, <I>nxc-wmi</I> is frequently used for:<br><b>* Reconnaissance:</b> Gathering system information, installed software, network configurations.<br><b>* Lateral Movement:</b> Executing commands or interacting with services on other systems accessible via WMI.<br><b>* Privilege Escalation:</b> Identifying misconfigurations or vulnerabilities through detailed system enumeration.


title: HISTORY
content:
The "nxc-wmi" module is an integral part of <I>NetExec</I>, a direct successor to the widely recognized penetration testing tool <I>CrackMapExec</I> (CME), originally developed by byt3bl33d3r. CME quickly rose to prominence for its ability to interact with various Windows services, including SMB, using diverse authentication methods.<br><br>The WMI module was a core component from early versions of CME, designed to leverage Windows Management Instrumentation for powerful reconnaissance and post-exploitation capabilities. The project's evolution into <I>NetExec</I> signifies a continued commitment to developing and maintaining this versatile tool, with the WMI module remaining a key feature for security professionals seeking advanced Windows interaction methods.


title: SYNOPSIS
content:
<b>nxcdb</b> [<i>options</i>] [<i>arguments</i>]<br><br><i>Note: Due to its specialized nature and lack of widespread public documentation as a general Linux command, the precise syntax and available options are not universally defined and depend heavily on the specific NetX Duo SDK version and implementation. It is often invoked internally by build scripts rather than directly by end-users.</i>


title: DESCRIPTION
content:
The command <b>nxcdb</b> is a highly specialized utility, primarily associated with embedded systems development, particularly within the context of Microsoft Azure RTOS (formerly ThreadX) and its networking component, <b>NetX Duo</b>. It is <i>not a standard Linux command</i> found on general-purpose distributions.<br><br>Its purpose is to manage or manipulate a configuration database (CDB), which may include certificates, security parameters, or other network-related configurations essential for the embedded device's operation. The exact functionality and how <b>nxcdb</b> is invoked are typically specific to the NetX Duo SDK, its build system, or custom scripts rather than a standalone, user-facing command-line tool with a widely documented interface.


title: CAVEATS
content:
This command is <i>highly niche</i> and almost exclusively found within specific embedded development environments, such as those utilizing Microsoft Azure RTOS and NetX Duo. It does <b>not</b> have a standard manual page (man(1)) on typical Linux distributions. Its usage, options, and even its existence as a direct command-line executable are entirely dependent on the specific version and configuration of the NetX Duo SDK or custom toolchain it is part of.<br><br>Users looking for information on <b>nxcdb</b> should consult the official Microsoft Azure RTOS documentation, NetX Duo specific guides, or the source code of the SDK they are using, as general Linux documentation will not cover it.


title: CONTEXT OF USE
content:
<b>nxcdb</b> is typically used by developers working on embedded systems that employ the NetX Duo TCP/IP stack. It might be invoked during the build process to generate or update database files that are then embedded into the firmware, or it could be a utility for pre-processing or inspecting configuration data related to TLS/DTLS or other security features provided by NetX Duo.


title: HISTORY
content:
The command <b>nxcdb</b> is an artifact of the development and evolution of the NetX Duo networking stack, originally part of Express Logic's ThreadX RTOS, and later acquired by Microsoft as Azure RTOS. Its emergence is tied to the need for managing persistent configuration data, such as certificates or network settings, within constrained embedded environments. Its exact historical development as a standalone 'command' is intertwined with the internal tooling and build processes of the NetX Duo framework rather than a separate, publicly documented project.


title: SYNOPSIS
content:
Since <I>"o"</I> is usually an alias, its synopsis mimics the command it points to, most commonly <I>xdg-open</I> or a similar utility.<br><br><b>o</b> <I>[FILE|URL]</I><br><b>o</b> <I>[OPTIONS] FILE|URL</I> (if aliased to a command that supports options)


title: PARAMETERS
content:
<b><I>FILE|URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the file or directory, or a URL, to be opened with its default application.<br><br>


title: DESCRIPTION
content:
The command <b><i>"o"</i></b> is not a standard executable found in common Linux distributions. Instead, it is very frequently used as a user-defined <I>alias</I> or <I>shell function</I> for quickly opening files, directories, or URLs with their default associated applications. <br><br>On macOS, the <I>open</I> command serves a similar purpose. On Linux, users often configure <I>"o"</I> to execute commands like <I>xdg-open</I>, which attempts to open a file or URL using the preferred application for the current desktop environment. This provides a convenient shorthand, avoiding the need to type longer commands like <I>xdg-open</I> or <I>gnome-open</I>/<I>kde-open</I>. Its primary utility lies in streamlining workflow by allowing users to interact with files in a graphical manner directly from the terminal.


title: CAVEATS
content:
The primary caveat is that <I>"o"</I> is <B>not a standard Linux command</B>. Its existence and functionality depend entirely on whether a user or system administrator has defined it as an alias or shell function. <br><br>Therefore:<br><I>1.</I> It may not exist on many systems.<br><I>2.</I> Its behavior can vary wildly depending on its definition (e.g., it might call <I>xdg-open</I>, <I>open</I> on macOS, a custom script, or nothing at all).<br><I>3.</I> Users should check their shell configuration (<I>.bashrc</I>, <I>.zshrc</I>, etc.) or use <I>type o</I> to determine its definition.


title: COMMON IMPLEMENTATIONS
content:
Due to its non-standard nature, <I>"o"</I> is typically set up in a user's shell configuration file. Common implementations include:<br><br><b><i>Bash/Zsh Alias:</i></b> <br><code>alias o='xdg-open'</code><br>This simple alias makes typing <I>o file.pdf</I> equivalent to <I>xdg-open file.pdf</I>.<br><br><b><i>Shell Function:</i></b> <br><code>o() { xdg-open "$@" &>/dev/null & }</code><br>A more robust function might suppress output, background the process, or add logic for different file types. The <I>"$@"</I> passes all arguments to the underlying command.


title: VERIFICATION
content:
To check if <I>"o"</I> is defined on your system and what it does, you can use the <I>type</I> command:<br><br><code>type o</code><br><br>This will output something like <I>o is aliased to `xdg-open'</I> or <I>o is a function</I>, or <I>o not found</I>.


title: HISTORY
content:
While there's no official "history" for the command <I>"o"</I> itself, its usage pattern is rooted in the common practice of defining shell aliases to simplify frequent or long commands. Users, especially those migrating from macOS environments where <I>open</I> is a standard utility, often create an alias for <I>xdg-open</I> (or similar) as <I>"o"</I> for convenience and consistency across different operating systems. This practice reflects the user's desire for efficiency and personalization of their terminal environment, evolving organically within various shell communities.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise help message and exits.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, showing more detailed decoding information.<br><br><b>-o <file>, --output=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the decoded output to the specified file instead of standard output.<br><br><b>-i <file>, --input=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file containing Oakley protocol data to be decoded. If omitted, input is read from standard input.<br><br><b>-f <format>, --format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired output format, such as 'raw', 'json', or 'yaml', if supported.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging for diagnostic purposes, often including internal processing details.<br><br>


title: DESCRIPTION
content:
<i>oakdecode</i> is a non-standard command likely associated with the <b>Oakley Key Determination Protocol</b>, a crucial key exchange mechanism used extensively in IPsec VPNs. Its primary function would be to <i>interpret and display cryptographic data</i>, such as security associations (SAs), keying material, or protocol messages, into a human-readable format. This utility would be invaluable for <br>debugging IPsec tunnels, analyzing key exchange failures, or auditing cryptographic parameters. It's often found within specific security toolkits or custom network environments rather than being a part of standard Linux distributions.


title: CAVEATS
content:
<i>oakdecode</i> is not a standard Linux command and is typically found only in specialized distributions or custom-built security software related to IPsec implementations. Its exact functionality and options may vary significantly based on the specific version or project it belongs to.


title: USAGE CONTEXT
content:
<i>oakdecode</i> would primarily be used by network security administrators, penetration testers, or developers working on IPsec VPN solutions. It helps in understanding the low-level details of key exchange processes, troubleshooting connectivity issues, or verifying the correct implementation of cryptographic algorithms and parameters as defined by the Oakley protocol.


title: INPUT DATA
content:
The command likely expects raw binary data streams representing Oakley protocol messages, often captured from network traffic (e.g., using <i>tcpdump</i>) or extracted from specific memory structures of an IPsec daemon.


title: HISTORY
content:
Due to its non-standard nature, <i>oakdecode</i> does not have a widely documented public history. It likely originated as a debugging or analysis tool within specific IPsec VPN implementations or open-source cryptographic projects that deal with the Oakley protocol (e.g., ISAKMP/IKE). Its development would be tightly coupled with the evolution of these projects, serving as an internal utility for developers and administrators to parse and understand complex key exchange data structures.


title: SYNOPSIS
content:
<I>oathtool</I> [<B>--totp</B> | <B>--hotp</B>] [<I>OPTIONS</I>] <I>KEY</I><br><I>oathtool</I> <B>--convert-otp-key</B> [<I>OPTIONS</I>] <I>KEY</I><br><I>oathtool</I> <B>--help</B> | <B>--version</B>


title: PARAMETERS
content:
<b>--totp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate or validate a <I>TOTP</I> code (Time-based One-Time Password).<br><br><b>--hotp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate or validate a <I>HOTP</I> code (HMAC-based One-Time Password).<br><br><b>KEY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The secret key used for OTP generation or validation. By default, it's interpreted as hexadecimal.<br><br><b>--base32</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret the input <I>KEY</I> as <I>Base32</I> encoded (RFC 4648).<br><br><b>--hex</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret the input <I>KEY</I> as hexadecimal encoded (default).<br><br><b>--print-base32</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the generated <I>KEY</I> in <I>Base32</I> encoding when using <B>--convert-otp-key</B>.<br><br><b>--print-hex</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the generated <I>KEY</I> in hexadecimal encoding when using <B>--convert-otp-key</B> (default output).<br><br><b>--count=<N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <I>HOTP</I> counter value (step count) for <B>--hotp</B> operations.<br><br><b>--start-offset=<N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the <I>HOTP</I> counter from <I>N</I> when validating a range for <B>--hotp</B>.<br><br><b>--now=<TIME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the current time for <I>TOTP</I> operations. Accepts various time formats, e.g., 'now', '2023-10-27 10:00:00', or a Unix timestamp.<br><br><b>--time-step=<N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the <I>TOTP</I> time-step size to <I>N</I> seconds (default 30 seconds).<br><br><b>--digits=<N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of digits for the OTP (default 6; can be 6, 7, 8, 9).<br><br><b>--check=<CODE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Validate a user-provided <I>CODE</I> against the <I>KEY</I> (requires <B>--hotp</B> or <B>--totp</B>).<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force validation for <B>--check</B> even if the current counter/time is outside a reasonable window.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing intermediate calculations.<br><br><b>--convert-otp-key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert the input <I>KEY</I> to a different encoding format based on output options (e.g., <B>--print-base32</B>).<br><br><b>--rfc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <I>RFC</I>-compliant defaults for hashing algorithms and time steps (e.g., SHA1 for TOTP, 30s step).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<I>oathtool</I> is a command-line utility from the <I>OATH Toolkit</I> for generating and validating one-time passwords (OTPs) based on the <I>OATH (Open AuTHentication) standards</I>. It supports both <I>TOTP (Time-based One-Time Password)</I> as defined in <I>RFC 6238</I> and <I>HOTP (HMAC-based One-Time Password)</I> as defined in <I>RFC 4226</I>.<br><br>This tool is invaluable for developers, system administrators, and security professionals who need to work with OTPs in scripts, for testing authentication systems, or for offline token generation. It allows you to generate codes from a secret key, verify user-provided codes against a secret, and convert secret keys between different encodings like Base32 and hexadecimal. While powerful, it operates purely locally and does not integrate with any external authentication services.


title: CAVEATS
content:
<I>oathtool</I> is a command-line utility and does not provide a full authentication system. It is designed for offline generation and validation of OTPs. <br><br><B>Security Implications</B>: Handling secret keys on the command line or in scripts can be insecure as the key might be exposed in shell history or process listings. Exercise caution when dealing with sensitive keys. For robust security, keys should be stored and managed securely, often requiring a secure key store or hardware security module (HSM). <br><br>It's also crucial to ensure the system's clock is accurate for <I>TOTP</I> operations to work reliably, as time synchronization is vital.


title: USAGE EXAMPLES
content:
Here are a few common examples demonstrating <I>oathtool</I>'s capabilities:<br><br><B>1. Generate a TOTP code (default 6 digits, 30s step, hex key):</B><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>oathtool --totp 3132333435363738393031323334353637383930<br></I><br><B>2. Generate a HOTP code with a specific counter (Base32 key):</B><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>oathtool --hotp --base32 --count=10 JBSWY3DPEHPK3PXP<br></I><br><B>3. Convert a Base32 key to Hexadecimal:</B><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>oathtool --convert-otp-key --base32 --print-hex JBSWY3DPEHPK3PXP<br></I><br><B>4. Validate a TOTP code (checks against current time):</B><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>oathtool --totp --check=123456 3132333435363738393031323334353637383930<br></I>


title: KEY FORMATS
content:
<I>oathtool</I> supports secret keys in two primary formats:<br>&nbsp;&nbsp;&nbsp;&nbsp;<B>Hexadecimal</B>: This is the default format. A hexadecimal key consists of characters '0'-'9' and 'a'-'f' (or 'A'-'F'). Each pair of characters represents a byte.<br>&nbsp;&nbsp;&nbsp;&nbsp;<B>Base32</B>: This format is often used for human readability and URL-safety (RFC 4648). It uses characters 'A'-'Z' and '2'-'7'. When specifying a Base32 key, you must use the <B>--base32</B> option.<br><br>The tool can also convert keys between these formats using the <B>--convert-otp-key</B> option.


title: OATH STANDARDS (HOTP & TOTP)
content:
<B>HOTP (HMAC-based One-Time Password)</B> (RFC 4226): This algorithm generates an OTP based on a shared secret key and a moving counter. Each time a new OTP is generated, the counter is incremented. Validation requires the server to keep track of the client's current counter value.<br><br><B>TOTP (Time-based One-Time Password)</B> (RFC 6238): This is an extension of HOTP that replaces the counter with a time-based value. The OTP is generated using a shared secret key and the current time (usually truncated to a 30 or 60-second window). Both client and server must have synchronized clocks for successful validation.


title: HISTORY
content:
<I>oathtool</I> is a core component of the <I>OATH Toolkit</I>, an open-source software project that provides libraries and applications for implementing <I>OATH (Open AuTHentication) standards</I>. The toolkit was primarily developed by <I>Simon Josefsson</I>, known for his contributions to cryptographic software and standards. Its development aimed to provide robust, open-source implementations of <I>HOTP</I> and <I>TOTP</I>, making it accessible for integration into various systems and for testing purposes since its early releases around the mid-2000s.


title: SYNOPSIS
content:
obabel [options]<br>obabel -i<I>input-format</I> <I>input-file</I> -o<I>output-format</I> <I>output-file</I> [options]


title: PARAMETERS
content:
<b>-i<I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file format. If omitted, <i>obabel</i> attempts to guess from the file extension.<br><br><b>-o<I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file format. If omitted, <i>obabel</i> attempts to guess from the output file extension.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads input from <b>stdin</b> instead of a file.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes output to <b>stdout</b> instead of a file.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates or optimizes 2D coordinates for molecules lacking them.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates or optimizes 3D coordinates for molecules lacking them. Often used with --gen3d.<br><br><b>-s <I>smarts</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a substructure search using a SMARTS pattern. Only molecules matching the pattern are processed.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the process.<br><br><b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a comprehensive list of all supported chemical file formats, along with their extensions and read/write capabilities.<br><br><b>--addhydrogens</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds hydrogens to the molecules, typically adding polar hydrogens or completing valencies.<br><br><b>--removehydrogens</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all hydrogens from the molecules, leaving only heavy atoms.<br><br><b>--gen3d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates 3D coordinates for molecules, often followed by energy minimization for better geometry.<br><br><b>--minimize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs energy minimization using a specified force field (e.g., MMFF94, UFF) to optimize molecular geometry.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If multiple molecules are output, write each to a separate file, appending an index to the filename.<br><br><b>-O <I>output_file_or_prefix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output filename or a prefix for multiple output files (when used with -m).<br><br>


title: DESCRIPTION
content:
<i>obabel</i> is the powerful command-line interface to the <b>Open Babel</b> cheminformatics toolkit. It is designed for interconverting chemical file formats, performing molecular manipulations, and calculating chemical properties. Supporting over 110 chemical file formats (including SMILES, PDB, SDF, CML, XYZ), <i>obabel</i> is an indispensable tool for chemists, biologists, and material scientists. Beyond format conversion, it can generate 2D or 3D coordinates, add or remove hydrogens, perform substructure searches, calculate various molecular descriptors, and even carry out energy minimization, making it highly versatile for diverse computational chemistry tasks.


title: CAVEATS
content:
Coordinate generation (e.g., with <b>--gen3d</b>) provides initial geometries, but for chemically accurate structures, subsequent energy minimization using a suitable force field is recommended. <br>The quality and completeness of format conversion can vary, as some formats support features not present in others. Large substructure searches or database processing can be computationally intensive.


title: SUPPORTED FORMATS
content:
<i>obabel</i> supports an extensive range of chemical file formats. Use the <b>-H</b> option to see a comprehensive list of all supported formats, their common extensions, and whether they can be used for reading or writing.


title: DEFAULT BEHAVIOR
content:
If input or output formats are not explicitly specified, <i>obabel</i> will attempt to infer them from the file extensions. If no output file is specified, the processed chemical data will be written to <b>stdout</b>.


title: HISTORY
content:
<b>Open Babel</b> originated from the earlier <i>babel</i> program, with development starting in 2000. It aimed to be a more robust, cross-platform, and extensible cheminformatics toolkit. It has since evolved into a widely recognized open-source project, maintained by a community of developers, and is a cornerstone for many computational chemistry workflows and software.


title: PARAMETERS
content:
<b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug messages for troubleshooting and development.<br><br><b><b>-f</b>, <b>--foreground</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps the server running in the foreground instead of detaching as a daemon. Useful for debugging and terminal monitoring.<br><br><b><b>-r</b>, <b>--replace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to replace an existing instance of the daemon if one is already running, ensuring a fresh start.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <i>obex-data-server</i> and exits immediately.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief help message with available command-line options and exits.<br><br>


title: DESCRIPTION
content:
<i>obex-data-server</i> provides a D-Bus service that enables applications to exchange objects using the OBEX (Object Exchange) protocol, primarily over Bluetooth. It acts as a backend for various OBEX profiles, including <b>OBEX Push</b> (for sending files), <b>OBEX FTP</b> (for browsing and manipulating files on a remote device), and <b>OBEX Sync</b> (for synchronizing data like contacts or calendar entries).<br><br>As a system service, it is typically activated automatically via D-Bus when an application requests OBEX functionality, rather than being invoked directly by users. It abstracts the underlying OBEX communication, providing a standardized D-Bus interface for applications to interact with Bluetooth-enabled devices for object transfer.


title: CAVEATS
content:
<i>obex-data-server</i> is typically managed by the system's D-Bus daemon and is automatically started when an application requires OBEX services. Users generally do not need to run it manually from the command line. Directly launching it without proper D-Bus integration may not provide full functionality or integrate correctly with other system services.<br><br>While OBEX is a standard protocol, its direct usage for file transfer has somewhat diminished in favor of more modern methods (e.g., Wi-Fi Direct, cloud services), though it remains relevant for legacy and specific embedded contexts. Security largely depends on the underlying Bluetooth security model (pairing, trust relationships).


title: D-BUS INTEGRATION
content:
<i>obex-data-server</i> registers itself on the system D-Bus, typically under the service name <code>org.bluez.obex</code> or a similar identifier, allowing applications to discover and interact with its services programmatically. This ensures a standardized and secure way for applications to request OBEX operations without needing direct access to Bluetooth hardware.


title: PROTOCOL PROFILES
content:
Beyond basic file transfer, OBEX supports various profiles like <b>Object Push Profile (OPP)</b> for sending objects, <b>File Transfer Profile (FTP)</b> for remote file system browsing, and <b>Synchronization Profile (SYNC)</b> for data synchronization. <i>obex-data-server</i> provides the underlying support for these profiles on the Linux platform, enabling a wide range of Bluetooth-based data interactions.


title: HISTORY
content:
The OBEX protocol itself was standardized in 1999, primarily for object exchange over IrDA and later widely adopted by Bluetooth. <i>obex-data-server</i> emerged as part of the broader effort to provide robust Bluetooth support on Linux systems, integrating OBEX capabilities into the D-Bus ecosystem. Its development is tied to the evolution of the BlueZ Bluetooth stack and the need for standardized interfaces for applications to interact with Bluetooth services. It has been a core component for file transfer and synchronization functionality over Bluetooth on Linux for many years, providing a modern D-Bus bridge to this established protocol.


title: PARAMETERS
content:
<b>-S, --strip-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove all symbol and relocation information from the output file.<br><br><b>-g, --strip-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove debug symbols from the output file.<br><br><b>-K <symbolname>, --strip-symbol=<symbolname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove all symbols named <i>&lt;symbolname&gt;</i> from the output file.<br><br><b>-R <sectionname>, --remove-section=<sectionname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove the specified section <i>&lt;sectionname&gt;</i> from the output file.<br><br><b>-j <sectionname>, --only-section=<sectionname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy only the specified section(s) <i>&lt;sectionname&gt;</i> from the input file to the output file.<br><br><b>-O <bfdname>, --output-target=<bfdname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output object file format to <i>&lt;bfdname&gt;</i>.<br><br><b>-I <bfdname>, --input-target=<bfdname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the input object file format to <i>&lt;bfdname&gt;</i>. Useful when input format cannot be determined automatically.<br><br><b>-B <architecture>, --binary-architecture=<architecture></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output architecture for binary dumps. This is for raw binary files without BFD headers.<br><br><b>-p, --preserve-dates</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserve the access and modification dates of the output file, matching the input file.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all object files copied, providing more detailed output.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for <b>objcopy</b>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<b>objcopy</b> is a powerful utility from the GNU Binutils package. It allows users to copy an object file, translating it into a different format if desired, or making various modifications to its contents.<br><br>This tool is frequently used for tasks such as stripping symbols (debug, local, or all), changing the architecture or format of an object file, extracting specific sections, or adding/removing sections. It's an essential tool for embedded systems development, optimizing binary sizes, and preparing executables for distribution.


title: CAVEATS
content:
Stripping symbols, especially all symbols, can make debugging the resultant binary much harder.<br><br>Incorrectly changing object file formats or architectures may render the output binary unusable.<br><br>Modifying or removing critical sections can break the program's functionality if not done carefully. Not all Binary File Descriptor (BFD) formats support all operations.


title: COMMON USE CASES
content:
<b>objcopy</b> is extensively used in embedded systems development to convert ELF executable files into raw binary images, Intel HEX, or Motorola S-record formats suitable for direct flashing to microcontrollers. It's also frequently employed to reduce the size of executables and shared libraries by removing unnecessary debug or local symbols before deployment, thereby conserving disk space and memory.


title: BFD LIBRARY
content:
The power of <b>objcopy</b> comes from its reliance on the BFD (Binary File Descriptor) library. BFD provides a common interface for reading and writing a wide range of object file formats (like ELF, COFF, PE, etc.) and architectures. This abstraction allows <b>objcopy</b> to perform format translations and manipulations without needing specific knowledge of each format internally, making it highly versatile.


title: HISTORY
content:
<b>objcopy</b> is a fundamental part of the GNU Binutils, a collection of binary tools maintained by the GNU Project since the late 1980s. It was developed to address the need for flexible manipulation of object files across various architectures and formats, playing a crucial role in cross-compilation toolchains and optimizing binaries for different deployment scenarios, especially in embedded systems.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--archive-header</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the archive header information for archive members. Only meaningful when given an archive file (e.g., a .a file).<br><br><b><b>-b</b> <i>BFDNAME</i>, <b>--target=</b><i>BFDNAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target object code format. <i>objdump</i> can usually figure this out automatically, but this option allows overriding it (e.g., <i>--target=i386-linux</i>).<br><br><b><b>-C</b>, <b>--demangle</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Demangle low-level symbol names into user-level names. This is especially useful for C++ programs to display readable function names (e.g., <i>_ZSt8make_pairISt4pairIiiESt10unique_ptrIiSt14default_deleteIiEE</i> becomes <i>std::make_pair<std::pair<int, int>, std::unique_ptr<int, std::default_delete<int>>></i>).<br><br><b><b>-d</b>, <b>--disassemble</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble the executable sections (usually <i>.text</i>) of the object file. This is one of the most common uses, showing the assembly instructions.<br><br><b><b>-D</b>, <b>--disassemble-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble all sections that are likely to contain code. This includes sections that are not normally executable, providing a more comprehensive view.<br><br><b><b>-e</b>, <b>--debugging-lines</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display debug line number information alongside disassembly. Requires debugging information to be present in the binary.<br><br><b><b>-f</b>, <b>--file-headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the contents of the overall file header, including the architecture and object file format.<br><br><b><b>-g</b>, <b>--debugging</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display debugging information. The exact output depends on the debugging format (e.g., DWARF, STABS).<br><br><b><b>-h</b>, <b>--section-headers</b>, <b>--headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the contents of the section headers, which describe the different segments (e.g., <i>.text</i>, <i>.data</i>, <i>.bss</i>) within the object file.<br><br><b><b>-i</b>, <b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about the supported architectures and object file formats by the BFD library.<br><br><b><b>-j</b> <i>NAME</i>, <b>--section=</b><i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information only for the specified section <i>NAME</i>. Can be used with other options like <i>-s</i> or <i>-d</i> to focus on a particular section.<br><br><b><b>-l</b>, <b>--line-numbers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display source code line numbers with disassembly or symbol tables. Requires debugging information.<br><br><b><b>-L</b>, <b>--start-address=</b><i>ADDR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start disassembly (or other operations) at the specified address <i>ADDR</i>.<br><br><b><b>-M</b> <i>OPTION</i>, <b>--disassembler-options=</b><i>OPTION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass specific options to the disassembler, such as controlling the output format (e.g., <i>intel</i> for Intel syntax, <i>att</i> for AT&T syntax, <i>reg-names-std</i>, <i>no-aliases</i>).<br><br><b><b>-N</b> <i>SYMBOL</i>, <b>--symbol=</b><i>SYMBOL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information only for the specified symbol. Useful when disassembling a specific function or viewing a specific data symbol.<br><br><b><b>-p</b>, <b>--private-headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information specific to the object file format (e.g., ELF program headers, COFF optional header). Equivalent to <i>readelf -l</i> for ELF files.<br><br><b><b>-r</b>, <b>--reloc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the relocation entries of the file. These entries indicate where the linker needs to patch addresses after loading the program.<br><br><b><b>-R</b>, <b>--dynamic-reloc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the dynamic relocation entries of the file. These are used by the dynamic linker/loader at runtime.<br><br><b><b>-s</b>, <b>--full-contents</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the full contents of any sections requested. If no sections are specified with <i>-j</i>, it will show the contents of all non-empty sections.<br><br><b><b>-S</b>, <b>--source</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Intermix source code with disassembly. Requires debugging information and source files to be accessible in the original build path.<br><br><b><b>-t</b>, <b>--syms</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the symbol table entries of the file. This includes all global and local symbols defined or referenced.<br><br><b><b>-T</b>, <b>--dynamic-syms</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the dynamic symbol table entries. These are symbols needed for dynamic linking (e.g., functions imported from shared libraries).<br><br><b><b>-u</b>, <b>--unwind-info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display unwind info, if present. This information is used for exception handling and stack unwinding during debugging.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of <i>objdump</i>.<br><br><b><b>-w</b>, <b>--wide</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format output for lines wider than 80 columns, preventing truncation and improving readability for disassembly.<br><br><b><b>-x</b>, <b>--all-headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all header information available (equivalent to combining <i>-a -f -h -p -r -R -t -T</i> for common cases).<br><br><b><b>--adjust-vma=</b><i>OFFSET</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>OFFSET</i> to all displayed addresses. Useful for analyzing position-independent code loaded at a specific base address.<br><br><b><b>--disable-sections</b>, <b>--enable-sections</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls whether section names are displayed in output (useful for very long section names).<br><br><b><b>--no-leading-addr</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the address at the beginning of a line of disassembly. Useful for comparing disassembly from different tools.<br><br><b><b>--no-show-raw-insn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When disassembling, do not print the raw bytes of the instruction, only the assembly mnemonic.<br><br><b><b>--prefix-addresses</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the complete address on each line of disassembly, not just relative offsets.<br><br><b><b>--start-address=</b><i>ADDR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start disassembling at the specified address <i>ADDR</i>.<br><br><b><b>--stop-address=</b><i>ADDR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop disassembling at the specified address <i>ADDR</i>.<br><br>


title: DESCRIPTION
content:
<i>objdump</i> is a command-line utility from the GNU Binutils package used to display various information about object files, including executables, shared libraries, and regular object files. It acts as a wrapper around the BFD (Binary File Descriptor) library, which allows it to understand different object file formats (like ELF, COFF, PE, etc.) and architectures.<br><br>Its primary uses include disassembling machine code into human-readable assembly, viewing symbol tables, examining section headers, inspecting relocation entries, and displaying the raw contents of sections. This makes it an invaluable tool for reverse engineering, debugging binaries, analyzing compiler output, and understanding the low-level structure of programs without needing a full debugger.


title: CAVEATS
content:
<i>objdump</i>'s output can be verbose and requires a good understanding of assembly language, object file formats (like ELF), and system architecture. While powerful for static analysis, it lacks the interactive debugging capabilities of a debugger like <i>gdb</i>. It cannot reliably disassemble highly optimized or obfuscated code, and its source intermixing (<i>-S</i>) relies on correct debugging information and accessible source paths from the build environment.


title: COMMON USE CASES
content:
<ul><li><b>Code Disassembly:</b> Use <i><b>-d</b></i> or <i><b>-D</b></i> to see the assembly code of an executable or library, often combined with <i><b>-M intel</b></i> for Intel syntax.</li><li><b>Symbol Inspection:</b> Use <i><b>-t</b></i> to list all symbols (functions, variables) and <i><b>-T</b></i> for dynamically linked symbols. <i><b>-C</b></i> helps to demangle C++ names.</li><li><b>Section Analysis:</b> Use <i><b>-h</b></i> to view section headers (size, address, flags) and <i><b>-s</b></i> to dump raw section contents. <i><b>-j &lt;section_name&gt;</b></i> can narrow down the focus.</li><li><b>Debugging Information:</b> Options like <i><b>-g</b></i>, <i><b>-l</b></i>, and <i><b>-S</b></i> allow inspecting debugging data and intermixing source code with disassembly, provided the binary was compiled with debug symbols (e.g., <i>gcc -g</i>).</li></ul>


title: OUTPUT INTERPRETATION
content:
When disassembling, <i>objdump</i> typically shows the virtual address, raw instruction bytes (hexadecimal), and the decoded assembly instruction. Symbols are often shown as offsets from their base address or as absolute addresses. Understanding the specific assembly dialect (AT&T vs. Intel) and the calling conventions of the architecture is crucial for interpreting the output effectively.


title: HISTORY
content:
<i>objdump</i> is a core component of the GNU Binutils project, a collection of programming tools for creating and managing binary programs. Its development dates back to the early days of the GNU Project, aiming to provide free and open-source alternatives to proprietary Unix tools. It has continuously evolved to support new architectures and object file formats, becoming an indispensable tool for developers, reverse engineers, and security researchers on Linux and other Unix-like systems.


title: SYNOPSIS
content:
<b>obs</b> [<i>GLOBAL_OPTIONS</i>] &lt;<i>SUBCOMMAND</i>&gt; [<i>SUBCOMMAND_OPTIONS</i>] [<i>ARGUMENTS</i>]


title: PARAMETERS
content:
<b><i>GLOBAL_OPTIONS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options that apply to the <b>obs</b> command itself, regardless of the subcommand. Common global options include <b>--help</b> (or <b>-h</b>) for displaying general help, <b>--version</b> (or <b>-v</b>) for showing the client version, <b>--debug</b> for verbose debugging output, <b>--quiet</b> (or <b>-q</b>) for suppressing output, <b>--apiurl &lt;URL&gt;</b> to specify the OBS API endpoint, and <b>--config &lt;FILE&gt;</b> to use a specific configuration file.<br><br><b>&lt;<i>SUBCOMMAND</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary action to perform. <b>obs</b> is designed around a subcommand pattern, where different subcommands handle specific OBS functionalities. Examples include: <b>build</b> (to build packages), <b>checkout</b> (or <b>co</b>, to get a local copy of a project/package), <b>commit</b> (or <b>ci</b>, to upload local changes), <b>ls</b> (to list projects or packages), <b>submit</b> (to submit new packages or changes), <b>request</b> (to manage review or merge requests), <b>prj</b> (to manage projects), <b>pkg</b> (to manage packages), and <b>search</b> (to search for OBS packages).<br><br><b>[<i>SUBCOMMAND_OPTIONS</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options specific to the chosen subcommand. Each subcommand typically has its own set of options to modify its behavior. For example, <b>obs commit -m &quot;message&quot;</b> uses the <b>-m</b> option for the <b>commit</b> subcommand.<br><br><b>[<i>ARGUMENTS</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional arguments required by the subcommand, such as project names, package names, file paths, or request IDs. For instance, <b>obs checkout myproject/mypackage</b> uses <b>myproject/mypackage</b> as an argument to the <b>checkout</b> subcommand.<br><br>


title: DESCRIPTION
content:
The <b>obs</b> command provides a powerful command-line interface for the <I>Open Build Service (OBS)</I>. OBS is a generic system for building and distributing packages from sources in an automated, consistent, and reproducible manner. The <b>obs</b> client allows developers and users to manage their OBS projects, packages, requests, and repositories directly from the terminal. It supports various actions such as creating and modifying projects, adding and removing packages, submitting build requests, checking build statuses, managing review processes, and handling project configuration. It's an essential tool for anyone working with OBS, enabling scripting and automation of build workflows. It simplifies interactions with the OBS server, offering a comprehensive set of subcommands for almost every OBS task.


title: CAVEATS
content:
The <b>obs</b> command requires proper configuration, including the OBS API URL and user credentials, often stored in a configuration file (e.g., <I>~/.config/obs/config</I>). Its functionality is entirely dependent on a running OBS instance and the user's permissions within that instance. Due to the comprehensive nature of OBS, mastering the <b>obs</b> command line client can involve a significant learning curve to understand the underlying OBS concepts.


title: CONFIGURATION FILES
content:
The <b>obs</b> client typically reads its configuration from files such as <I>~/.config/obs/config</I> or, for backward compatibility, <I>~/.oscrc</I>. These files store crucial information like the default OBS API URL, user authentication tokens, and other preferences. It's often necessary to set up this configuration before extensive use of the command.


title: TYPICAL WORKFLOW
content:
A common workflow with <b>obs</b> involves using <b>checkout</b> to obtain a local working copy of an OBS project or package, making changes to source files or metadata locally, and then using <b>commit</b> to push those changes back to the OBS server. Users can also leverage subcommands like <b>build</b> to trigger builds, <b>status</b> to check build progress, and <b>request</b> to manage submissions and reviews.


title: HISTORY
content:
The <b>obs</b> command is the modern, Python-based command-line client for the Open Build Service. It emerged as a successor to the older <I>osc</I> (Open Build Service Client), which was written in Perl. Its development aimed to provide a more consistent, robust, and user-friendly interface, better integrating with contemporary development workflows and leveraging Python's ecosystem. It has since become the officially recommended CLI client for interacting with OBS instances, reflecting the continuous evolution of the build service itself.


title: SYNOPSIS
content:
<b><I>oc</I></b> <I>&lt;command&gt;</I> [<I>&lt;subcommand&gt;</I>] [<I>options</I>] [<I>arguments</I>]<br><br>The <b><I>oc</I></b> command operates on a subcommand structure, where the main command is followed by a specific action (e.g., <b><I>get</I></b>, <b><I>apply</I></b>, <b><I>login</I></b>, <b><I>new-app</I></b>), which may in turn have further subcommands and associated options and arguments.


title: PARAMETERS
content:
<b><b><I>--help</I></b>, <b><I>-h</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b><I>oc</I></b> command or a specific subcommand.<br><br><b><b><I>--config=&lt;path&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the kubeconfig file to use for connection details.<br><br><b><b><I>--context=&lt;name&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the kubeconfig context to use, overriding the current context.<br><br><b><b><I>--namespace=&lt;name&gt;</I></b>, <b><I>-n &lt;name&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If present, the namespace scope for the CLI request.<br><br><b><b><I>--server=&lt;url&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The address and port of the OpenShift API server to connect to.<br><br><b><b><I>--token=&lt;token&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bearer token for authentication, used in conjunction with <b><I>--server</I></b>.<br><br><b><b><I>--insecure-skip-tls-verify</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If true, the server's certificate will not be checked for validity. Use with caution.<br><br><b><b><I>--loglevel=&lt;level&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the level of logging detail (e.g., 0 for silent, 9 for verbose).<br><br>


title: DESCRIPTION
content:
The <b><I>oc</I></b> command is the command-line interface (CLI) for interacting with OpenShift clusters. It provides a powerful set of tools for developers and administrators to manage applications, build processes, deployments, projects, and various OpenShift resources directly from the terminal.<br><br>While sharing much of its core functionality with <b><I>kubectl</I></b> (the Kubernetes CLI), <b><I>oc</I></b> extends capabilities with OpenShift-specific concepts like <i>ImageStreams</i>, <i>BuildConfigs</i>, <i>DeploymentConfigs</i>, <i>Routes</i>, and <i>Projects</i>. It allows users to log into a cluster, create and manage applications, initiate builds, scale deployments, inspect logs, debug issues, and perform administrative tasks such as managing users, roles, and security policies.<br><br>It is the primary tool for automating tasks and scripting interactions with OpenShift, providing comprehensive control over the platform's features.


title: CAVEATS
content:
The <b><I>oc</I></b> command is not a standard Linux command available on all distributions by default. It is specifically designed for and used with Red Hat OpenShift Container Platform. It requires separate installation and a configured connection (via a kubeconfig file) to an OpenShift cluster to function correctly. Its functionality is heavily reliant on the OpenShift API and the specific version of the cluster being interacted with.


title: COMMON USAGE PATTERNS
content:
The <b><I>oc</I></b> command is used for a variety of tasks:<br><ul><li><b><I>oc login</I></b>: Authenticate to an OpenShift cluster.</li><li><b><I>oc new-app</I></b>: Create new applications from source code, images, or templates.</li><li><b><I>oc project</I></b>: Switch between OpenShift projects (namespaces).</li><li><b><I>oc get &lt;resource&gt;</I></b>: List various OpenShift resources (e.g., pods, services, deployments, routes).</li><li><b><I>oc apply -f &lt;file&gt;</I></b>: Apply configuration changes defined in a file.</li><li><b><I>oc logs &lt;pod&gt;</I></b>: View logs for a specific pod.</li><li><b><I>oc rsh &lt;pod&gt;</I></b>: Open a shell inside a running container.</li></ul>


title: HISTORY
content:
The <b><I>oc</I></b> command was developed as part of the OpenShift Container Platform, an enterprise-grade Kubernetes distribution from Red Hat. Initially, OpenShift had its own orchestration engine (v2), but with OpenShift v3, it re-architected on top of Kubernetes. Consequently, the <b><I>oc</I></b> CLI was built upon the Kubernetes client libraries, inheriting much of <b><I>kubectl</I></b>'s design and functionality while adding OpenShift-specific commands and resource types. Its development continues in tandem with OpenShift releases, constantly evolving to support new features and improvements in the platform.


title: PARAMETERS
content:
<b>-I <I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <I>dir</I> to the list of directories searched for compiled interface files (.cmi) and bytecode files (.cmo).<br><br><b>-init <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load the script <I>file</I> at the beginning of the session.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information and exit.<br><br><b>-vnum</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the OCaml version number and exit.<br><br><b>-noprompt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display the prompt, useful for non-interactive execution.<br><br><b>-stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read input from standard input instead of the terminal.<br><br><b>-safe-string</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat string literals as immutable. This is the default behavior since OCaml 4.02.<br><br><b>-labels</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow optional and named parameters for function calls (default in recent OCaml versions).<br><br><b>-no-labels</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disallow optional and named parameters for function calls.<br><br><b>-warn-error <I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat specified warnings as errors, where <I>list</I> is a sequence of warning flags.<br><br><b>-w <I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable specific warnings, where <I>list</I> is a sequence of warning flags.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a short usage summary and exit.<br><br>


title: DESCRIPTION
content:
The <i>ocaml</i> command launches the interactive top-level environment for the OCaml programming language. It serves as a Read-Eval-Print Loop (REPL), allowing users to input OCaml expressions, definitions, and declarations directly, which are then immediately evaluated and their results (type and value) displayed. This makes it an invaluable tool for experimenting with code snippets, learning the language's syntax and semantics, and quickly debugging small functions or modules.<br><br>The top-level automatically loads the standard library, providing access to fundamental data structures and functions. Users can enter multi-line code, ending inputs with <I>;;</I> (double semi-colon) followed by Enter. It also supports special directives, prefixed with <I>#</I>, for tasks like loading compiled modules (<I>#load</I>), executing scripts (<I>#use</I>), or changing directories (<I>#cd</I>). While <i>ocaml</i> is excellent for interactive development, compiled OCaml code (generated by <i>ocamlc</i> or <i>ocamlopt</i>) is generally used for building and deploying applications, offering superior performance.


title: CAVEATS
content:
The <i>ocaml</i> interactive interpreter is designed for rapid prototyping, learning, and debugging, not for executing performance-critical applications. Code run in the interpreter is typically slower than natively compiled code (generated by <i>ocamlopt</i>). Additionally, certain advanced features, such as linking with external C libraries, can be more complex to manage within the interactive environment compared to standard compilation workflows.


title: TOP-LEVEL DIRECTIVES
content:
The <i>ocaml</i> interactive top-level understands special commands, known as directives, prefixed with a hash symbol (<B>#</B>) and terminated by double semicolons (<B>;;</B>). These directives facilitate various tasks within the interpreter environment:<br><br><b>#use "file.ml";;</b><br>Executes the OCaml code contained in the specified file.<br><br><b>#load "module.cmo";;</b><br>Loads a compiled bytecode module, making its contents available in the current session.<br><br><b>#cd "dir";;</b><br>Changes the current working directory of the interpreter.<br><br><b>#quit;;</b><br>Exits the OCaml interactive top-level.<br><br><b>#help;;</b><br>Displays a list of available top-level directives and their purposes.<br><br><b>#trace <I>function</I>;;</b><br>Enables tracing for a specified function, showing its calls and returns during execution.


title: HISTORY
content:
OCaml originated from the Caml (Categorical Abstract Machine Language) family of languages, initially developed at INRIA (French National Institute for Research in Computer Science and Automation) in the early 1990s. The 'O' in OCaml stands for 'Objective,' reflecting its extension with object-oriented programming features, which were added to Caml Light. The first stable release of OCaml was in 1996. It has since undergone continuous development, evolving into a mature, multi-paradigm language widely used in research, education, and industry, particularly for compilers, static analysis tools, and financial applications.


title: PARAMETERS
content:
<b><b>-clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all generated files and temporary directories created by <i>ocamlbuild</i>.<br><br><b><b>-r</b>, <b>-rebuild</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a complete rebuild of all targets from scratch, ignoring existing compiled files.<br><br><b><b>-use-ocamlfind</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables integration with the <i>ocamlfind</i> tool for managing and locating OCaml libraries.<br><br><b><b>-package</b> <i>&lt;pkg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an <i>ocamlfind</i> package (e.g., 'core', 'lwt') to the list of required packages for the build.<br><br><b><b>-plugin-tag</b> <i>&lt;tag&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads a specific <i>ocamlbuild</i> plugin by its tag, extending its functionality.<br><br><b><b>-show-tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the list of tags currently recognized and applied by <i>ocamlbuild</i> in the configuration.<br><br><b><b>-ocamlc</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>ocamlc</i> (OCaml bytecode compiler) executable to be used.<br><br><b><b>-ocamlopt</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>ocamlopt</i> (OCaml native code compiler) executable to be used.<br><br><b><b>-where</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installation path of the <i>ocamlbuild</i> tool itself.<br><br><b><b>-quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most of the verbose output during the build process, showing only errors.<br><br><b><b>-no-progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the display of real-time compilation progress indicators.<br><br><b><b>-classic-display</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a simpler, non-interactive output format instead of the enhanced progress display.<br><br><b><b>-no-auto-clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>ocamlbuild</i> from automatically cleaning intermediate files before building.<br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <i>ocamlbuild</i> command.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message detailing command line options and usage.<br><br>


title: DESCRIPTION
content:
<i>ocamlbuild</i> is a powerful and flexible build system specifically designed for OCaml projects. It automates the compilation and linking process by automatically inferring dependencies between source files and managing the invocation of <i>ocamlc</i>, <i>ocamlopt</i>, and other tools. Unlike traditional build tools like <i>make</i>, <i>ocamlbuild</i> uses a declarative, rule-based approach, where users specify build goals (targets) and <i>ocamlbuild</i> determines the necessary steps to achieve them.<br><br>It supports common OCaml features such as bytecode compilation, native code compilation, <i>.cmi</i> and <i>.cmx</i> files, and integration with <i>ocamlfind</i> for library management. Its extensibility through plugins allows users to define custom build rules and integrate with external tools or specific project structures. It handles cleaning intermediate files and rebuilding only what's necessary, improving build times. While widely used, especially in older OCaml projects, newer alternatives like Dune have become more prevalent.


title: CAVEATS
content:
While powerful, <i>ocamlbuild</i> can have a significant learning curve due to its reliance on a tag-based system and specific directory structures. Configuring it for complex projects, especially those involving C-bindings or unusual dependencies, might require deep understanding. It has largely been superseded by <i>dune</i> for new OCaml projects, which offers a simpler, more opinionated, and faster build experience. As such, <i>ocamlbuild</i> is more commonly encountered in older or legacy OCaml codebases.


title: TAG SYSTEM
content:
<i>ocamlbuild</i> employs a sophisticated <I>tag system</I> to control the build process. Tags are keywords (e.g., <i>native</i>, <i>thread</i>, <i>debug</i>) that can be associated with files, directories, or build targets. These tags influence which compilation flags are used, which libraries are linked, and which build rules apply. For instance, tagging a file with <i>native</i> will ensure it's compiled to native code, while <i>thread</i> indicates the need for thread-related libraries.


title: _TAGS FILE
content:
Customization and configuration in <i>ocamlbuild</i> projects are often managed through a file named <I>_tags</I> in the project directory. This plain text file allows users to declaratively specify rules for associating tags with file patterns or directories. For example, one might write '<I>&lt;src/*&gt;: pkg_unix</I>' to apply the <i>pkg_unix</i> tag to all files in the <i>src</i> directory, thereby linking the Unix library to them. This provides a flexible way to tailor the build without modifying <i>ocamlbuild</i>'s core logic.


title: HISTORY
content:
<i>ocamlbuild</i> was introduced as a standard component of the OCaml distribution starting with OCaml 3.10 (circa 2007-2008). Its aim was to provide a more automated and robust build system for OCaml projects, moving beyond simple <i>Makefiles</i> by automatically inferring dependencies and supporting common OCaml build patterns. For a period, it became the de-facto standard build tool for OCaml. However, with the emergence of <i>dune</i> (originally <i>jbuilder</i>) around the mid-2010s, which offered a simplified project setup, improved performance, and a more user-friendly experience, <i>ocamlbuild</i>'s role has diminished in new project development, though it remains maintained and is still active in many established projects.


title: PARAMETERS
content:
<b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile only. Output <i>.cmo</i> and <i>.cmi</i> files without linking.<br><br><b><b>-o</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the output executable or library file.<br><br><b><b>-I</b> <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <I>directory</I> to the list of paths searched for compiled interfaces (<i>.cmi</i>) and compiled modules (<i>.cmo</i>).<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add debugging information to the compiled code.<br><br><b><b>-w</b> <I>flags</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control warning messages. <I>flags</I> can be a combination of <i>+</i> (enable), <i>-</i> (disable), <i>@</i> (default) followed by warning tags.<br><br><b><b>-warn-error</b> <I>flags</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat specified warnings as errors.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the compiler version and exit.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a short usage summary and exit.<br><br><b><b>-pp</b> <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pipe source files through the specified external <I>command</I> (preprocessor).<br><br><b><b>-short-paths</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shorten error message paths by omitting the current directory prefix.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build a bytecode library (<i>.cma</i>) from the specified <i>.cmo</i> files.<br><br><b><b>-linkpkg</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When linking, also link the packages specified (usually handled by build systems like dune).<br><br><b><b>-pack</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pack all compiled modules into a single module.<br><br><b><b>-no-stdlib</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not add the standard library to the search path.<br><br><b><b>-open</b> <I>module</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the specified <I>module</I> at the top of each compiled file.<br><br>


title: DESCRIPTION
content:
The <b>ocamlc</b> command is the OCaml bytecode compiler, a fundamental tool in the OCaml programming language ecosystem.<br>It translates OCaml source code (<i>.ml</i> files) and module interfaces (<i>.mli</i> files) into bytecode, which can then be executed by the <b>ocamlrun</b> virtual machine.<br><br>Unlike <b>ocamlopt</b>, which generates native machine code, <b>ocamlc</b> produces architecture-independent bytecode. This makes executables compiled with <b>ocamlc</b> highly portable, requiring only the <b>ocamlrun</b> interpreter to be available on the target system.<br><br>Its primary functions include compiling individual modules into <i>.cmo</i> (compiled module) and <i>.cmi</i> (compiled interface) files, archiving multiple <i>.cmo</i> files into <i>.cma</i> (bytecode library) files, and linking these compiled units along with the OCaml standard library to produce a final bytecode executable.<br><br>Developers typically use <b>ocamlc</b> for rapid prototyping, educational purposes, or when portability across various systems is a higher priority than raw execution speed.


title: CAVEATS
content:
Bytecode executables generated by <b>ocamlc</b> require the <b>ocamlrun</b> interpreter to be present on the target system for execution. <br>While highly portable, bytecode performance is generally lower than native code compiled by <b>ocamlopt</b>, making <b>ocamlc</b> less suitable for performance-critical applications.


title: OUTPUT FILES
content:
When compiling OCaml source code, <b>ocamlc</b> produces several types of files:<br><i>.cmi</i> files: Compiled interface files, generated from <i>.mli</i> files or automatically from <i>.ml</i> files. They contain type information for a module.<br><i>.cmo</i> files: Compiled module files (bytecode objects), generated from <i>.ml</i> files. They contain the module's compiled code.<br><i>.cma</i> files: Bytecode libraries, which are archives of multiple <i>.cmo</i> files.<br>Executable files: When linking is performed, a final executable is created, which is a wrapper around the bytecode that invokes <b>ocamlrun</b>.


title: HISTORY
content:
<b>ocamlc</b> is a core component of the OCaml distribution, tracing its lineage back to the earliest versions of the OCaml language (formerly Caml Light and then Objective Caml).<br><br>Its development has run in parallel with the language itself, steadily gaining features such as improved warning systems, support for new language constructs, and integration with modern build tools. From the beginning, <b>ocamlc</b> provided the foundational capability for compiling OCaml code into portable bytecode, a critical feature for its adoption and use across diverse computing environments before native code compilation became widespread or highly optimized.<br><br>While <b>ocamlopt</b> (for native code) has gained prominence for performance-sensitive applications, <b>ocamlc</b> remains indispensable for situations prioritizing rapid compilation, cross-platform compatibility, or environments where a full native compiler toolchain might be cumbersome.


title: PARAMETERS
content:
<b><b>-I</b> <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <i>directory</i> to the list of paths searched for source files and compiled interfaces (<i>.cmi</i>). Multiple <i>-I</i> options can be specified.<br><br><b><b>-c</b> <i>channel</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a remote process using the specified <i>channel</i>. Examples include <i><I>inet:host:port</I></i> for network connections or <i><I>file:path</I></i> for local sockets.<br><br><b><b>-output-channel</b> <i>channel</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects all debugger output to the specified <i>channel</i> instead of standard output.<br><br><b><b>-port</b> <i>number</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the TCP port <i>number</i> for remote debugging when <i>ocamldebug</i> acts as a server, listening for incoming connections from the debugged program.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables searching the standard library directory for source files. Only directories specified with <i>-I</i> will be searched.<br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the OCaml debugger version string and exits.<br><br><b><b>-vnum</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the major version number of the OCaml debugger and exits.<br><br><b><b>-help</b> | <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short usage summary of command-line options and exits.<br><br><b><b>-stdlib</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the path to the standard library directory and exits.<br><br>


title: DESCRIPTION
content:
<i>ocamldebug</i> is the standard source-level debugger for OCaml bytecode programs. It empowers developers to meticulously execute their OCaml applications step-by-step, inspect the values of variables, set conditional breakpoints, and navigate the call stack. This interactive, command-line driven tool is indispensable for controlling program execution flow, navigating through source code, and diagnosing intricate runtime issues.<br><br>It exclusively operates on bytecode executables that have been compiled with the <i><I>-g</I></i> flag using <i><I>ocamlc</I></i>, which embeds the necessary debugging information. <i>ocamldebug</i> is a critical utility for understanding program behavior, identifying logical errors, and refining code within the OCaml development ecosystem.


title: CAVEATS
content:
<i>ocamldebug</i> primarily works with bytecode executables compiled by <i><I>ocamlc -g</I></i>. Debugging native code produced by <i><I>ocamlopt</I></i> is generally more complex and often requires tools like <i><I>gdb</I></i> with specific OCaml extensions or other specialized debuggers. Its interactive command-line interface, while powerful, may require a learning curve for users accustomed to graphical debugging environments.


title: KEY INTERACTIVE COMMANDS
content:
Once launched, <i>ocamldebug</i> offers a comprehensive set of commands for interacting with the debugged program. These include flow control commands like <i><I>run</I></i>, <i><I>break</I></i>, <i><I>step</I></i>, and <i><I>next</I></i> to execute and navigate code; inspection commands such as <i><I>print</I></i>, <i><I>display</I></i>, and <i><I>where</I></i> to examine variable values and the call stack; and utility commands like <i><I>list</I></i> to view source code and <i><I>quit</I></i> to exit the debugger.


title: REMOTE DEBUGGING CAPABILITIES
content:
In addition to local debugging, <i>ocamldebug</i> fully supports remote debugging scenarios. This advanced feature enables developers to debug an OCaml bytecode program executing on a different machine or within a distinct process. The debugger can operate as a server, awaiting a connection from the debugged program, or conversely, connect to a program that is acting as a debugging server. This capability is exceptionally valuable for diagnosing issues in deployed applications, on embedded systems, or within complex distributed environments.


title: HISTORY
content:
<i>ocamldebug</i> has been an indispensable component of the OCaml distribution since its inception, serving as the primary debugging utility for bytecode programs. Its evolution has closely paralleled that of the OCaml language and its bytecode interpreter, consistently providing developers with a robust mechanism to inspect and understand their programs' runtime behavior within the OCaml ecosystem.


title: PARAMETERS
content:
<b>-I <i><dir></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <i><dir></i> to the list of directories searched for compiled interfaces (<i>.cmi</i> files) when resolving module dependencies.<br><br><b>-modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a list of module names imported by the specified source files, one module name per line. This is different from the default Makefile-style output.<br><br><b>-impl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats subsequent arguments as implementation files (<i>.ml</i>, <i>.mll</i>, <i>.mly</i>), overriding the default extension-based detection.<br><br><b>-intf</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats subsequent arguments as interface files (<i>.mli</i>), overriding the default extension-based detection.<br><br><b>-raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints raw dependencies without adding suffixes (<i>.d</i>, <i>.cmo</i>, etc.) or header comments. Useful for custom parsing.<br><br><b>-resolve-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resolves file paths to their canonical form.<br><br><b>-files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the list of source files passed to <b>ocamldep</b> itself, one file per line.<br><br><b>-pp <i><command></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pipes source files through the specified preprocessor <i><command></i> before parsing. This is crucial for sources that use preprocessor directives.<br><br><b>-no-all-deps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>ocamldep</b> from adding a dependency on the pseudo-target <b>all</b> (e.g., <b>all: &lt;target&gt;</b>).<br><br><b>-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts the generated dependencies lexicographically.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>ocamldep</b> version number and exits.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose information during execution, including progress messages.<br><br><b>-help</b> or <b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of the command's options and exits.<br><br><b>-ml-synonym <i><extension></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats files with <i><extension></i> as OCaml source files (<i>.ml</i>). Useful for custom file naming conventions.<br><br><b>-as-ml <i><file.ext></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats <i><file.ext></i> as an OCaml source file for dependency analysis, regardless of its actual extension.<br><br><b>-extension <i><ext></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <i><ext></i> to the list of file extensions <b>ocamldep</b> searches for when resolving module names.<br><br>


title: DESCRIPTION
content:
<b>ocamldep</b> is a utility distributed with the OCaml compiler. Its primary function is to analyze OCaml source files (including <i>.ml</i>, <i>.mli</i>, <i>.mll</i>, and <i>.mly</i> files) and automatically generate dependency rules suitable for inclusion in Makefiles.<br><br>By examining <b>open</b> directives, module interfaces, and implicit module references, <b>ocamldep</b> determines the correct compilation order of OCaml modules. This automation is crucial for large OCaml projects, as it ensures that when a module's interface changes, all dependent modules are correctly recompiled, preventing stale binaries and simplifying the build process. It outputs rules in a format compatible with <b>make</b>, typically <i>target: dependencies</i> lines, which can be directly included in a project's Makefile.


title: CAVEATS
content:
<b>ocamldep</b> primarily relies on the textual analysis of OCaml source files. It does not inspect compiled interface files (<i>.cmi</i>) directly for dependency resolution, but rather uses the <b>-I</b> paths to locate sources when resolving module names. While it parses source files, complex build setups involving exotic preprocessors or compiler-specific pragmas might require careful handling or specific <b>-pp</b> options to ensure accurate dependency generation. It's designed for simple module dependencies, not for tracking changes in C stubs or external libraries, which must be handled by the broader build system.


title: TYPICAL MAKEFILE INTEGRATION
content:
<b>ocamldep</b> is most commonly integrated into Makefiles to automatically generate and update dependency rules. A typical setup involves defining a rule to generate <i>.d</i> files (dependency files) from OCaml source files (<i>.ml</i>, <i>.mli</i>). These generated <i>.d</i> files are then <b>include</b>d into the main Makefile, allowing <b>make</b> to automatically track changes and recompile only what's necessary. This significantly reduces manual dependency management and ensures build correctness. For example:<br><br><b>%.d: %.ml<br>	ocamldep $< &gt; $@<br><br>%.d: %.mli<br>	ocamldep $< &gt; $@<br><br>include $(wildcard *.d)</b>


title: HISTORY
content:
<b>ocamldep</b> has been a fundamental component of the OCaml distribution from its early days, evolving alongside the OCaml language and compiler. Its inclusion reflects the need for robust dependency management in compiled languages, making it an indispensable tool for automating OCaml project builds using systems like <b>make</b>. Its design aligns with the modular nature of OCaml, simplifying the often complex task of maintaining correct build orders in a highly interconnected codebase.


title: PARAMETERS
content:
<b>-c <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <I>dir</I> to the include path for finding compiled interface files (<I>.cmi</I>).<br><br><b>-d <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output directory for generated documentation files.<br><br><b>-html</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates documentation in <B>HTML</B> format.<br><br><b>-latex</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates documentation in <B>LaTeX</B> format.<br><br><b>-man</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates documentation in <B>man page</B> format.<br><br><b>-o <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file name for single-file formats (e.g., man, LaTeX, text).<br><br><b>-t <title></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the main title of the generated documentation.<br><br><b>-intro <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the content of the specified file as the introductory page.<br><br><b>-css <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom <B>CSS</B> stylesheet for <B>HTML</B> output.<br><br><b>-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts modules and types alphabetically in the generated output.<br><br><b>-hide <module></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hides the specified module from the documentation output.<br><br><b>-colorize-code</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables syntax highlighting for code examples within the documentation.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing progress and detailed information.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <I>ocamldoc</I> version and exits.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of available options and exits.<br><br>


title: DESCRIPTION
content:
<i>ocamldoc</i> is the standard documentation generator for the <B>OCaml</B> programming language. It parses OCaml source files (<I>.ml</I>, <I>.mli</I>) and their associated documentation comments (<I>(** ... *)</I>) to produce high-quality, browsable documentation in various formats.<br><br>It supports generating documentation in <B>HTML</B>, <B>LaTeX</B>, plain text, and <B>man pages</B>. It understands module structure, links between modules, and supports custom styling and formatting. It's an essential tool for OCaml projects, allowing developers to generate <B>API documentation</B> directly from their codebase, making it easier for others to understand and use the libraries and applications.


title: CAVEATS
content:
<i>ocamldoc</i> relies on <I>.cmi</I> (compiled interface) files being present in the include path to resolve types and links, similar to how <I>ocamlc</I> compiles.<br>Customization of output templates can be complex, often requiring knowledge of OCaml or specific template languages.<br>Parsing of code comments requires a specific format <I>(** ... *)</I> for proper interpretation, including special <I>@</I> tags for structured data.


title: DOCUMENTATION COMMENTS
content:
<i>ocamldoc</i> interprets comments delimited by <I>(** ... *)</I> as documentation. These comments can contain special <B>@ tags</B> (e.g., <I>@param</I>, <I>@return</I>, <I>@see</I>) for structured information, and basic <B>HTML-like formatting</B> (e.g., <I><i></I>, <I><b></I>, <I><pre></I>).


title: USAGE WITH BUILD SYSTEMS
content:
<i>ocamldoc</i> is commonly integrated into build systems like <B>Dune</B> or <B>Makefiles</B>. This automation allows documentation generation to be a seamless part of the project build process, ensuring documentation stays up-to-date with the codebase.


title: HISTORY
content:
<i>ocamldoc</i> has been a core part of the <B>OCaml</B> distribution for many years, evolving alongside the language itself. Its design emphasizes deep integration with OCaml's module system and type-checking capabilities, ensuring that generated documentation accurately reflects the codebase. From simpler beginnings, it has grown to support various output formats and extensive customization, becoming the de-facto standard for OCaml project documentation.


title: PARAMETERS
content:
<b><b>query</b> <i>&lt;package&gt;</i> [...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries information about specified packages, such as compilation flags or paths. Often used with <i>predicates</i>.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently installed OCaml packages known to <b>ocamlfind</b>.<br><br><b><b>install</b> <i>&lt;package_name&gt;</i> <i>&lt;files&gt;</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a new OCaml package into the <b>ocamlfind</b> library directory. Requires administrative privileges for system-wide installation.<br><br><b><b>remove</b> <i>&lt;package_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed OCaml package.<br><br><b><b>printconf</b> <i>&lt;variable&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the value of a configuration variable, such as the <b>path</b> where libraries are searched or the <b>version</b> of OCaml.<br><br><b><b>rpath</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resolves a given path by substituting <b>ocamlfind</b> variables (e.g., <i>$ocamlfind_prefix</i>).<br><br><b><b>lint</b> <i>&lt;package&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks an installed package for common issues and best practices.<br><br><b><b>help</b> [<i>&lt;command&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help or detailed help for a specific <b>ocamlfind</b> command.<br><br>


title: DESCRIPTION
content:
<b>ocamlfind</b> is a powerful and indispensable utility in the OCaml programming language ecosystem. Its primary purpose is to simplify the discovery and management of OCaml libraries and packages during compilation and linking. Rather than requiring developers to specify absolute file paths for every library, <b>ocamlfind</b> allows referring to them by their logical package names (e.g., <i>unix</i>, <i>threads</i>, <i>str</i>).<br><br>It works by maintaining a database of installed OCaml packages, typically located in directories defined by the <b>OCAMLPATH</b> environment variable or the default system library path. When invoked, <b>ocamlfind</b> can query this database to provide the correct compiler flags (e.g., <i>-I</i>, <i>-cclib</i>) or file paths (<i>.cmi</i>, <i>.cmo</i>, <i>.cmx</i>, <i>.a</i>) needed by <b>ocamlc</b>, <b>ocamlopt</b>, and other OCaml tools.<br><br>Beyond simple path resolution, <b>ocamlfind</b> supports complex queries using <i>predicates</i>, allowing users to select specific variants of a library (e.g., native code, bytecode, syntax extensions). It also includes subcommands for installing, removing, listing, and linting packages, making it a comprehensive tool for library management in OCaml projects. Although package managers like Opam often handle the initial installation of libraries, <b>ocamlfind</b> remains the foundational layer for OCaml compilers to locate and utilize those libraries.


title: CAVEATS
content:
<b>ocamlfind</b> primarily manages packages installed in a specific directory structure. It might not automatically discover packages installed by other means if they are not correctly registered or placed in <b>ocamlfind</b>'s search paths.<br><br>Modifying system-wide <b>ocamlfind</b> libraries (e.g., using <b>install</b> or <b>remove</b> without a custom <b>OCAMLPATH</b>) often requires root privileges, which should be used with caution.<br><br>Managing packages with <b>ocamlfind</b> directly can be complex for large projects. Modern OCaml development often relies on build systems like Dune and package managers like Opam, which abstract away many direct <b>ocamlfind</b> invocations.


title: PREDICATES
content:
Predicates are keywords used with the <b>query</b> command to specify attributes or variants of a package that <b>ocamlfind</b> should consider. Examples include <i>byte</i> (for bytecode libraries), <i>native</i> (for native code libraries), <i>syntax</i> (for syntax extensions), <i>ppx</i> (for PPX preprocessors), and <i>plugin</i> (for compiler plugins). They allow <b>ocamlfind</b> to select the correct files or compilation flags based on the context.


title: OCAMLPATH ENVIRONMENT VARIABLE
content:
The <b>OCAMLPATH</b> environment variable is crucial for <b>ocamlfind</b>. It specifies a colon-separated list of directories where <b>ocamlfind</b> should search for OCaml libraries and packages. If not set, <b>ocamlfind</b> defaults to system-wide paths. Users can set this variable to manage custom or project-specific library locations without needing root access.


title: HISTORY
content:
<b>ocamlfind</b> was created by <i>Gerd Stolpmann</i> and first released in the early 2000s. It quickly became the de-facto standard for managing OCaml libraries due to its ability to abstract away physical library paths and provide a consistent interface for developers. Before the widespread adoption of package managers like Opam, <b>ocamlfind</b> was often used directly for installing and configuring OCaml libraries. While Opam now handles the installation of packages, <b>ocamlfind</b> remains a fundamental underlying component, as Opam installs packages in a way that <b>ocamlfind</b> can discover and use. Its stable design has ensured its continued relevance in the OCaml ecosystem.


title: PARAMETERS
content:
<b><b>-o</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file name for the executable or library.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile source files into native object files (<I>.cmx</I>) without linking.<br><br><b><b>-I</b> <I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <I>dir</I> to the list of directories searched for compiled interface (<I>.cmi</I>) and native object (<I>.cmx</I>) files.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add debugging information to the compiled code, enabling more effective debugging with tools like <I>gdb</I>.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output assembly code (<I>.s</I> file) for each source file instead of machine code.<br><br><b><b>-unsafe</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable faster but potentially unsafe integer arithmetic and array accesses, by disabling bounds checks and overflow checks.<br><br><b><b>-shared</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build a shared library (<I>.so</I> or <I>.dll</I>) instead of an executable.<br><br><b><b>-inline</b> <I>n</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set inlining aggressiveness; <I>n</I> is a numeric value (higher means more inlining).<br><br><b><b>-cc</b> <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <I>command</I> as the C compiler for linking and compiling C stubs.<br><br><b><b>-cclib</b> <I>lib</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass the C library <I>lib</I> to the C linker (e.g., <I>-cclib -lfoo</I> to link <I>libfoo.a</I> or <I>libfoo.so</I>).<br><br><b><b>-ccopt</b> <I>option</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass <I>option</I> directly to the C compiler or linker (e.g., <I>-ccopt -O2</I>).<br><br><b><b>-fPIC</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate position-independent code (required for shared libraries on some systems and for certain dynamic linking scenarios).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version number of the OCaml compiler and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a summary of available command-line options.<br><br>


title: DESCRIPTION
content:
<I>ocamlopt</I> is the optimizing native-code compiler for the OCaml programming language. Unlike <I>ocamlc</I>, which compiles OCaml source code into bytecode that runs on the OCaml virtual machine, <I>ocamlopt</I> translates OCaml source files (<I>.ml</I>, <I>.mli</I>) and compiled interface/object files (<I>.cmi</I>, <I>.cmx</I>) directly into machine code. This results in standalone executables or shared libraries that can be run without the OCaml runtime interpreter, often offering significant performance improvements.<br><br>It performs various optimizations such as register allocation, common subexpression elimination, and inlining. <I>ocamlopt</I> is typically used for deploying performance-critical OCaml applications and handles linking with C code and C libraries.


title: CAVEATS
content:
Debugging native code generated by <I>ocamlopt</I> can be more complex than debugging bytecode, often requiring platform-specific tools like <I>gdb</I>.<br>Compiled executables are platform-specific (e.g., Linux x86-64 executables won't run on Windows ARM).<br>Building mixed OCaml/C applications requires careful management of C stubs and linking configurations.


title: COMPILATION PHASES
content:
<I>ocamlopt</I> typically processes OCaml source files (<I>.ml</I>, <I>.mli</I>) into native object files (<I>.cmx</I>) in a compilation phase. Subsequently, these <I>.cmx</I> files (along with any <I>.c</I> files or C libraries) are linked into a final executable or shared library in a separate linking phase.


title: CMX VS. CMO FILES
content:
While <I>ocamlc</I> produces <I>.cmo</I> (bytecode object) files, <I>ocamlopt</I> produces <I>.cmx</I> (native code object) files. These <I>.cmx</I> files contain machine code and are suitable for linking into native executables, whereas <I>.cmo</I> files are linked into bytecode executables or interpreted by the <I>ocaml</I> toplevel.


title: HISTORY
content:
The OCaml language, originally known as Caml Light and later Caml, was developed at INRIA (Institut national de recherche en informatique et en automatique) in France, building upon the ML (Meta Language) family. <I>ocamlopt</I> was introduced as a key component of the OCaml distribution to provide an optimizing native-code compiler, addressing the demand for high-performance applications that could not be fully met by the bytecode compiler (<I>ocamlc</I>). Its continuous development has focused on improving performance, supporting new architectures, and integrating advanced compilation techniques.


title: PARAMETERS
content:
<b><i>-geometry &lt;geometry&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the initial size and position of the clock window, e.g., <i>80x80+10+10</i>.<br><br><b><i>-display &lt;display&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines which X server to connect to, useful in multi-display environments.<br><br><b><i>-fg &lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the foreground color, affecting the clock hands, numbers, and tick marks.<br><br><b><i>-bg &lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the background color of the clock's face.<br><br><b><i>-bd &lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the color of the window border.<br><br><b><i>-bw &lt;pixels&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the width of the window border in pixels.<br><br><b><i>-digital</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the clock display to a digital numerical format within the round face.<br><br><b><i>-analog</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the traditional analog hand-based display format (this is the default).<br><br><b><i>-chime</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables an audible chime on the hour and half-hour.<br><br><b><i>-update &lt;milliseconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the interval at which the clock updates its display, in milliseconds. Lower values mean smoother second hand movement but higher CPU usage.<br><br><b><i>-shape</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests a shaped window, allowing for a truly circular clock without a rectangular background (if supported by the X server and window manager).<br><br>


title: DESCRIPTION
content:
<i>oclock</i> is a traditional analog clock application designed for the X Window System. It graphically displays the current time with rotating hour, minute, and second hands. Known for its distinct round shape, it can also be configured to show time in a digital format within its circular face. It serves as a simple, unobtrusive desktop widget, often launched as part of a user's X session or through a window manager. As a lightweight graphical utility, <i>oclock</i> remains a testament to the early days of graphical computing on Unix-like systems, providing a basic yet functional time display without significant resource overhead. It provides a straightforward and classic visual representation of time for X users.


title: CAVEATS
content:
<i>oclock</i> is a graphical X application and requires an active X Window System environment to run. It is not suitable for command-line scripting on headless servers or for users without a graphical desktop. Its design is minimalistic, offering basic time display without advanced features found in modern desktop widgets.


title: X RESOURCES
content:
<i>oclock</i>, like many X applications, can be extensively configured via X resource files such as <i>~/.Xdefaults</i> or <i>~/.Xresources</i>. These files allow users to define default settings for colors, fonts, geometry, and other attributes without using command-line options.<br><br><b>Example:</b><br><i>Oclock*background: midnightblue<br>Oclock*foreground: lightgray<br>Oclock*chime: true</i><br><br>These settings are loaded by the X server or applications, providing persistent customization. After modifying <i>~/.Xresources</i>, it's often necessary to run <i>xrdb -load ~/.Xresources</i> to apply changes.


title: DESKTOP INTEGRATION
content:
In older window managers (like <i>fvwm</i>, <i>twm</i>) or minimalist desktop environments, <i>oclock</i> was often explicitly launched as a standalone application or 'docked' into a panel. It can be run from a terminal in an X session, or included in a startup script like <i>~/.xinitrc</i> or a desktop environment's autostart mechanism to appear automatically upon login. Its round shape and simplicity made it a popular choice for integrating into various custom desktop layouts.


title: HISTORY
content:
<i>oclock</i> emerged as an early utility within the X Window System, originally developed by Dave Mankins at MIT in 1988. It quickly became a standard inclusion in various <i>xorg-apps</i> or <i>x11-apps</i> packages across Unix-like operating systems. Its enduring presence underscores its foundational role in providing basic graphical desktop functionality in the nascent stages of graphical user interfaces on Linux and Unix systems. It remains maintained as part of the X.Org project.


title: SYNOPSIS
content:
ocrmypdf [OPTIONS] <input_pdf> <output_pdf><br><i>or</i><br>ocrmypdf [OPTIONS] <b>--inplace</b> <pdf_file>


title: PARAMETERS
content:
<b><b>-l</b> <i>LANGUAGE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the language(s) for OCR, e.g., 'eng+fra'. Requires corresponding Tesseract language data installed.<br><br><b><b>--force-ocr</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces OCR to run on all pages, even if they appear to contain text already.<br><br><b><b>--redo-ocr</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces OCR to rerun on pages that already have an OCR layer, useful for correcting errors or changing OCR options.<br><br><b><b>--inplace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites the input PDF file with the OCR-processed version instead of creating a new file.<br><br><b><b>--deskew</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to detect and correct skewed pages in the input PDF, improving OCR accuracy.<br><br><b><b>--optimize</b> <i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimizes image compression for the output PDF. <i>N</i> is a level (0-3), with 3 providing the highest compression.<br><br><b><b>--sidecar</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the OCR text in a separate plain text or hOCR (HTML) file alongside the output PDF.<br><br><b><b>--output-type</b> <i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output PDF conformance, e.g., 'pdfa-1', 'pdfa-2', 'pdfa-3', or 'pdf' (default for standard PDF).<br><br><b><b>--j</b> <i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of parallel jobs (pages processed concurrently) to utilize CPU cores efficiently.<br><br>


title: DESCRIPTION
content:
<i>ocrmypdf</i> is a powerful free and open-source command-line tool designed to add an OCR (Optical Character Recognition) text layer to scanned PDF documents. It works by intelligently processing each page, using the <I>Tesseract OCR engine</I> to recognize text, and then embedding this text as an invisible layer beneath the original page image. This transformation makes previously unsearchable scanned PDFs fully searchable and selectable, without altering their visual appearance. <i>ocrmypdf</i> can handle various document types, including those with mixed content, and offers features like image optimization, deskewing, and automatic page rotation to produce high-quality, compact, and searchable PDFs. It's widely used for digitizing and archiving paper documents.


title: CAVEATS
content:
OCR quality is highly dependent on the input PDF's image quality. Poor scans, low resolution, or complex fonts can result in inaccurate text recognition. The process can be CPU and memory intensive, especially for large documents or many concurrent jobs. While it adds a searchable text layer, it does not convert the PDF into an editable document. Users must ensure that the <I>Tesseract OCR engine</I> and required language packs are installed on their system for <i>ocrmypdf</i> to function correctly.


title: <B>PDF/A CONFORMANCE</B>
content:
<i>ocrmypdf</i> can generate output PDFs conforming to PDF/A (Portable Document Format for Archiving) standards, such as PDF/A-1b, PDF/A-2b, or PDF/A-3b. This is crucial for long-term archival of documents, ensuring their accessibility and readability across different software and future technologies.


title: <B>PREREQUISITES</B>
content:
For <i>ocrmypdf</i> to function, the <I>Tesseract OCR engine</I> must be installed on your system. Additionally, you need to install the specific <I>Tesseract language data packs</I> for any languages you intend to OCR (e.g., 'tesseract-ocr-eng' for English on Debian/Ubuntu-based systems).


title: HISTORY
content:
<i>ocrmypdf</i> was initially developed by Klemens Böhm, with its first stable release appearing around 2014. It emerged as a practical solution to automate the process of adding OCR text layers to scanned PDFs, leveraging the powerful <I>Tesseract OCR engine</I>. Since its inception, it has been maintained as an active open-source project on GitHub, continuously evolving with new features, optimizations, and bug fixes, thanks to contributions from a community of developers. Its robust design and ease of use have made it a popular choice for digitizing documents in both personal and professional contexts.


title: PARAMETERS
content:
<b>-url <responder_url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the URL of the OCSP responder to which the request should be sent.</i><br><br><b>-cert <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The path to the certificate file whose status is to be checked.</i><br><br><b>-issuer <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The path to the issuer certificate file of the certificate being checked.</i><br><br><b>-reqout <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Writes the raw OCSP request to the specified file.</i><br><br><b>-respout <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Writes the raw OCSP response to the specified file.</i><br><br><b>-text</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the OCSP request and response in a human-readable text format.</i><br><br><b>-CAfile <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies a file containing trusted CA certificates for verifying the OCSP responder's signature.</i><br><br><b>-CApath <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies a directory containing trusted CA certificates.</i><br><br><b>-noverify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables the verification of the OCSP response signature. Use with caution, mainly for testing.</i><br><br><b>-index <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Responder mode) Specifies the certificate database index file (e.g., 'index.txt') used by the responder to determine certificate status.</i><br><br><b>-rsigner <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Responder mode) The certificate used by the OCSP responder to sign its responses.</i><br><br><b>-rkey <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Responder mode) The private key corresponding to the responder's signing certificate.</i><br><br><b>-port <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Responder mode) Specifies the port number on which the OCSP responder will listen for incoming requests.</i><br><br><b>-header <field:value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adds an arbitrary HTTP header to the request sent to the OCSP responder.</i><br><br><b>-no_nonce</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables the inclusion of an OCSP nonce in the request, which can help prevent replay attacks but may not be supported by all responders.</i><br><br>


title: DESCRIPTION
content:
The <b>ocsp</b> command, part of the OpenSSL toolkit, implements a simple <i>OCSP (Online Certificate Status Protocol)</i> client and a basic test responder. As a client, it's used to query OCSP responders to determine the revocation status of <b>X.509 certificates</b> in real-time, providing an alternative to relying solely on Certificate Revocation Lists (CRLs). It sends an OCSP request for a specific certificate and parses the response, indicating whether the certificate is <i>good</i>, <i>revoked</i>, or <i>unknown</i>.<br><br>In its responder mode, <b>ocsp</b> can act as a lightweight, non-production OCSP server. This mode is primarily intended for testing, development, and debugging purposes, allowing users to simulate an OCSP responder and test their client implementations or certificate revocation processes. The command supports various options for specifying certificates, responders, output formats, and verification parameters, making it a versatile tool for certificate lifecycle management and security testing.


title: CAVEATS
content:
The <b>ocsp</b> command's responder mode is designed for testing and development, <i>not for production use</i>. A full-fledged OCSP responder requires robust handling of high traffic, secure key management, and detailed logging, which are beyond the scope of this utility.<br><br>Proper certificate chain validation is crucial for accurate OCSP response verification; ensure that the <b>-CAfile</b> or <b>-CApath</b> options point to a complete set of trusted certificates.<br><br>Without proper network connectivity to the OCSP responder, the client mode will fail to retrieve status information. Firewalls or proxy settings might need configuration to allow OCSP traffic.


title: OCSP PROTOCOL OVERVIEW
content:
OCSP allows a client to determine the revocation status of a certificate without requiring the client to download and parse potentially large CRLs. Instead, the client sends a specific query to an OCSP responder, which returns a signed response indicating if the certificate is 'good', 'revoked', or 'unknown'. This real-time lookup is especially beneficial for time-sensitive applications or when network bandwidth is limited.


title: CLIENT VS. RESPONDER MODES
content:
The <b>ocsp</b> command operates in two primary modes: <i>client</i> and <i>responder</i>.<br><br>In <b>client mode</b> (default), it constructs and sends an OCSP request for one or more certificates to a specified OCSP responder URL. It then receives, parses, and verifies the responder's signed response, displaying the revocation status.<br><br>In <b>responder mode</b>, the command simulates an OCSP server. It listens on a specified port for incoming OCSP requests, looks up the status of the requested certificates in a local certificate database (e.g., an OpenSSL 'index.txt' file), signs the appropriate response, and sends it back to the client. This mode is invaluable for developing and testing OCSP-aware applications or for understanding OCSP protocol interactions.


title: HISTORY
content:
The <i>Online Certificate Status Protocol (OCSP)</i> was defined in <b>RFC 2560</b> in 1999 as a real-time alternative to Certificate Revocation Lists (CRLs) for checking certificate revocation status. The <b>ocsp</b> command has been an integral part of the OpenSSL toolkit for many years, evolving alongside the OpenSSL library's continuous development. It provides a command-line interface to interact with OCSP, making it a widely used tool for cryptographic operations and security testing within the Linux ecosystem.


title: PARAMETERS
content:
<b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the initial Octave banner and copyright message.<br><br><b><b>-f</b>, <b>--no-init-file</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent Octave from executing the user's <i>~/.octaverc</i> startup file.<br><br><b><b>--no-history</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not load or save the command history.<br><br><b><b>--no-gui</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force Octave to start in the command-line interface (CLI) mode, even if a graphical environment is available.<br><br><b><b>--gui</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force Octave to start in graphical user interface (GUI) mode.<br><br><b><b>-p</b> <i>DIR</i>, <b>--path</b> <i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add the directory <i>DIR</i> to Octave's function search path.<br><br><b><b>-B</b>, <b>--batch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run Octave in batch mode. In this mode, Octave exits after processing input files or evaluating commands.<br><br><b><b>-x</b>, <b>--exit-on-error</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit Octave if an error occurs during execution of a script or command.<br><br><b><b>--eval</b> <i>CODE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluate the Octave code string <i>CODE</i> and then exit.<br><br><b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A script file to execute. Octave will execute the commands in <i>FILE</i> and then exit (unless <b>--persist</b> is used or in interactive mode).<br><br>


title: DESCRIPTION
content:
GNU Octave is a powerful, free, and open-source programming language for numerical computations. It offers a high-level interpreter primarily designed for numerical analysis, scientific computing, and data visualization. Its syntax is largely compatible with MATLAB, making it a popular alternative for engineers, scientists, and students. <br> Octave supports complex numbers, matrices, and a rich set of built-in functions for linear algebra, Fourier transforms, signal processing, image manipulation, and statistical analysis. It can execute scripts and functions written in its own language, and also supports calling C++, Fortran, and other language code. Users can extend Octave's capabilities through various packages, providing specialized functionalities for different domains. It provides both an interactive command-line interface and a graphical user interface (GUI).


title: CAVEATS
content:
While highly compatible with MATLAB, some advanced or specialized MATLAB toolboxes might not have direct Octave equivalents or require different syntax. <br> Performance for very large datasets or extremely complex parallel computations might sometimes differ from highly optimized commercial alternatives. <br> The graphical user interface (GUI) features might be less mature or feature-rich compared to commercial counterparts, though they are constantly improving.


title: PACKAGE SYSTEM
content:
Octave features a robust package system, similar to other scripting languages. Users can install and load specialized packages from the Octave Forge repository (e.g., <i>pkg install control</i>, <i>pkg load control</i>) to extend its functionality for specific domains like signal processing, image processing, or symbolic math.


title: PLOTTING
content:
Octave supports extensive 2D and 3D plotting capabilities, largely compatible with MATLAB's plotting functions. It can use Gnuplot as its default backend, but also supports FLTK and Qt for interactive plots, and OpenGL for advanced 3D graphics.


title: HISTORY
content:
Development began in 1988 by John W. Eaton. Its first alpha release was in 1993, followed by the first stable release (version 1.0) in February 1994. The project was named after Octave Levenspiel, a professor known for his quick calculations. Octave has since been continually developed and maintained as part of the GNU Project, evolving to include a graphical user interface, enhanced MATLAB compatibility, and a robust package system.


title: SYNOPSIS
content:
<b>octez-client</b> [<i>global options</i>] <<i>command</i>> [<i>command options</i>] [<i>arguments</i>]<br><br>Examples:<br><i>octez-client get balance for <alias_or_address></i><br><i>octez-client transfer <amount> from <source> to <destination> --fee <fee> --dry-run</i><br><i>octez-client originate contract <contract_name> for <delegate> transferring <amount> from <source> running <contract_path> --init '<initial_storage>' --burn-cap <burn_cap></i>


title: PARAMETERS
content:
<b>--base-dir <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where client data (e.g., wallet, client configuration) is stored. Default is <i>~/.tezos-client</i>.<br><br><b>--endpoint <uri></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the RPC endpoint of the Tezos node to connect to (e.g., <i>http://localhost:8732</i>).<br><br><b>--block <block_id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the block to use for queries (e.g., <i>head</i>, <i>genesis</i>, a specific hash or level).<br><br><b>--chain <chain_id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the chain ID to interact with (e.g., <i>main</i>, <i>test</i>).<br><br><b>--force, --no-confirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips confirmation prompts for critical operations, proceeding without user intervention.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates an operation without sending it to the Tezos network, showing potential outcomes and fees.<br><br><b>--fee <amount></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the transaction fee in mutez to include with the operation.<br><br><b>--burn-cap <amount></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum amount of tez to burn for contract storage or gas.<br><br><b>--verbose-signing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the byte stream being signed for an operation, useful for verification.<br><br>


title: DESCRIPTION
content:
The <b>octez-client</b> is the primary command-line interface for interacting with the Tezos blockchain. It allows users to perform a wide range of operations, including managing Tezos accounts (generating keys, importing/exporting private keys, setting aliases), sending tez (the native cryptocurrency), deploying and interacting with smart contracts written in Michelson or high-level languages like SmartPy or Ligo, and querying the blockchain state such as account balances, block information, and contract storage.<br><br>The client connects to a running Octez node, which synchronizes with the Tezos network. It supports various network configurations, allowing connection to mainnet, testnets, or local development networks. <b>octez-client</b> is an essential tool for developers, bakers, and users who prefer command-line interaction over graphical user interfaces to manage their Tezos assets and participate in the ecosystem. It abstracts away the complexities of the underlying RPC calls, providing a user-friendly interface for common blockchain operations.


title: CAVEATS
content:
<b>Node Dependency:</b> <b>octez-client</b> requires a running Octez node to connect to, either locally or remotely. Without a synchronized node, it cannot perform network operations.<br><b>Complexity:</b> While powerful, the command-line interface can be complex for new users due to the wide array of commands, options, and Tezos-specific concepts (e.g., mutez, delegates, smart contract storage).<br><b>Key Security:</b> Private keys stored locally in the client's base directory are susceptible to local security breaches. Users must ensure their systems are secure and consider hardware wallets for significant funds.<br><b>Network Latency:</b> Operations involving the network are subject to network latency and node synchronization status, which can affect response times and transaction confirmation.


title: KEY MANAGEMENT
content:
<b>octez-client</b> provides robust capabilities for managing cryptographic keys, including generating new key pairs, importing existing ones, setting aliases for addresses, and interacting with hardware security modules (HSMs) or remote signers. This is crucial for securing assets and signing operations on the Tezos network.


title: RPC INTERACTION
content:
Under the hood, <b>octez-client</b> translates user commands into RPC (Remote Procedure Call) requests that are sent to a connected Octez node. This abstraction layer simplifies blockchain interactions, allowing users to perform complex operations without needing to understand the intricacies of the Tezos RPC API directly.


title: HISTORY
content:
The <b>octez-client</b> command is part of the Octez software suite, which constitutes the reference implementation of the Tezos protocol. It evolved from its predecessor, <i>tezos-client</i>, as part of the broader rebranding of the Tezos node and associated tools to Octez. This change reflects the project's continuous development, modularity, and focus on providing a robust and extensible blockchain platform. Its functionality has expanded significantly with each Tezos protocol upgrade, introducing new features for smart contracts, governance, and economic models.


title: SYNOPSIS
content:
<b>od</b> [<i>OPTION</i>]... [<i>FILE</i>]...<br><b>od</b> -t <i>TYPE</i> [<i>OPTION</i>]... [<i>FILE</i>]...


title: PARAMETERS
content:
<b>-A RADIX, --address-radix=RADIX</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the base (<i>RADIX</i>) for displaying file offsets. Common options include <i>d</i> (decimal), <i>o</i> (octal), <i>x</i> (hexadecimal), or <i>n</i> (none).<br><br><b>-t TYPE, --format=TYPE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format. <i>TYPE</i> is a string that can combine character type and size, e.g., <i>a</i> (named char), <i>c</i> (ASCII char), <i>d[SIZE]</i> (decimal), <i>f[SIZE]</i> (float), <i>o[SIZE]</i> (octal), <i>x[SIZE]</i> (hexadecimal). <i>SIZE</i> can be <i>1</i>, <i>2</i>, <i>4</i>, <i>8</i>, or type codes like <i>C</i> (char), <i>S</i> (short), <i>I</i> (int), <i>L</i> (long).<br><br><b>-j BYTES, --skip-bytes=BYTES</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips <i>BYTES</i> bytes from the beginning of the input before dumping. <i>BYTES</i> can be followed by <i>b</i> for blocks (512 bytes), <i>k</i> for kilobytes, <i>m</i> for megabytes, etc.<br><br><b>-N BYTES, --read-bytes=BYTES</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the output to a maximum of <i>BYTES</i> bytes from the input.<br><br><b>-v, --output-duplicates</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all input data explicitly. By default, <b>od</b> replaces lines of identical content with a single line containing an asterisk (<i>*</i>).<br><br><b>-w[BYTES], --width[=BYTES]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of input bytes displayed per output line. If <i>BYTES</i> is omitted, it defaults to 32 bytes.<br><br><b>-b, --octal-bytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays bytes in octal (equivalent to <i>-t o1</i>).<br><br><b>-c, --characters</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interprets bytes as ASCII characters or backslash escapes (equivalent to <i>-t c</i>).<br><br><b>-d, --decimal</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <i>short</i> decimal words (equivalent to <i>-t u2</i>, unsigned 2-byte decimal).<br><br><b>-x, --hex-long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <i>long</i> hexadecimal words (equivalent to <i>-t x4</i>).<br><br><b>-o, --octal</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <i>short</i> octal words (equivalent to <i>-t o2</i>).<br><br>


title: DESCRIPTION
content:
The <b>od</b> (octal dump) command is a Unix utility used to display the contents of files in various human-readable formats, such as octal, hexadecimal, decimal, ASCII characters, and floating-point representations. It is primarily used for debugging, examining binary files, or inspecting files that contain non-printable characters. By default, <b>od</b> displays the file content in octal bytes, but its strength lies in its extensive formatting options, allowing users to specify the output radix (base), byte grouping, and data type. It can also skip a certain number of bytes from the input or limit the number of bytes read, making it invaluable for analyzing specific sections of large files.


title: CAVEATS
content:
While powerful for low-level inspection, <b>od</b> is not suitable for editing files. Its output can be very verbose for large files, making specific data points hard to locate without filtering. Interpretation of multi-byte data types can be sensitive to system endianness, which can sometimes be controlled but requires careful consideration. The traditional <b>od</b> syntax (e.g., specifying an offset as a non-option argument) can be confusing and is generally less flexible than the modern option-based syntax.


title: DEFAULT OUTPUT BEHAVIOR
content:
By default, <b>od</b> will replace sequences of identical output lines (except the first and last lines) with a single asterisk (<i>*</i>) on a line by itself. This behavior can be suppressed using the <i>-v</i> or <i>--output-duplicates</i> option for a complete dump of the file.


title: FLEXIBLE FORMATTING WITH -T
content:
The <i>-t TYPE</i> option is extremely versatile. For instance, <i>-t x1</i> dumps in hexadecimal bytes, <i>-t d4</i> dumps in 4-byte decimal integers, and <i>-t fL</i> dumps in long double-precision floating-point numbers. Combining different <i>TYPE</i> specifiers (e.g., <i>-t cx2</i>) can display character and 2-byte hexadecimal values side-by-side, offering a comprehensive view.


title: HISTORY
content:
The <b>od</b> command has a long history, originating in early versions of Unix. It was part of the original AT&T Unix and has been a standard utility in Unix-like operating systems ever since. It is specified in POSIX and is included in the GNU Core Utilities, which are fundamental components of GNU/Linux distributions. Its primary usage has remained consistent: providing a byte-level view of file contents for debugging and analysis.


title: SYNOPSIS
content:
<i>odbcinst</i> [<i>general_options</i>] <i>command</i> <i>target</i> [<i>target_options_and_arguments</i>]<br><br><b>Commands/Actions:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-i</b> | <b>--install</b>: Install a driver or DSN.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-u</b> | <b>--uninstall</b>: Uninstall a driver or DSN.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-q</b> | <b>--query</b>: Query/list installed drivers or DSNs.<br><br><b>Targets:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-d</b> | <b>--driver</b>: Operate on an ODBC driver.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-s</b> | <b>--system</b>: Operate on a system DSN.<br><br><b>Examples of Usage:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Install Driver:</i> <b>odbcinst -i -d -f</b> <i>&lt;path/to/driver_template.ini&gt;</i><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uninstall Driver:</i> <b>odbcinst -u -d -n</b> <i>&lt;driver_name&gt;</i><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Query Drivers:</i> <b>odbcinst -q -d</b> [<b>-n</b> <i>&lt;driver_name&gt;</i>]<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Install System DSN:</i> <b>odbcinst -i -s -n</b> <i>&lt;DSN_name&gt;</i> <b>-t</b> <i>&lt;driver_name&gt;</i> [<b>-r</b> <i>&lt;description&gt;</i>] [<i>...other_dsn_attributes...</i>]<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uninstall System DSN:</i> <b>odbcinst -u -s -n</b> <i>&lt;DSN_name&gt;</i><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Query System DSNs:</i> <b>odbcinst -q -s</b> [<b>-n</b> <i>&lt;DSN_name&gt;</i>]<br><br><b>General Options:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-v</b> | <b>--verbose</b>: Enable verbose output.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-l</b> | <b>--longlist</b>: For query operations, show long list details.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-h</b> | <b>--help</b>: Display help message.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>--version</b>: Display version information.


title: PARAMETERS
content:
<b><b>-i</b> | <b>--install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install or register an ODBC driver or a system DSN based on the specified target.<br><br><b><b>-u</b> | <b>--uninstall</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstall or unregister an ODBC driver or a system DSN. Requires the name to be specified with <b>-n</b>.<br><br><b><b>-q</b> | <b>--query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query or list installed ODBC drivers or system DSNs. Can be filtered by name using <b>-n</b>.<br><br><b><b>-d</b> | <b>--driver</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that the operation should be performed on an ODBC driver.<br><br><b><b>-s</b> | <b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that the operation should be performed on a system Data Source Name (DSN).<br><br><b><b>-f</b> <i>&lt;file&gt;</i> | <b>--file</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-i -d</b> to provide a template <i>.ini</i> file for driver installation. The file contains properties for the driver.<br><br><b><b>-n</b> <i>&lt;name&gt;</i> | <b>--name</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the driver or DSN for uninstall or query operations, or the name of the DSN for installation.<br><br><b><b>-t</b> <i>&lt;drivername&gt;</i> | <b>--tdriver</b> <i>&lt;drivername&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-i -s</b> to specify the name of the ODBC driver that the new DSN will use.<br><br><b><b>-r</b> <i>&lt;description&gt;</i> | <b>--rdesc</b> <i>&lt;description&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-i -s</b> to provide a descriptive remark for the new DSN.<br><br><b><b>-c</b> <i>&lt;connectionstring&gt;</i> | <b>--connection</b> <i>&lt;connectionstring&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-i -s</b> to specify connection attributes for the new DSN, e.g., 'SERVER=localhost;PORT=5432'.<br><br><b><b>-h</b> <i>&lt;hostname&gt;</i> | <b>--hostname</b> <i>&lt;hostname&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-i -s</b>, although less common, can be used to specify the hostname for certain DSN configurations.<br><br><b><b>-v</b> | <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the operation's progress and potential issues.<br><br><b><b>-l</b> | <b>--longlist</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-q</b> to display more detailed information about drivers or DSNs, beyond just their names.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message with command usage and options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <i>odbcinst</i> utility.<br><br>


title: DESCRIPTION
content:
<i>odbcinst</i> is a command-line utility provided by the <i>unixODBC</i> project. It's primarily used for administering ODBC drivers and Data Source Names (DSNs) on Unix-like operating systems. This tool allows users to register and unregister ODBC drivers, create and remove system DSNs, and list existing configurations. It interacts with the <i>odbc.ini</i> and <i>odbcinst.ini</i> configuration files, which define DSNs and installed drivers respectively. <i>odbcinst</i> simplifies the process of setting up database connectivity for applications that rely on ODBC, ensuring that applications can locate and connect to the correct database drivers. It's an essential tool for developers and administrators working with ODBC-enabled applications in a Linux environment.


title: CAVEATS
content:
<ul><li>Changing system-wide ODBC configurations (drivers and system DSNs) typically requires root privileges (or <b>sudo</b>).</li><li><i>odbcinst</i> relies on the correct functioning and location of <i>odbcinst.ini</i> and <i>odbc.ini</i> configuration files. Incorrect permissions or syntax in these files can lead to errors.</li><li>Error messages from <i>odbcinst</i> can sometimes be generic. Using the <b>-v</b> (verbose) option can help in diagnosing problems.</li><li><i>odbcinst</i> manages <i>system DSNs</i> only. <i>User DSNs</i>, which are defined in a user's home directory (e.g., <i>~/.odbc.ini</i>), are not managed by this utility.</li></ul>


title: CONFIGURATION FILES
content:
<i>odbcinst</i> primarily interacts with two crucial configuration files: <i>odbcinst.ini</i> and <i>odbc.ini</i>. The <i>odbcinst.ini</i> file stores information about installed ODBC drivers, including their path and associated setup libraries. The <i>odbc.ini</i> file defines Data Source Names (DSNs), which are aliases that provide connection parameters for specific databases using registered drivers. These files are typically located in system-wide directories like <i>/etc/</i> or <i>/usr/local/etc/</i>.


title: DRIVER VS. DSN MANAGEMENT
content:
It's vital to distinguish between managing drivers and managing DSNs with <i>odbcinst</i>. Installing a <b>driver</b> (using <b>-i -d</b>) registers the driver's shared library and its properties with the ODBC driver manager. Installing a <b>DSN</b> (using <b>-i -s</b>), on the other hand, creates a named set of connection parameters that an application can use to connect to a specific database instance. A DSN always relies on an already installed and configured driver.


title: HISTORY
content:
<i>odbcinst</i> is an integral part of the <i>unixODBC</i> project, an open-source ODBC driver manager designed for Unix-like systems. The project emerged in the late 1990s to bridge the gap in ODBC connectivity on non-Windows platforms, adhering closely to the ODBC specification established by Microsoft. Since its inception, <i>unixODBC</i>, and by extension <i>odbcinst</i>, has been a critical tool for developing cross-platform database applications. It enables applications built with ODBC to connect seamlessly to various databases such as MySQL, PostgreSQL, and SQL Server, eliminating the need for platform-specific coding. The development of <i>unixODBC</i> has consistently focused on strict adherence to ODBC standards and robust configuration management.


title: SYNOPSIS
content:
<b>odps</b> <I>subcommand</I> [<I>options</I>] [<I>arguments</I>]<br><b>odps</b> <I>help</I> [<I>subcommand</I>]<br><b>odps</b> <I>sql</I> -e "<I>SQL_STATEMENT</I>"<br><b>odps</b> <I>upload</I> <I>local_path</I> <I>table_name</I>


title: PARAMETERS
content:
<b>sql</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes MaxCompute SQL statements. Supports interactive mode or direct execution via <b>-e</b> option.<br><br><b>desc (or describe)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a MaxCompute object (table, view, function, project).<br><br><b>ls (or list)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists objects within the current MaxCompute project (tables, projects, instances, resources).<br><br><b>cat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the content of a MaxCompute table or resource file.<br><br><b>upload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uploads local files or directories to MaxCompute tables or resources.<br><br><b>download</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads data from MaxCompute tables to local files.<br><br><b>whoami</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current user's Alibaba Cloud account information and MaxCompute project context.<br><br><b>set</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures various MaxCompute session parameters, such as project, endpoint, tunnel settings, or SQL execution options.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides assistance on the <I>odps</I> command itself or specific subcommands.<br><br>


title: DESCRIPTION
content:
The <I>odps</I> command provides a powerful command-line interface (CLI) for interacting with Alibaba Cloud's MaxCompute service. MaxCompute, formerly known as Open Data Processing Service (ODPS), is a serverless, highly scalable platform designed for large-scale data warehousing, analytics, and machine learning. The <I>odps</I> CLI allows users to manage MaxCompute projects, execute SQL and MapReduce jobs, upload and download data, create and manage tables, views, UDFs (User-Defined Functions), and other resources directly from their terminal. It serves as a primary tool for developers, data engineers, and analysts to automate data tasks, perform ad-hoc queries, and script complex data workflows without needing to access the web console. This command facilitates efficient interaction with the MaxCompute ecosystem for big data processing and analysis.


title: CAVEATS
content:
The <I>odps</I> command is not a native Linux utility but a client application for Alibaba Cloud's MaxCompute service. It typically requires Java Runtime Environment (JRE) to be installed. Proper configuration with Alibaba Cloud AccessKey ID, AccessKey Secret, and the MaxCompute project endpoint is essential for its operation. Network latency to the MaxCompute service can impact command execution performance. Authentication tokens have limited validity and may require re-authentication.


title: CONFIGURATION
content:
The client typically uses a configuration file (e.g., <I>odps_config.ini</I>) to store connection details like AccessKey, project name, and endpoint. These can also be passed via environment variables or command-line arguments.


title: INTERACTIVE MODE
content:
Many subcommands, particularly <I>sql</I>, support an interactive shell mode for executing multiple commands sequentially, similar to traditional database clients.


title: SECURITY
content:
Access to MaxCompute resources via the <I>odps</I> command is governed by Alibaba Cloud RAM (Resource Access Management) policies associated with the AccessKey used.


title: HISTORY
content:
The <I>odps</I> command-line client has evolved as an integral part of Alibaba Cloud's big data ecosystem. Originally designed for the Open Data Processing Service (ODPS), it continued its development and importance after the rebranding of ODPS to MaxCompute. It has consistently served as the primary programmatic and interactive interface for users to manage and interact with their MaxCompute data warehouses and compute jobs, paralleling the growth of Alibaba Cloud's global big data offerings. Its design reflects common patterns found in database command-line interfaces, adapting them for the distributed, serverless nature of MaxCompute.


title: PARAMETERS
content:
<b><b>config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures global default settings for the MaxCompute CLI, including default project, service endpoint, tunnel endpoint, output format, and logging level. <br><i>Syntax: <b>odps-auth config</b> [--project <I>project</I>] [--endpoint <I>endpoint</I>] [--tunnel-endpoint <I>tunnel_endpoint</I>] [--format {csv|json}] [--log-level {info|debug}]</i><br><br><b><b>add</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new authentication profile to the configuration. This profile stores AccessKey credentials and associated project/endpoint details. <br><i>Syntax: <b>odps-auth add -i</b> <I>AccessKeyId</I> <b>-k</b> <I>AccessKeySecret</I> [<b>-t</b> <I>SecurityToken</I>] <b>-p</b> <I>ProjectName</I> <b>-e</b> <I>Endpoint</I> <b>-n</b> <I>ProfileName</I><br><b>-i</b> <I>AccessKeyId</I>: Your Alibaba Cloud AccessKey ID.<br><b>-k</b> <I>AccessKeySecret</I>: Your Alibaba Cloud AccessKey Secret.<br><b>-t</b> <I>SecurityToken</I>: (Optional) Your Security Token for STS authentication.<br><b>-p</b> <I>ProjectName</I>: The MaxCompute project name.<br><b>-e</b> <I>Endpoint</I>: The MaxCompute service endpoint.<br><b>-n</b> <I>ProfileName</I>: A unique name for this profile.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all currently configured authentication profiles, showing their names and indicating the active profile.<br><i>Syntax: <b>odps-auth list</b></i><br><br><b><b>set-current</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates a specified existing profile, making it the default for subsequent MaxCompute CLI operations.<br><i>Syntax: <b>odps-auth set-current</b> <I>ProfileName</I></i><br><br><b><b>delete</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified authentication profile from the configuration file.<br><i>Syntax: <b>odps-auth delete</b> <I>ProfileName</I></i><br><br>


title: DESCRIPTION
content:
<b>odps-auth</b> is a command-line utility used for managing authentication configurations for the Alibaba Cloud MaxCompute (formerly ODPS) Command Line Interface (CLI). It allows users to set up, switch, and delete different authentication profiles, typically using AccessKey (AK) pairs or Security Token Service (STS) tokens. This tool is essential for interacting with MaxCompute projects and resources programmatically or via the MaxCompute CLI, ensuring secure and authorized access to data processing services. It streamlines the process of managing credentials for various MaxCompute accounts or different environments within a single CLI installation, enhancing workflow efficiency and security by enabling easy switching between credentials.


title: CAVEATS
content:
<b>Security Risk</b>: Storing AccessKey secrets directly on disk carries inherent security risks. Ensure proper file permissions and restrict access to configuration files to authorized users only.<br><b>Endpoint Mismatch</b>: An incorrect MaxCompute service endpoint configuration can lead to connection failures or interactions with the wrong regional data center.<br><b>Profile Management</b>: Use clear and descriptive profile names to avoid confusion, especially when managing multiple accounts or projects within the same environment.


title: AUTHENTICATION METHODS
content:
<b>odps-auth</b> primarily supports two authentication methods:<br><b>AccessKey (AK)</b>: Uses a permanent pair of AccessKey ID and AccessKey Secret, suitable for long-term programmatic access.<br><b>STS (Security Token Service)</b>: Utilizes temporary security tokens, often generated via RAM (Resource Access Management) roles or STS API calls, providing enhanced security through time-limited credentials.


title: PROFILE STORAGE
content:
Configured authentication profiles and global settings are typically stored in a configuration file within the user's home directory. The common location is <I>~/.maxcompute/odps_config.ini</I> or a similar path, depending on the MaxCompute CLI installation and version. Users should ensure this file has appropriate permissions to prevent unauthorized access to sensitive credentials.


title: HISTORY
content:
MaxCompute, originally known as Open Data Processing Service (ODPS), is Alibaba Cloud's proprietary big data processing platform. The <b>odps-auth</b> utility was developed as an integral part of the MaxCompute client tools to streamline and secure the authentication process for command-line interactions. Its evolution has focused on providing robust and flexible authentication methods, including AccessKey and STS, along with comprehensive profile management capabilities to cater to the diverse needs of users and enterprise environments requiring access to different MaxCompute projects or accounts.


title: SYNOPSIS
content:
<b>odps-func</b> <I>command</I> [<i>options</i>]<br><br><b>Commands:</b><br>&nbsp;&nbsp;<b>list</b>: List all UDFs in the current project.<br>&nbsp;&nbsp;<b>upload</b>: Upload a new UDF or update an existing one.<br>&nbsp;&nbsp;<b>delete</b>: Delete a UDF.<br>&nbsp;&nbsp;<b>describe</b>: Display details about a specific UDF.


title: PARAMETERS
content:
<b><b>--project</b> <I>name</I>, <b>-p</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the MaxCompute project name to operate within. This is often an essential parameter for targeting specific data environments.<br><br><b><b>--endpoint</b> <I>url</I>, <b>-e</b> <I>url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the MaxCompute service endpoint URL. This directs the command to the correct MaxCompute region or instance.<br><br><b><b>--function</b> <I>name</I>, <b>-n</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the User-Defined Function to be created, updated, deleted, or described. This is the identifier for the UDF within MaxCompute.<br><br><b><b>--class</b> <I>className</I>, <b>-c</b> <I>className</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For Java UDFs, specifies the fully qualified class name that implements the UDF logic. This class must be present in the uploaded JAR file.<br><br><b><b>--file</b> <I>filePath</I>, <b>-f</b> <I>filePath</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local path to the UDF's executable file (e.g., a JAR file for Java UDFs, or a Python script for Python UDFs) that contains the function's logic.<br><br><b><b>--resources</b> <I>resourceList</I>, <b>-r</b> <I>resourceList</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of existing MaxCompute resource names that the UDF depends on. These resources must be uploaded to MaxCompute separately and are required for the UDF to execute correctly.<br><br><b><b>--udf-type</b> <I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the type of UDF being managed (e.g., 'java', 'python'). While often inferred, explicit specification ensures correct handling for ambiguous cases.<br><br><b><b>--overwrite</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the 'upload' command to force an overwrite of an existing UDF with the same name. Without this, an error might occur if the UDF already exists.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <i>odps-func</i> command or a specific subcommand, showing available options and usage examples.<br><br>


title: DESCRIPTION
content:
<i>odps-func</i> is a command-line utility provided as part of the Alibaba Cloud MaxCompute (formerly ODPS) client tools. Its primary purpose is to manage User-Defined Functions (UDFs), User-Defined Aggregate Functions (UDAFs), and User-Defined Table Functions (UDTFs) within a MaxCompute project.<br><br>This tool allows users to upload new function definitions (typically JAR files for Java or Python files for Python UDFs), update existing ones, list all deployed functions, or delete functions from a MaxCompute project. It streamlines the deployment and lifecycle management of custom logic that extends MaxCompute's SQL capabilities, enabling complex data processing and analysis directly within the big data platform.


title: CAVEATS
content:
This command is part of the Alibaba Cloud MaxCompute client tools and requires an active Alibaba Cloud account with MaxCompute service enabled. Users must have appropriate permissions to manage UDFs within the specified MaxCompute project. Proper configuration of the MaxCompute client (e.g., API keys, project name, endpoint) is crucial for the command to function correctly.


title: UDF TYPES AND LANGUAGE SUPPORT
content:
MaxCompute supports various programming languages for UDFs, primarily Java and Python. When using <i>odps-func</i>, the `--class` parameter is typically used for Java UDFs, specifying the main entry point class within a JAR file. For Python UDFs, you would usually provide a Python script file. The command handles the nuances of deploying functions written in these different languages, adapting its internal processes based on the file type or explicit `--udf-type` parameter.


title: RESOURCE MANAGEMENT AND DEPENDENCIES
content:
Complex UDFs often rely on external libraries or data files. In MaxCompute, these are managed as 'resources'. When uploading a UDF using <i>odps-func</i>, you can specify dependent resources using the `--resources` parameter. These resources must be pre-uploaded to your MaxCompute project. MaxCompute ensures these dependencies are available to your UDF at runtime, allowing for highly extensible and modular function development.


title: HISTORY
content:
<i>odps-func</i> emerged as a specialized component within the broader suite of MaxCompute (formerly known as ODPS, Open Data Processing Service) client tools developed by Alibaba Cloud. Its development is intrinsically linked to the evolution of MaxCompute as a robust big data computing platform. The dedicated `odps-func` utility was introduced to streamline the lifecycle management of User-Defined Functions, acknowledging their critical role in extending the platform's capabilities beyond standard SQL. Its focus on function-specific operations reflects a commitment to providing granular control and simplifying the deployment of custom logic, making it easier for users to encapsulate complex business rules as reusable components within the MaxCompute ecosystem.


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message, listing available commands and options specific to the <i>odps-inst</i> utility.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <i>odps-inst</i> utility or the associated MaxCompute client package.<br><br><b><b>--config</b> <I>file</I>, <b>-c</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use for setup or operations, overriding default paths.<br><br><b><b>--init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes or resets the default configuration files and settings for the MaxCompute client in the current environment.<br><br><b><b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs diagnostic checks on the environment, dependencies (e.g., Java), and the existing MaxCompute client installation status.<br><br><b><b>--path</b> <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the target directory for installation or where configuration files should be managed by the utility.<br><br><b><b>--silent</b>, <b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the command in silent or unattended mode, suppressing interactive prompts and using default values where applicable.<br><br>


title: DESCRIPTION
content:
<i>odps-inst</i> is not a standard Linux command found in general-purpose distributions. Instead, it is typically a utility or script associated with the <I>Alibaba Cloud MaxCompute</I> (formerly ODPS) client or SDK. Its primary purpose is to assist with the installation, configuration, or environment setup of the <I>MaxCompute command-line tool</I> (<I>odpscmd</I>) and related components. This command ensures that the necessary dependencies are met, configuration files are correctly set up, and environment variables are properly configured for users to interact with the <I>MaxCompute</I> big data platform. Specific usage and available options are highly dependent on the particular version and packaging of the <I>MaxCompute</I> client being used.


title: CAVEATS
content:
<i>odps-inst</i> is not a universal Linux command; its availability and exact functionality are tied specifically to the <I>Alibaba Cloud MaxCompute</I> client or SDK. <br>Users will only find this command if they have explicitly downloaded and set up the <I>MaxCompute</I> command-line tools. <br>The command's options and behavior may vary significantly between different versions of the <I>MaxCompute</I> client, and it is primarily designed for environment setup rather than daily MaxCompute operations (which are handled by <I>odpscmd</I>). <br>Consult the official <I>Alibaba Cloud MaxCompute</I> documentation for the most accurate and up-to-date usage instructions for your specific client version.


title: OBTAINING THE UTILITY
content:
The <i>odps-inst</i> utility is not distributed independently but is bundled within the official <I>Alibaba Cloud MaxCompute</I> command-line client (<i>odpscmd</i>) package. Users typically download this package from the <I>Alibaba Cloud</I> official website or documentation, which then includes <i>odps-inst</i> as part of the setup scripts.


title: TYPICAL USAGE FLOW
content:
A common usage scenario involves downloading the <I>MaxCompute</I> client package, extracting it, navigating to the extracted directory, and then running <i>./odps-inst --check</i> or <i>./odps-inst --init</i> to prepare the environment before using the main <i>./odpscmd</i> tool for data operations.


title: HISTORY
content:
The <i>odps-inst</i> utility emerged as part of the evolution of the <I>Alibaba Cloud MaxCompute</I> (formerly ODPS) client. As <I>MaxCompute</I> grew into a mature big data platform, the need for a streamlined and reliable method to set up its command-line interface (<I>odpscmd</I>) on various Linux environments became apparent. <i>odps-inst</i> was developed to automate common installation and configuration tasks, such as validating Java environments, setting up necessary paths, and configuring connectivity parameters, thus simplifying the initial user experience for interacting with the <I>MaxCompute</I> service.


title: SYNOPSIS
content:
resource <b>{list | add | drop | get}</b> <I>[arguments]</I> <I>[options]</I><br><br>Examples:<br>resource <b>list</b> [-p <I>project_name</I>] [-t <I>type</I>]<br>resource <b>add</b> <I>resource_name</I> <I>local_path</I> [-p <I>project_name</I>] [-f] [-t <I>type</I>]<br>resource <b>drop</b> <I>resource_name</I> [-p <I>project_name</I>]<br>resource <b>get</b> <I>resource_name</I> [<I>local_path</I>] [-p <I>project_name</I>]


title: PARAMETERS
content:
<b><b>list</b> | <b>ls</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all resources or resources of a specific type within a MaxCompute project. Alias <b>ls</b> is also available.<br><br><b><b>add</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uploads a local file as a resource to the MaxCompute project.<br><br><b><b>drop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes an existing resource from the MaxCompute project.<br><br><b><b>get</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads a specified resource from the MaxCompute project to a local path.<br><br><b><I>resource_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name assigned to the resource within the MaxCompute project. Used for identifying, adding, dropping, or getting resources.<br><br><b><I>local_path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The local file system path for the source file to upload (with <b>add</b>) or the destination path for the downloaded file (with <b>get</b>).<br><br><b><b>-p</b> <I>project_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target MaxCompute project. If omitted, the currently configured default project is used.<br><br><b><b>-t</b> <I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters or specifies the type of resource. Valid types include <i>file</i>, <i>jar</i>, and <i>archive</i>. Used with <b>list</b> and <b>add</b>.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an overwrite if a resource with the same name already exists during an <b>add</b> operation.<br><br>


title: DESCRIPTION
content:
The <b>odps-resource</b> command is a crucial subcommand within the <i>odpscmd</i> client tool for Alibaba Cloud MaxCompute. It facilitates the management of project-level resources, which include generic files, Java Archive (JAR) packages, and compressed archives. These resources are fundamental for executing custom logic such as User-Defined Functions (UDFs), User-Defined Aggregate Functions (UDAFs), and other custom processes within the MaxCompute environment. The command supports various operations including listing existing resources, adding new ones from local files, deleting resources, and downloading resources from MaxCompute to a local machine. It ensures that all necessary external files for computations are readily available within the MaxCompute distributed system.


title: CAVEATS
content:
The <b>odps-resource</b> command is not a standalone Linux executable. It is a subcommand of the <i>odpscmd</i> client, which must be installed and configured with appropriate access credentials for Alibaba Cloud MaxCompute. Users require specific MaxCompute project permissions (e.g., <i>CreateResource</i>, <i>DeleteResource</i>, <i>ListResource</i>, <i>DownloadResource</i>) to perform operations. Resource names must be unique within a project. There might be size limitations for individual resources depending on MaxCompute service limits.


title: RESOURCE TYPES EXPLAINED
content:
MaxCompute distinguishes between three main resource types:<br><b>file</b>: General purpose files, often used for data or configuration.<br><b>jar</b>: Java Archive files, specifically designed for Java UDFs and UDAFs.<br><b>archive</b>: Compressed archives (e.g., .zip, .tar.gz) that can contain multiple files, useful for Python UDFs or other complex dependencies.<br>The type influences how MaxCompute processes and makes the resource available to your jobs.


title: USAGE CONTEXT
content:
This command is typically executed in two ways:<br>1. Within the interactive <i>odpscmd</i> shell: After launching <i>odpscmd</i>, you can directly type <code>resource add ...</code>.<br>2. Non-interactively via the <i>odpscmd -e</i> option: For scripting purposes, you can run <code>odpscmd -e "resource add ..."</code> from your Linux terminal.


title: HISTORY
content:
MaxCompute, formerly known as ODPS, is Alibaba Cloud's fully managed, serverless data warehousing solution. The <i>odpscmd</i> client and its various subcommands, including <b>resource</b>, have been developed as essential tools for interacting with the MaxCompute platform. The <b>resource</b> command's evolution parallels the growing need for robust management of external dependencies like UDFs and custom code within the MaxCompute ecosystem, ensuring efficient data processing and analysis capabilities for enterprise users.


title: SYNOPSIS
content:
odps-table <command> [arguments] [options]<br>Example: <i>odps-table desc my_table</i><br>Example: <i>odps-table create new_table (id BIGINT, name STRING) PARTITIONED BY (dt STRING)</i>


title: PARAMETERS
content:
<b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all tables available in the current MaxCompute project.<br><br><b><b>desc</b> <i>&lt;table_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specified table, including its schema, partition keys, lifecycle, comment, and other metadata.<br><br><b><b>create</b> <i>&lt;table_name&gt;</i> <i>&lt;column_definitions&gt;</i> [<i>&lt;properties&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new MaxCompute table. <i>&lt;column_definitions&gt;</i> specifies column names and data types. Optional <i>&lt;properties&gt;</i> include <b>PARTITIONED BY</b> for partitioning, <b>LIFECYCLE</b> for data retention, and <b>COMMENT</b> for description.<br><br><b><b>drop</b> <i>&lt;table_name&gt;</i> [<b>IF EXISTS</b>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a specified table from MaxCompute. The <b>IF EXISTS</b> clause prevents an error if the table does not exist.<br><br><b><b>alter table</b> <i>&lt;table_name&gt;</i> <i>&lt;operation&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies an existing table. Common <i>&lt;operation&gt;</i>s include:<br><i>&nbsp;&nbsp;<b>add column</b> (col_name type[, ...])</i><br><i>&nbsp;&nbsp;<b>add partition</b> (pt_col='pt_val'[, ...])</i><br><i>&nbsp;&nbsp;<b>set lifecycle</b> &lt;days&gt;</i><br><i>&nbsp;&nbsp;<b>set comment</b> '&lt;comment_string&gt;'</i><br><i>&nbsp;&nbsp;<b>rename to</b> &lt;new_table_name&gt;</i><br><br>


title: DESCRIPTION
content:
<b>odps-table</b> is a command-line utility used to manage tables within Alibaba Cloud's MaxCompute, a serverless data warehousing platform. It provides a comprehensive set of operations for database administrators and developers to interact with MaxCompute tables directly from a terminal. With <b>odps-table</b>, users can perform essential table management tasks such as listing existing tables, creating new tables with specified schemas and properties, describing table details (including columns, partitions, and metadata), dropping tables, and altering table structures or properties. It's an integral part of the MaxCompute client tools (<b>odpscmd</b>) designed for efficient data governance and schema evolution.<br><br>The tool facilitates scripting and automation of data warehousing operations, allowing for programmatic control over table lifecycles and metadata. While <b>odps-table</b> itself doesn't offer many direct options, its functionality is primarily exposed through a series of subcommands, each dedicated to a specific table operation. These subcommands are invoked after <b>odps-table</b> and often accept their own set of options and arguments to refine their behavior.


title: CAVEATS
content:
<ul><li><b>odps-table</b> requires a configured Alibaba Cloud MaxCompute client (<b>odpscmd</b>) and appropriate network connectivity to the MaxCompute service endpoints.</li><li>Users must have the necessary IAM permissions within MaxCompute to perform table operations (e.g., Create Table, Drop Table, Alter Table).</li><li>Syntax for table properties (like PARTITIONED BY, LIFECYCLE) and data types (e.g., BIGINT, STRING, DATETIME) must conform to MaxCompute SQL specifications, which may differ from standard SQL dialects.</li><li>Operations like dropping or altering tables can have irreversible consequences on data. Always exercise caution and verify commands before execution.</li></ul>


title: AUTHENTICATION
content:
Access to MaxCompute via <b>odps-table</b> requires proper authentication. This is typically managed through AccessKey ID and AccessKey Secret credentials, or RAM roles, configured in the <b>odpscmd</b> client's configuration file (usually <i>~/.odps_config</i>). Ensure your credentials are up-to-date and have the necessary permissions for the desired operations.


title: PROJECT CONTEXT
content:
All <b>odps-table</b> operations are performed within a specific MaxCompute project. The active project is usually determined by the <b>odpscmd</b> client's configuration. You can switch projects using the <b>set project</b> command within the interactive <b>odpscmd</b> shell, or by configuring the default project in your client settings.


title: HISTORY
content:
<b>odps-table</b> is an integral part of the MaxCompute client tools provided by Alibaba Cloud. MaxCompute, formerly known as ODPS (Open Data Processing Service), was developed by Alibaba Group to handle massive-scale data processing and analytics. The <b>odps-table</b> command has evolved alongside MaxCompute to provide robust command-line capabilities for managing the metadata and structure of tables, adapting to new features and data types introduced in the platform. Its development has focused on providing a streamlined interface for programmatic interaction with the MaxCompute data warehouse.


title: SEE ALSO
content:
odps-sql: Another component of odpscmd for executing MaxCompute SQL queries., odps-tunnel: Used for efficient data import/export between local file systems and MaxCompute tables., sqlplus(1): Oracle SQL command-line interface., mysql(1): MySQL database client command-line interface.


title: SYNOPSIS
content:
<b>odps-tunnel</b> <I>command</I> [options]<br><br><I>Common Commands:</I><br><I>  odps-tunnel upload</I> [options] <I>&lt;local_file_path&gt;</I> <I>&lt;table_name&gt;</I><br><I>  odps-tunnel download</I> [options] <I>&lt;table_name&gt;</I> <I>&lt;local_file_path&gt;</I>


title: PARAMETERS
content:
<b>-e, --endpoint</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the MaxCompute service endpoint (e.g., 'http://service.cn-hangzhou.maxcompute.aliyun.com/api').<br><br><b>-i, --id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Alibaba Cloud AccessKey ID for authentication.<br><br><b>-k, --key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Alibaba Cloud AccessKey Secret for authentication.<br><br><b>-p, --project</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the MaxCompute project name to operate within.<br><br><b>-t, --table</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target MaxCompute table name for data transfer.<br><br><b>-pt, --partition</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the partition for a partitioned table (e.g., 'dt=20230101,hr=10').<br><br><b>-f, --file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local file path for data input or output.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or a specific subcommand.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the MaxCompute Tunnel client.<br><br><b>--skip-header</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For upload, skips the first line of the input file, treating it as a header.<br><br><b>--delimiter</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the column delimiter for text files (e.g., ',').<br><br><b>--encoding</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character encoding for the input/output file (e.g., 'UTF-8', 'GBK').<br><br><b>--compress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables data compression during transfer to improve performance.<br><br><b>--threads</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of concurrent threads for data transfer (e.g., '8').<br><br><b>--overwrite</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For upload, overwrites existing data in the target table or partition.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables strict mode for data type conversion during upload, enforcing exact type matching.<br><br><b>--null-value</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the string representation for NULL values in the data file (e.g., '\N').<br><br>


title: DESCRIPTION
content:
The <b>odps-tunnel</b> command is a command-line interface (CLI) tool for Alibaba Cloud's MaxCompute (formerly ODPS) service. It serves as a client-side utility primarily for efficient and high-performance data transfer between local file systems and MaxCompute tables. Users can leverage <b>odps-tunnel</b> to upload large datasets from local files into MaxCompute tables, or to download data from MaxCompute tables to local files. It supports various data formats, encoding, compression, and offers options for handling partitioned tables, error management, and parallel processing to optimize data transfer performance. This tool is essential for data engineers and analysts working with MaxCompute for ETL processes, data loading, and reporting.


title: CAVEATS
content:
<b>Authentication:</b> Requires valid Alibaba Cloud AccessKey ID and Secret. It is recommended to use environment variables or configuration files for credentials rather than directly on the command line for security.<br><b>Network Latency:</b> Performance can be significantly affected by network latency and bandwidth between the client and MaxCompute endpoint.<br><b>Data Volume:</b> While optimized for large data volumes, extremely large files might still benefit from data partitioning or specific MaxCompute import/export features for better management.<br><b>Schema Matching:</b> When uploading, the local data schema must be compatible with the MaxCompute table schema; otherwise, data conversion errors may occur.


title: CONFIGURATION FILE SUPPORT
content:
The <b>odps-tunnel</b> client supports reading configurations from a file (e.g., 'tunnel.ini' or similar) to manage common parameters like endpoint, AccessKey, and project, avoiding repetitive command-line input and centralizing settings.


title: DATA FORMATS
content:
While primarily used for text-based data (CSV, TSV), the client is optimized for various data types and can handle complex data structures if properly formatted according to MaxCompute's table schema.


title: JOB ID & STATUS
content:
Each upload or download operation initiated through <b>odps-tunnel</b> is assigned a unique job ID. This ID can be used with subcommands like 'show' and 'purge' to monitor the progress or manage the lifecycle of the data transfer job.


title: HISTORY
content:
MaxCompute was originally launched as ODPS (Open Data Processing Service) by Alibaba Cloud. The <b>odps-tunnel</b> client was developed as an essential component of the ODPS ecosystem to facilitate high-throughput data ingestion and extraction. As ODPS evolved into MaxCompute, the <b>odps-tunnel</b> client continued to be maintained and updated, reflecting the platform's advancements in data processing capabilities and new features like enhanced data types and partition management. Its development has focused on improving transfer performance, stability, and ease of use for handling massive datasets in cloud environments.


title: PARAMETERS
content:
<b><b>-c</b> <i>&lt;file&gt;</i>, <b>--config</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>OpenDNSSEC</i> configuration file to use.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging, providing more verbose output for troubleshooting.<br><br><b><b>-p</b> <i>&lt;file&gt;</i>, <b>--pidfile</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>PID file</i> path where the daemon writes its process ID.<br><br><b><b>-t</b> <i>&lt;dir&gt;</i>, <b>--chroot</b> <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the root directory of the daemon process for enhanced security.<br><br><b><b>-u</b> <i>&lt;user&gt;</i>, <b>--user</b> <i>&lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drops privileges and runs the daemon as the specified user.<br><br><b><b>-g</b> <i>&lt;group&gt;</i>, <b>--group</b> <i>&lt;group&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drops privileges and runs the daemon as the specified group.<br><br><b><b>--foreground</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the daemon in the foreground, useful for debugging.<br><br><b><b>--nonl</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses logging to <i>syslog</i>, outputting only to standard error if in foreground.<br><br><b><b>--log-config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs the complete configuration loaded by the daemon at startup.<br><br><b><b>start</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Command to start the <i>ods-server</i> daemon.<br><br><b><b>stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Command to stop the <i>ods-server</i> daemon.<br><br><b><b>reload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Command to instruct the daemon to reload its configuration and policies without stopping.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current running status of the <i>ods-server</i> daemon.<br><br>


title: DESCRIPTION
content:
<i>ods-server</i> is the core daemon component of the <b>OpenDNSSEC</b> project, an automated DNSSEC key and signing management tool.<br>It is responsible for all cryptographic operations, including key generation, key rollovers, and the actual signing of DNS zones according to policies defined in the <i>Key and Signing Policy (KASP)</i> database.<br>The daemon continually monitors the state of configured zones and applies the necessary DNSSEC operations to ensure they remain signed and secure.<br>It communicates with configured DNS servers (such as BIND or NSD) to retrieve unsigned zones and push signed zones, effectively automating the entire DNSSEC signing process for domain owners.


title: CAVEATS
content:
Running <i>ods-server</i> requires a properly configured <b>OpenDNSSEC</b> environment, including the <i>Enforcer</i> and a configured <i>Hardware Security Module (HSM)</i> or software-based key store.<br>Incorrect or outdated DNSSEC policies (defined in <i>KASP</i>) can lead to critical issues such as zones becoming unsigned, key rollover failures, or operational errors.<br>It is crucial to ensure that the daemon has appropriate file system permissions to access configuration files, key material, and communicate with the DNS server.


title: <B>CONFIGURATION FILES</B>
content:
The primary configuration file for <i>ods-server</i> is typically <i>conf.xml</i>, which defines paths, logging, and connections to the KASP database and DNS servers.<br>DNSSEC policies themselves are defined in <i>kasp.xml</i>, managed by the <i>enforcer</i> component, and are crucial for the daemon's operations.


title: <B>LOGGING</B>
content:
By default, <i>ods-server</i> logs its operational messages and errors to <i>syslog</i>, typically under the <i>daemon</i> facility.<br>For detailed troubleshooting, enabling debug logging (<i>-d</i> option) and reviewing the syslog messages is essential.


title: HISTORY
content:
The <i>ods-server</i> daemon is a central component of the <b>OpenDNSSEC</b> project, which originated from a need to automate the complex process of <b>DNSSEC</b> signing.<br>Developed by <i>NLnet Labs</i> and <i>SURFnet</i>, <b>OpenDNSSEC</b> aims to provide an open-source, robust, and policy-driven solution for securing DNS zones.<br>The daemon has evolved through various versions, improving performance, adding features, and enhancing security, becoming a widely adopted tool for DNSSEC automation in critical infrastructure.


title: SEE ALSO
content:
<b>ods-enforcerd</b>(8), <b>ods-control</b>(8), <b>ods-ksmutil</b>(1), <b>ods-enforcer</b>(1), <b>named</b>(8), <b>nsd</b>(8)


title: PARAMETERS
content:
<b><b>-f</b> <I>format_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output file format name (e.g., 'ESRI Shapefile', 'GeoJSON', 'PostgreSQL').<br><br><b><b>-s_srs</b> <I>srs_def</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Source spatial reference system (SRS) definition (e.g., 'EPSG:4326', 'WGS84').<br><br><b><b>-t_srs</b> <I>srs_def</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Target spatial reference system (SRS) definition.<br><br><b><b>-overwrite</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete the output datasource and recreate it if it already exists.<br><br><b><b>-append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append to an existing layer instead of creating a new one.<br><br><b><b>-update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open existing output datasource in update mode. Can be combined with <i>-append</i>.<br><br><b><b>-sql</b> <I>sql_statement</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute an SQL statement against the input datasource to select features.<br><br><b><b>-where</b> <I>expression</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attribute query to select features from the input layer.<br><br><b><b>-select</b> <I>field1,field2,...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of fields to copy from the input layer.<br><br><b><b>-nln</b> <I>new_layer_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assign a new name to the output layer.<br><br><b><b>-nlt</b> <I>geometry_type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the output geometry type (e.g., 'PROMOTE_TO_MULTI', 'POINT', 'LINESTRING', 'POLYGON').<br><br><b><b>-spat</b> <I>xmin ymin xmax ymax</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Spatial query extents to filter features.<br><br><b><b>-skipfailures</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue with translation even if some features could not be written.<br><br><b><b>-progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display progress of the translation process.<br><br><b><b>-co</b> <I>NAME=VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creation option for the output format/driver (e.g., 'GEOMETRY_NAME=geom').<br><br>


title: DESCRIPTION
content:
<i>ogr2ogr</i> is a powerful command-line tool, part of the <b>GDAL/OGR</b> library, designed for converting simple features data between various vector data formats. It can read virtually any vector format supported by GDAL/OGR drivers (like Shapefile, GeoJSON, PostGIS, KML, CSV) and write to another. <br><br>Beyond simple format conversion, <i>ogr2ogr</i> offers extensive capabilities including coordinate system reprojection, spatial and attribute filtering (e.g., SQL WHERE clauses, spatial extents), reordering fields, selecting specific layers or features, and modifying geometry types. It's an essential utility for GIS professionals and developers working with geospatial vector data, enabling complex data transformations and interoperability between different systems and applications. Its flexibility makes it a cornerstone for automating geospatial workflows.


title: CAVEATS
content:
<i>ogr2ogr</i> relies heavily on the capabilities of the installed GDAL/OGR drivers. Some drivers may have specific limitations regarding data types, schema evolution, or performance. Reprojection accuracy depends on the quality of the source and target SRS definitions and transformations. Large datasets can consume significant memory and disk space, potentially requiring optimized strategies or streaming capabilities.


title: GDAL/OGR DRIVERS
content:
<i>ogr2ogr</i>'s versatility stems from its support for a wide array of <b>GDAL/OGR drivers</b>. Each driver provides read/write capabilities for a specific vector data format (e.g., Shapefile, GeoJSON, PostGIS, GML). Users specify the desired output format using the <b>-f</b> option. The availability and capabilities of these drivers depend on how GDAL/OGR was compiled and what external libraries are linked.


title: SPATIAL REFERENCE SYSTEMS (SRS)
content:
A core function of <i>ogr2ogr</i> is the ability to transform data between different <b>Spatial Reference Systems (SRS)</b>, commonly known as coordinate systems or projections. This is achieved using the <b>-s_srs</b> (source SRS) and <b>-t_srs</b> (target SRS) options. SRS definitions can be provided in various formats, including EPSG codes (e.g., 'EPSG:4326' for WGS 84), PROJ.4 strings, or WKT (Well-Known Text) strings. Accurate SRS definition is crucial for correct spatial operations.


title: HISTORY
content:
<i>ogr2ogr</i> is a key component of the <b>GDAL/OGR</b> project, an open-source geospatial data translation library developed primarily by Frank Warmerdam. GDAL (Geospatial Data Abstraction Library) handles raster data, while OGR (OpenGIS Simple Features Reference Implementation) handles vector data. <i>ogr2ogr</i> emerged as the primary tool for vector data transformation, building on the OGR library's extensive support for various formats and spatial operations. Its development began in the late 1990s, and it has since become an industry standard for geospatial data interoperability, continuously evolving with new drivers and features.


title: PARAMETERS
content:
<b><b>-ro</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the data source in read-only mode.<br><br><b><b>-al</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all layers in the data source. This is the default if no <i>layer_name</i> is specified.<br><br><b><b>-so</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Summary only. Suppresses the listing of individual features, showing only layer schema and statistics.<br><br><b><b>-json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the information in JSON format (GDAL 2.2+).<br><br><b><b>-sql</b> <i><query></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute an SQL <i>query</i> against the data source. The results are presented as a virtual layer.<br><br><b><b>-where</b> <i><query></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply an SQL WHERE <i>clause</i> to filter features from the selected layer.<br><br><b><b>-spat</b> <i><xmin> <ymin> <xmax> <ymax></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Spatially filter features within the specified bounding box coordinates.<br><br><b><b>-fid</b> <i><fid></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select and display only the feature with the specified Feature ID (<i>fid</i>).<br><br><b><b>-geom</b> <i><option></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control how geometry is displayed: <i>YES</i> (display WKT), <i>NO</i> (don't display), or <i>SUMMARY</i> (display type and extent).<br><br><b><b>-fields</b> <i><option></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control how fields are displayed: <i>YES</i> (display all fields), <i>NO</i> (don't display).<br><br><b><b>-stats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display statistics (min/max/mean/stddev) for numeric fields in the layer.<br><br><b><b>-nomd</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display metadata.<br><br><b><b>-listmd</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List available metadata domains for the data source.<br><br><b><b>-mdd</b> <i><domain></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display metadata from a specific <i>domain</i> (e.g., 'IMAGERY_OVERVIEW').<br><br><b><b>-oo</b> <i><NAME>=<VALUE></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a driver-specific open <i>option</i> for the data source. Can be used multiple times.<br><br><b><b>-gt</b> <i><count></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Group features. Stop after displaying the first <i>count</i> features.<br><br><b><b>-dialect</b> <i><dialect></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the SQL <i>dialect</i> to use (e.g., 'OGRSQL', 'SQLite').<br><br>


title: DESCRIPTION
content:
The <b>ogrinfo</b> command is a powerful utility within the GDAL/OGR library designed to inspect and report information about geospatial vector data sources and their layers. It supports a vast array of vector formats, including Shapefile, GeoJSON, KML, PostGIS, GPKG, and many more. Users can employ <b>ogrinfo</b> to list available drivers, identify layers within a data source, display detailed layer schema (fields, geometry type, spatial reference system), and even query or filter features based on SQL expressions or spatial extents. <br><br>It serves as a crucial diagnostic and exploration tool, allowing users to verify data integrity, understand projections, and explore attribute tables before performing more complex transformations with other GDAL/OGR utilities like <b>ogr2ogr</b>. Its flexibility and comprehensive reporting capabilities make it an indispensable asset in geospatial data analysis and processing workflows.


title: CAVEATS
content:
Performance can be impacted by large datasets, complex queries, or extensive feature listing. The availability of specific features and supported formats depends on how the GDAL/OGR library was compiled and which drivers are installed. Memory usage can increase significantly when processing or filtering a very high number of features. Behavior of SQL options (<b>-sql</b>, <b>-where</b>) can vary based on the data source's underlying driver capabilities or the specified SQL dialect.


title: DEFAULT BEHAVIOR
content:
When <b>ogrinfo</b> is invoked with only a <i>datasource_name</i> and no <i>layer_name</i>, it defaults to listing all available layers within that data source, providing a high-level overview of its contents.


title: DRIVER-SPECIFIC OPEN OPTIONS
content:
The <b>-oo</b> option is critical for interacting with specific data source types. It allows users to pass format-specific configuration options, such as connection parameters for databases (e.g., 'DB_SCHEMA=public' for PostGIS) or specific file handling settings for complex formats. Consult the GDAL/OGR documentation for the specific driver to find applicable options.


title: HISTORY
content:
<b>ogrinfo</b> is an integral part of the GDAL/OGR library, which began development in 1998. The OGR (OpenGIS Simple Features Reference Implementation) component, responsible for vector data handling, was introduced around 2001. Since its inception, <b>ogrinfo</b> has served as the primary command-line utility for inspecting vector datasets. Its evolution mirrors that of the GDAL/OGR project, consistently adding support for new data formats, incorporating advanced querying capabilities (like JSON output and improved SQL dialects), and enhancing performance, solidifying its role as a cornerstone tool for geospatial data interoperability.


title: PARAMETERS
content:
<b><b>--api-token=&lt;token&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the Oh Dear! API token for authentication. This can also be set via environment variables.</i><br><br><b><b>--site-id=&lt;id&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Used by commands that operate on a specific monitored site, e.g., <b>run-checks</b> or <b>deploy-success</b>.</i><br><br><b><b>--url=&lt;url&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Used by specific check commands like <b>check-broken-links</b> to define the target URL for crawling.</i><br><br><b><b>--domain=&lt;domain&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Used by specific check commands like <b>check-certificate</b> to define the target domain for validation.</i><br><br><b><b>--help, -h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays help information for the main command or a specific subcommand.</i><br><br><b><b>--version, -V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the installed version of the <b>ohdear-cli</b> tool.</i><br><br><b><b>--verbose, -v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Increases the verbosity of output messages. Can be specified multiple times for more verbosity (<b>-vv</b>, <b>-vvv</b>).</i><br><br><b><b>--quiet, -q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppresses all output messages.</i><br><br><b><b>--no-interaction</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables interactive prompts, useful for scripting.</i><br><br>


title: DESCRIPTION
content:
<i><b>ohdear-cli</b> is the official command-line interface for the Oh Dear! website monitoring service. It allows developers and system administrators to interact with their Oh Dear! account directly from the terminal, automating various monitoring and deployment tasks. It supports a range of functionalities, including listing monitored sites, triggering checks, notifying deployment successes, and performing specific checks like SSL certificate validity, broken links, and scheduled tasks. This tool is particularly useful for integrating Oh Dear! into CI/CD pipelines, scripting routine operations, or quickly checking site statuses without needing to access the web interface. It requires an Oh Dear! API token for authentication.</i>


title: CAVEATS
content:
<i>Requires an Oh Dear! API token, which must be configured or passed with <b>--api-token</b>. An active internet connection is necessary for most operations as it interacts with the Oh Dear! cloud service. The <b>check-scheduled-tasks</b> command often requires specific local server configurations (e.g., running within a Laravel application context) to function correctly. Some features might be limited by your Oh Dear! subscription plan.</i>


title: AUTHENTICATION
content:
<i><b>ohdear-cli</b> primarily authenticates using an Oh Dear! API token. This token can be provided via the <b>--api-token</b> option, but it's recommended to store it as an environment variable (e.g., <b>OHDEAR_API_TOKEN</b>) or in a configuration file to avoid exposing it in shell history.</i>


title: SUBCOMMANDS
content:
<i>The <b>ohdear-cli</b> tool is structured around subcommands, each performing a specific action. Examples include <b>list-sites</b> to view all monitored sites, <b>run-checks &lt;site_id&gt;</b> to trigger checks for a specific site, <b>deploy-success &lt;site_id&gt;</b> to mark a successful deployment, <b>check-certificate &lt;domain&gt;</b> for SSL checks, and <b>check-broken-links &lt;url&gt;</b> for link validation. To see available subcommands, run <b>ohdear-cli --help</b>. Each subcommand also has its own help page (e.g., <b>ohdear-cli list-sites --help</b>).</i>


title: HISTORY
content:
<i><b>ohdear-cli</b> is developed by the team behind the Oh Dear! monitoring service. It emerged as a practical tool to extend the service's functionality beyond its web interface, allowing for automation and integration into development and deployment workflows. Its development parallels the growth of the Oh Dear! service itself, continually providing command-line access to an increasing number of features. It is a relatively modern tool, reflecting the industry trend of offering robust CLI clients for SaaS platforms.</i>


title: SYNOPSIS
content:
okular [<i>options</i>] [<i>URL</i>]<br>okular [<i>Qt-options</i>] [<i>KDE-options</i>] [<i>file</i>]<br>


title: PARAMETERS
content:
<b><i>[URL]</i> or <i>[file]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the document to open. This can be a local file path or a URL.<br><br><br><b><b>-p</b> <i><page></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the document and immediately navigates to the specified <i><page></i> number.<br><br><br><b><b>--presentation</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Okular in full-screen presentation mode directly after opening the document.<br><br><br><b><b>--find</b> <i><string></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for the first occurrence of the specified <i><string></i> within the document upon opening.<br><br><br><b><b>--unique</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures that only one instance of Okular is running. If another Okular window is already open, the document will be opened in that window.<br><br><br><b><b>--noraise</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--unique</b>, this option prevents an existing Okular window from being brought to the foreground when a new document is opened in it.<br><br><br><b><b>--select</b> <i><x,y,width,height></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific rectangular region defined by the coordinates (x,y) and dimensions (width,height) after opening. This is primarily useful for automation or specific document types.<br><br><br><b><b>--print</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately sends the opened document to the printer without displaying the viewer interface.<br><br><br><b><b>--editor-sync</b> <i><file> <line></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used for editor synchronization, typically with LaTeX or Markdown. It opens the document and jumps to the location corresponding to the given source <i><file></i> and <i><line></i> number.<br><br><br>


title: DESCRIPTION
content:
Okular is a versatile universal document viewer developed by KDE, designed to handle a wide array of document formats with ease. It stands out for its comprehensive support, allowing users to view <b>PDF</b> files, <b>DjVu</b> documents, comic books (<b>CBR</b>, <b>CBZ</b>), <b>EPUB</b> ebooks, <b>PostScript</b>, <b>DVI</b>, <b>XPS</b>, and even <b>Markdown</b> files. Beyond simple viewing, Okular offers powerful annotation tools, enabling users to highlight text, add inline notes, draw shapes, and create bookmarks, making it an excellent tool for students and professionals. Its intuitive interface provides features like text selection, searching within documents, thumbnail navigation, and a structured table of contents view, enhancing productivity and readability. Okular is built on the KDE Frameworks and is an integral part of the KDE Applications, but it's also available on other Linux desktops.<br>


title: CAVEATS
content:
Okular's full functionality, especially advanced features like <b>--select</b> or editor synchronization, might depend on the specific document format backend and proper system configuration. While it supports embedding annotations directly into <b>PDF</b> files, it also uses external <i>.okular</i> files by default for many formats, which means annotations might not be portable with the document itself unless explicitly exported. Performance with extremely large or complex documents can vary.<br>


title: SUPPORTED FORMATS
content:
Okular boasts support for an impressive range of document formats, including <b>PDF</b>, <b>DjVu</b>, <b>PostScript</b>, <b>DVI</b>, <b>XPS</b>, <b>OpenDocument Text</b> (<i>ODT</i>), <b>FictionBook</b> (<i>FB2</i>), various comic book formats (<b>CBR</b>, <b>CBZ</b>, <b>CB7</b>, <b>CBT</b>), <b>CHM</b> (<i>Compiled HTML Help</i>), <b>EPUB</b>, <b>Markdown</b>, and various image formats. This wide compatibility makes it a truly versatile viewer.<br>


title: ANNOTATION PERSISTENCE
content:
Okular offers robust annotation capabilities, allowing users to highlight text, add sticky notes, draw lines and shapes, and even sign documents. By default, annotations are often saved in an external <i>.okular</i> data file alongside the original document. However, for <b>PDF</b> files, Okular provides the option to save annotations directly embedded within the <b>PDF</b>, ensuring their persistence when the document is shared.<br>


title: HISTORY
content:
Okular's development began in 2005, aiming to create a modern, universal document viewer for the KDE desktop environment. It was designed to replace older, format-specific viewers like <b>KPDF</b> (for <b>PDF</b>) and <b>KDVI</b> (for <b>DVI</b>) in <b>KDE 4</b>, providing a unified interface for various document types. Since its inception, Okular has been a core component of the <b>KDE Applications</b> suite, leveraging powerful libraries like <b>Poppler</b> for <b>PDF</b> rendering and various other backends for different formats. Its continuous development focuses on stability, feature enrichment, and integration within the KDE ecosystem.<br>


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the program's version number and exit.<br><br><b>-a, --analyze</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform analysis of the VBA macros (default behavior, often used for clarity).<br><br><b>-c, --code</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only the VBA source code found in the document(s).<br><br><b>-d, --decompress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress and display the raw VBA stream content without analysis.<br><br><b>-r, --regex <i>&lt;regex&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a Python regular expression to search within the VBA code. Matching lines will be highlighted.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output analysis results in JSON format, suitable for programmatic parsing and integration into automated workflows.<br><br><b>--disable-colors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output, useful when redirecting output to a file or for compatibility with specific terminal emulators.<br><br><b>--loglevel <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging level for diagnostic messages (e.g., <i>debug</i>, <i>info</i>, <i>warning</i>, <i>error</i>).<br><br><b>--no-extract-macros</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only list the presence of macros in the document; do not extract or analyze their content.<br><br><b>--reveal</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to reveal potentially obfuscated strings or values present in the VBA code.<br><br><b>--lax</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not fail on malformed OLE/OpenXML files; try to parse them with a best-effort approach.<br><br>


title: DESCRIPTION
content:
<i>olevba</i> is a powerful command-line tool from the <b>oletools</b> suite designed for the static analysis of Microsoft Office OLE and OpenXML files. Its primary purpose is to extract and analyze VBA (Visual Basic for Applications) macros embedded within documents such as .doc, .xls, .ppt, .docm, .xlsm, .pptm, .docx, .xlsx, and .pptx.<br><br>It plays a crucial role in cybersecurity and malware analysis by identifying potentially malicious VBA code. <i>olevba</i> can detect suspicious keywords, common IOCs (Indicators of Compromise), and auto-executable macro functions (e.g., <i>AutoOpen</i>, <i>Workbook_Open</i>, <i>Document_Open</i>). It can also decompress VBA streams, attempt to reveal obfuscated strings, and provide the extracted source code for deeper inspection. By performing static analysis, it helps analysts quickly triage suspicious documents without executing potentially dangerous code, providing insights into macro behavior and potential threats.


title: CAVEATS
content:
As a static analysis tool, <i>olevba</i> does not execute the VBA macros. Therefore, it may be bypassed by advanced obfuscation techniques, highly dynamic code that builds malicious payloads at runtime, or shellcode execution which is beyond the scope of VBA analysis. It relies on known patterns and keywords, so novel or highly polymorphic malware might evade detection. Always combine static analysis with dynamic analysis for comprehensive security assessments of suspicious documents.


title: TYPICAL USAGE
content:
Security analysts frequently use <i>olevba</i> as a first-pass tool to quickly assess the risk posed by suspicious Office documents. It helps in identifying whether a document contains macros, if those macros are auto-executing, and if they contain suspicious patterns indicative of malware. The output often guides further investigation, either by manually reviewing the extracted code for deeper insights or by subjecting the document to dynamic analysis in a sandboxed environment for behavioral insights.


title: OUTPUT INTERPRETATION
content:
<i>olevba</i>'s output is structured to highlight critical information. It typically displays a summary, including detected OLE streams, VBA code, and identified IOCs. Warnings about suspicious keywords, potential shellcode, or network indicators are clearly flagged. Auto-executable functions (like <i>AutoOpen</i>, <i>Workbook_Open</i>, <i>Document_Open</i>) are noted, indicating the macro's potential to run without user interaction. The extracted VBA source code is also provided, allowing for detailed manual review of the macro's logic and structure.


title: HISTORY
content:
<i>olevba</i> is an integral part of the <b>oletools</b> project, an open-source suite of Python tools developed by Philippe Lagadec. The project emerged to provide robust capabilities for analyzing Microsoft OLE and OpenXML files, particularly in the context of cybersecurity and malware analysis. <i>olevba</i> specifically focuses on VBA macro analysis, evolving over time to address new obfuscation techniques and malicious macro patterns, making it a staple in incident response and threat intelligence workflows.


title: SYNOPSIS
content:
<b>ollama</b> [<i>OPTIONS</i>] <i>COMMAND</i> [<i>ARGUMENTS</i>]<br><br>Common commands:<br><b>ollama</b> <b>run</b> <i>&lt;model&gt;</i><br><b>ollama</b> <b>pull</b> <i>&lt;model&gt;</i><br><b>ollama</b> <b>serve</b>


title: PARAMETERS
content:
<b><b>run</b> <i>&lt;model_name&gt;</i> [<i>prompt</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a specified model. If no prompt is provided, it starts an interactive chat session with the model. Can also be used for single-shot prompts.<br><br><b><b>pull</b> <i>&lt;model_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads a specified model from the <i>Ollama</i> model library to your local machine.<br><br><b><b>create</b> <i>&lt;model_name&gt;</i> <b>-f</b> <i>&lt;modelfile_path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a custom model from a <i>Modelfile</i>, allowing you to define parameters, prompts, and base models for new custom LLMs.<br><br><b><b>list</b> (or <b>ls</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all models that have been downloaded and are available on your local machine.<br><br><b><b>serve</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the <i>Ollama</i> API server, which allows other applications and services to interact with your local models via a REST API.<br><br><b><b>rm</b> <i>&lt;model_name&gt;</i> [<i>...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more specified models from your local storage, freeing up disk space.<br><br><b><b>ps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists currently running <i>Ollama</i> model sessions.<br><br><b><b>push</b> <i>&lt;model_name&gt;</i> [<i>registry</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pushes a local model to a remote <i>Ollama</i> registry or host.<br><br><b><b>cp</b> <i>&lt;source_model&gt;</i> <i>&lt;destination_model&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies an existing model to a new name, creating a duplicate without re-downloading.<br><br><b><b>show</b> <i>&lt;model_name&gt;</i> [<i>info_type</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specified model, such as its license, parameters, or the underlying Modelfile.<br><br><b><b>help</b> [<i>command</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help or specific help for a given <i>Ollama</i> subcommand.<br><br>


title: DESCRIPTION
content:
<i>Ollama</i> is an open-source tool designed to simplify the process of running large language models (LLMs) on your local machine.<br><br>It provides a <b>command-line interface (CLI)</b> and an <b>API</b>, making it exceptionally easy to download pre-trained models, serve them, and interact with them directly from your computer. <i>Ollama</i> handles the complexities of model weights, inference, and hardware acceleration (like GPU support), allowing users to focus on experimentation and development rather than setup intricacies.<br><br>It supports a wide range of popular models from its library and other sources, enabling offline AI applications, privacy-focused LLM usage, and rapid prototyping without relying on cloud services. Its <b>Modelfile</b> system further allows for customization and creation of new models based on existing ones, facilitating fine-tuning and specialized AI deployments. <i>Ollama</i> aims to democratize access to powerful LLMs by making local deployment straightforward for developers and enthusiasts alike.


title: CAVEATS
content:
Running large language models requires significant computational resources. Users should ensure they have sufficient <b>RAM</b> (typically 8GB+ for smaller models, 16GB+ for medium, 32GB+ for larger ones) and, ideally, a compatible <b>GPU</b> (NVIDIA, AMD, or Apple Silicon) for optimal performance. Initial model downloads can be very large (several gigabytes each), requiring ample disk space. While <i>Ollama</i> simplifies deployment, understanding basic LLM concepts and Modelfile syntax is beneficial for advanced usage.


title: MODELFILES
content:
<i>Ollama</i> uses <b>Modelfiles</b>, which are simple text files, to define and create custom models. These files specify parameters like the base model, system prompts, temperature, and other configuration options. This powerful feature allows users to easily fine-tune model behavior or create specialized versions from existing models without deep machine learning expertise.


title: API SERVER
content:
When <b>ollama serve</b> is executed, it exposes a RESTful API (typically on <b>localhost:11434</b>). This enables programmatic interaction with models, allowing developers to integrate <i>Ollama</i> into custom applications, chatbots, web services, or other software, making local LLM capabilities accessible to a broader ecosystem.


title: GPU ACCELERATION
content:
<i>Ollama</i> is designed to automatically detect and leverage available GPU hardware (such as NVIDIA CUDA, AMD ROCm, or Apple Metal) for accelerated inference. This significantly improves the speed and efficiency of running large language models compared to CPU-only execution, which is crucial for real-time applications and larger models.


title: HISTORY
content:
<i>Ollama</i> emerged in 2023, quickly gaining traction for its straightforward approach to local LLM deployment. Prior to <i>Ollama</i>, running models locally often involved more complex setups, such as compiling models or configuring intricate environments. <i>Ollama</i> was developed with the goal of democratizing access to LLMs, packaging the necessary components into a single, easy-to-use binary. It continuously evolves, adding support for new models, improving performance, and enhancing its <i>Modelfile</i> capabilities, cementing its place as a popular tool for offline AI experimentation and development.


title: PARAMETERS
content:
<b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Quiet mode. Suppresses informational messages during the conversion process, showing only errors or critical output.</i><br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Dry run. Parses the schema files and performs syntax checks but does not produce any LDIF output. This is useful for validating the syntax and consistency of schema definitions without actually generating output.</i><br><br><b><b>&lt;schemafile ...&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>One or more paths to OpenLDAP schema definition files. The command will read and convert these files into LDIF entries. These are typically standard text files defining attribute types and object classes.</i><br><br>


title: DESCRIPTION
content:
oLschema2ldif is an <I>OpenLDAP</I> utility designed to convert traditional <I>OpenLDAP</I> schema definition files (often ending in <I>.schema</I> and typically found in <I>/etc/openldap/schema</I>) into <I>LDIF (LDAP Data Interchange Format)</I> entries.<br>These <I>LDIF</I> entries are specifically formatted for use with the <I>cn=config</I> dynamic configuration system introduced in <I>OpenLDAP 2.4</I>. The command parses <I>attribute types</I> and <I>object classes</I> defined in the input schema files and generates corresponding <I>olcAttributeTypes</I> and <I>olcObjectClasses</I> entries, complete with the necessary <I>LDAP</I> object identifiers (<I>OIDs</I>) and syntax definitions.<br>This conversion is crucial for administrators wishing to extend or update an <I>OpenLDAP</I> server's schema by adding these <I>LDIF</I> entries to the <I>cn=config</I> database, often using tools like <I>ldapadd</I> or <I>ldapmodify</I>, without requiring a service restart.


title: CAVEATS
content:
The output <I>LDIF</I> is specifically designed for <I>OpenLDAP's cn=config</I> format and may not be directly compatible with older <I>slapd.conf</I> based schema configurations or other <I>LDAP</I> server implementations. Ensure the input schema files adhere to <I>OpenLDAP's</I> schema syntax rules for successful conversion. The order of schema files might be important if there are inter-dependencies between them.


title: OUTPUT FORMAT
content:
The command produces <I>LDIF</I> entries formatted specifically for the <I>cn=config</I> backend. These entries include <I>olcAttributeTypes</I> and <I>olcObjectClasses</I> definitions, suitable for being added to the <I>cn=schema,cn=config</I> branch of your <I>OpenLDAP</I> directory. Each schema element is typically assigned an index (e.g., <I>cn={0}core</I>, <I>cn={1}cosine</I>) to maintain ordering and uniqueness within the <I>cn=config</I> hierarchy.


title: TYPICAL USAGE
content:
After converting schema files, the generated <I>LDIF</I> is usually piped to <I>ldapadd</I> or redirected to a file for later import.<br><br><b>Example:</b><br><I>oLschema2ldif core.schema cosine.schema > /tmp/my_schemas.ldif</I><br><I>ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/my_schemas.ldif</I>


title: HISTORY
content:
<I>oLschema2ldif</I> is an integral part of the <I>OpenLDAP</I> project, which began as an open-source implementation of the <I>LDAP</I> protocol in the late <I>1990s</I>. The command's necessity arose significantly with the introduction of <I>cn=config</I> in <I>OpenLDAP 2.4</I>. Prior to this, schema definitions were typically managed via static text files referenced in the <I>slapd.conf</I> configuration. <I>cn=config</I> revolutionized <I>OpenLDAP</I> management by allowing the entire server configuration, including schema, to be managed dynamically via <I>LDAP</I> operations. <I>oLschema2ldif</I> was developed to bridge the gap, enabling the vast existing base of static schema files to be easily converted into the new <I>LDIF</I> format required by <I>cn=config</I>, facilitating a smoother transition and continued use of standard schema definitions within the dynamic configuration framework.


title: SYNOPSIS
content:
The <I>omf</I> command is the primary interface for managing your Oh My Fish installation, including its themes and plugins.<br><br><B>Syntax:</B><br><I>omf <command> [arguments...]</I><br><br><B>Examples:</B><br><I>omf install bobthefish</I> (installs a theme)<br><I>omf update</I> (updates OMF and all components)<br><I>omf list plugins</I> (lists installed plugins)


title: PARAMETERS
content:
<b>install <repository|plugin|theme></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a plugin, theme, or a full Oh My Fish setup from a Git repository URL, or by name from the OMF registry. <br>Example: <I>omf install git@github.com/my/plugin.git</I> or <I>omf install bobthefish</I>.<br><br><b>update [plugin|theme]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates Oh My Fish itself, all installed plugins, or specific plugins/themes. <br>Example: <I>omf update</I> or <I>omf update bobthefish</I>.<br><br><b>remove <plugin|theme></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed plugin or theme. <br>Example: <I>omf remove agnoster</I>.<br><br><b>list [plugins|themes]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently installed plugins or themes. <br>Example: <I>omf list plugins</I>.<br><br><b>channel <branch_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the update channel for Oh My Fish (e.g., <I>stable</I>, <I>next</I>). <br>Example: <I>omf channel next</I>.<br><br><b>theme <subcommand></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A subcommand for managing themes. Common subcommands include <I>install</I>, <I>use</I> (to set the active theme), and <I>list</I>.<br><br><b>plugin <subcommand></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A subcommand for managing plugins. Common subcommands include <I>install</I>, <I>enable</I>, <I>disable</I>, and <I>list</I>.<br><br><b>doctor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs diagnostic checks to identify and suggest fixes for common Oh My Fish issues.<br><br><b>help [command]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help or detailed help for a specific <I>omf</I> subcommand.<br><br>


title: DESCRIPTION
content:
Oh My Fish (<B>OMF</B>) is a powerful and extensible framework for the <I>Fish shell</I>. It simplifies the process of managing themes, plugins, and custom functions, significantly enhancing the <I>Fish shell</I> experience. <B>OMF</B> allows users to easily install, update, and remove community-contributed themes and plugins, which can extend the shell's functionality, change its appearance, or automate common tasks. It provides a structured way to organize and load configurations, making the <I>Fish shell</I> more modular and user-friendly, especially for those who want to customize their command-line environment without writing complex shell scripts from scratch. <B>OMF</B> aims to bring a similar level of ease-of-use and extensibility to <I>Fish</I> as <I>Oh My Zsh</I> does for <I>Zsh</I>. It handles dependency management and updates for its installed components, ensuring a smooth and powerful interactive shell environment.


title: CAVEATS
content:
Oh My Fish is not a core Linux utility; it is a framework specifically designed for the <I>Fish shell</I>. Therefore, it requires the <I>Fish shell</I> to be installed and used as the default shell or specifically invoked.<br><br>Its functionality relies on <I>Git</I> for cloning repositories and managing plugins and themes. Configurations and installed components are specific to the <I>Fish shell</I> environment and do not affect other shells like <I>Bash</I> or <I>Zsh</I>.


title: INSTALLATION
content:
Oh My Fish is typically installed by running a single command from its official website, which fetches and executes a script to set up the framework in the user's home directory. This process automatically sets up the <I>omf</I> command, making it available in your <I>Fish shell</I> sessions.


title: THEMES AND PLUGINS ECOSYSTEM
content:
<B>OMF</B> provides a vast repository of community-contributed themes to customize the shell's appearance and plugins to extend its functionality. These can range from advanced Git prompts and syntax highlighting to utility functions for various development tasks. Users can easily discover and install these components using the <I>omf install</I> command, enhancing their command-line workflow with minimal effort.


title: HISTORY
content:
Oh My Fish was created to provide a robust and easy-to-use plugin and theme management system for the <I>Fish shell</I>, mirroring the success and community around <I>Oh My Zsh</I> for <I>Zsh</I>. It began as an independent project to fill this gap in the <I>Fish</I> ecosystem, allowing users to extend their shell's capabilities without requiring deep scripting knowledge. Its development is community-driven, with contributions from many users adding new plugins and themes, and continuously improving the core framework. It gained popularity as the <I>Fish shell</I> itself grew in adoption, offering a user-friendly and powerful interactive shell experience.


title: PARAMETERS
content:
<b><b>-s</b> <I>server</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the specified <I>server</I> (IP address or hostname). Default is localhost.<br><br><b><b>-p</b> <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the specified <I>port</I> on the server. Default is 7911.<br><br><b><b>-k</b> <I>key-file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a shared secret <I>key-file</I> for authentication. This file must contain a key declaration matching one configured in <I>dhcpd.conf</I>.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the connection in read-only mode. No modifications can be made to the DHCP server's configuration.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing more verbose output for troubleshooting.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables development mode, typically for internal use and more granular debugging.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects immediately upon startup without waiting for an explicit <I>connect</I> command.<br><br><b><b>-l</b> <I>lease-file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative DHCP lease database file to read. This is usually for debugging or inspection of a specific lease file.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <b>omshell</b>.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br>


title: DESCRIPTION
content:
<b>omshell</b> is an interactive object management API (OMAPI) shell. It allows administrators to connect to and interact with the ISC DHCP server (<I>dhcpd</I>) using the OMAPI protocol. This shell provides a programmatic interface to inspect and modify the DHCP server's runtime configuration, including leases, host declarations, and other dynamic objects. It's particularly useful for automating tasks, debugging, or making on-the-fly changes to a running DHCP service without restarting it.<br><br><b>omshell</b> communicates with <I>dhcpd</I> over a network socket, typically on a local host, and often requires shared secret authentication using a key file for security. It presents a command-line interface where users can issue OMAPI commands like <I>connect</I>, <I>new</I>, <I>open</I>, <I>set</I>, <I>get</I>, <I>update</I>, <I>remove</I>, and <I>end</I> to manipulate DHCP objects. This powerful tool provides granular control over the DHCP server's operational state.


title: CAVEATS
content:
<ul><li><b>omshell</b> requires the ISC DHCP server (<I>dhcpd</I>) to be running and configured to accept OMAPI connections. The <I>omapi-port</I> and <I>key</I> declarations must be present in <I>dhcpd.conf</I>.</li><br><li>Authentication using a shared secret <I>key-file</I> is crucial for security. Without proper keys, connection might be denied or insecure.</li><br><li>Modifications made through <b>omshell</b> directly affect the running <I>dhcpd</I> instance. Care should be taken as incorrect commands can disrupt DHCP services.</li><br><li>It's a specialized tool for DHCP management, not a general-purpose network utility. Its syntax and commands are specific to OMAPI.</li></ul>


title: <I>OMAPI PROTOCOL BASICS</I>
content:
The Object Management API (OMAPI) is a simple, extensible protocol used by ISC DHCP software to manipulate and query objects. <b>omshell</b> leverages this protocol to send commands and receive responses from the DHCP server. OMAPI objects can represent leases, hosts, subnets, and other DHCP-related entities. Commands within <b>omshell</b> (e.g., <I>new lease</I>, <I>open host</I>, <I>set ip-address</I>, <I>update</I>) directly map to OMAPI operations.


title: <I>SECURITY CONSIDERATIONS</I>
content:
Due to its ability to modify the running DHCP server, <b>omshell</b> connections are typically secured using shared secret keys. These keys are defined in <I>dhcpd.conf</I> and referenced by <b>omshell</b> via the <b>-k</b> option. It's critical to protect these key files and restrict <b>omshell</b> access to authorized administrators, as unauthorized access could lead to network disruption or IP address conflicts.


title: <I>COMMON INTERACTIVE COMMANDS</I>
content:
Once connected, <b>omshell</b> supports various commands for object manipulation:<br><I>connect</I>: Establishes a connection to the DHCP server.<br><I>new <object-type></I>: Creates a new object in memory (e.g., <I>new lease</I>).<br><I>open <object-type></I>: Opens an existing object for manipulation (e.g., <I>open lease</I>).<br><I>set <attribute-name> = <value></I>: Sets an attribute of the currently active object.<br><I>get <attribute-name></I>: Retrieves the value of an attribute.<br><I>update</I>: Applies changes to the object on the server.<br><I>remove</I>: Deletes the object from the server.<br><I>list</I>: Lists available objects/attributes (context-dependent).<br><I>end</I>: Closes the current object or session.


title: HISTORY
content:
<b>omshell</b> has been an integral part of the ISC DHCP distribution for many years, providing a powerful interface for interacting with the DHCP server's OMAPI. Its development is tied directly to the evolution of the OMAPI protocol, which was introduced to allow dynamic management of DHCP objects without requiring a server restart. It reflects ISC's commitment to providing robust and manageable network services.


title: SYNOPSIS
content:
<B>omz</B> <I>command</I> [<I>options</I>] [<I>arguments</I>]<br><br>Examples:<br><b>omz update</b><br><b>omz plugin install</b> <I>zsh-syntax-highlighting</I><br><b>omz theme set</b> <I>agnoster</I>


title: PARAMETERS
content:
<b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the Oh My Zsh framework to its latest version, fetching changes from the official repository.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help information for the <B>omz</B> command or detailed help for a specific subcommand.<br><br><b>plugin <action> [name]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Oh My Zsh plugins. Common actions include: <I>install</I> (to add a new plugin), <I>enable</I> (to activate an installed plugin), <I>disable</I> (to deactivate a plugin), and <I>list</I> (to show installed plugins).<br><br><b>theme <action> [name]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Oh My Zsh themes. Common actions include: <I>set</I> (to apply a specific theme), <I>enable</I> (to activate a theme), <I>disable</I> (to deactivate a theme), and <I>list</I> (to show available themes).<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the main <I>.zshrc</I> configuration file in your default editor, allowing direct customization.<br><br><b>doctor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a diagnostic check on your Oh My Zsh installation to identify common issues and suggest fixes.<br><br><b>about</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about the Oh My Zsh framework, including its version and contributing details.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current version number of your Oh My Zsh installation.<br><br>


title: DESCRIPTION
content:
<I>Oh My Zsh</I> is a popular open-source, community-driven framework for managing your <I>Zsh</I> configuration. The <B>omz</B> command-line utility serves as its primary interface, simplifying tasks such as updating the framework, installing and managing plugins, applying themes, and performing general maintenance.<br><br>It provides a centralized way to interact with the vast ecosystem of <I>Oh My Zsh</I>, abstracting the underlying <I>Git</I> operations and directory structures. This makes customizing and extending your <I>Zsh</I> shell environment significantly easier and more accessible for users.


title: CAVEATS
content:
The <B>omz</B> command is not a standard Linux utility; it is part of the <I>Oh My Zsh</I> framework and requires <I>Zsh</I> to be your default shell or actively used. Its availability and exact functionality depend on your Oh My Zsh installation and version. Some subcommands might require network access for updates or plugin installations.


title: INSTALLATION
content:
<I>Oh My Zsh</I> is typically installed by executing a script downloaded via <I>curl</I> or <I>wget</I> from its official GitHub repository. This script automatically clones the repository and sets up the basic configuration.


title: CONFIGURATION FILE
content:
The primary configuration for <I>Oh My Zsh</I> and your <I>Zsh</I> shell resides in the <B>~/.zshrc</B> file. This file is where you enable plugins, set themes, define aliases, and add custom functions.


title: EXTENSIBILITY
content:
<I>Oh My Zsh</I> boasts a rich ecosystem of plugins and themes contributed by its community. Plugins extend shell functionality (e.g., auto-suggestions, syntax highlighting), while themes customize the appearance of your prompt.


title: HISTORY
content:
<I>Oh My Zsh</I> was founded by Robby Russell in 2009 to simplify the management of <I>Zsh</I> configurations. Over time, it evolved into a vast community-driven project. The <B>omz</B> command-line utility was introduced later as a user-friendly interface to streamline common tasks like updating the framework and managing its extensive collection of plugins and themes, abstracting away the manual <I>Git</I> commands previously required.


title: DESCRIPTION
content:
The <i>on_ac_power</i> command is a simple utility designed to determine whether the Linux system is presently connected to an AC power source. It is often employed in shell scripts or automated tasks to dynamically adjust system behavior based on power availability. For instance, scripts might use it to enable or disable power-saving features, dim the screen, or modify CPU frequency scaling when switching between battery and AC power.<br><br>The command's primary function is to return an exit status that signifies the current power state: typically 0 for AC power and a non-zero value (usually 1) for battery power. This makes it highly effective for use in conditional logic within scripts. Internally, <i>on_ac_power</i> typically queries the system's power management interfaces, such as the <i>sysfs</i> filesystem (e.g., by checking the state of <i>/sys/class/power_supply/AC*/online</i>) or by interacting with power management daemons like <i>Upower</i>. While its direct availability can vary across different Linux distributions and system versions (often being part of older power management utility packages like <i>pm-utils</i>), its core role in adaptive power management remains valuable.


title: CAVEATS
content:
The availability and exact behavior of the <i>on_ac_power</i> command can vary considerably between Linux distributions and their versions. It was historically a common component of the <i>pm-utils</i> package. However, in more modern systems, its functionality might be integrated into or superseded by more comprehensive power management services like <i>Upower</i>, or it might not be provided as a standalone binary at all. Users should verify its presence on their specific system. The accuracy of its output depends entirely on the underlying kernel drivers and hardware correctly reporting the power status.


title: EXIT STATUS
content:
The <i>on_ac_power</i> command communicates the system's power status through its exit code:<br><br>An exit status of <b>0</b> indicates that the system is currently running on AC power.<br>An exit status of <b>1</b> indicates that the system is currently running on battery power.<br>An exit status greater than 1 typically signifies an error condition or an inability to determine the power status.<br><br>This simple, clear exit status design makes <i>on_ac_power</i> exceptionally useful for conditional execution in shell scripts, allowing for logic like <i>if on_ac_power; then echo 'On AC'; else echo 'On Battery'; fi</i>.


title: HISTORY
content:
The <i>on_ac_power</i> command emerged as a practical utility within the broader landscape of Linux power management, particularly with the rise of laptops and mobile computing. It was frequently bundled as part of the <i>pm-utils</i> suite, a collection of scripts aimed at managing power states for portable devices. Its development was driven by the necessity for systems to automatically adapt their operational profile (e.g., performance vs. battery life) depending on the power source. As Linux power management matured and became more integrated with desktop environments and standardized D-Bus services like <i>Upower</i>, the standalone role of <i>on_ac_power</i> sometimes shifted. While still functional where present, modern approaches often leverage more centralized power information services, sometimes rendering <i>on_ac_power</i> as either a legacy tool or a simple wrapper around more advanced APIs.


title: PARAMETERS
content:
<b><I>query</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The keyword(s) or phrase to search for across the Tor network.<br><br><b><b>-s</b>, <b>--search-engines</b> <I>engine1,engine2,...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a comma-separated list of search engines to use (e.g., <i>ahmia</i>, <i>notevil</i>, <i>darksearch</i>). If omitted, typically uses a default set.<br><br><b><b>-n</b>, <b>--num-results</b> <I>number</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of results to fetch per search engine.<br><br><b><b>-o</b>, <b>--output</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the search results to the specified file instead of printing to standard output.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, displaying more details about the search process and requests.<br><br><b><b>-x</b>, <b>--proxy</b> <I>protocol://host:port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative SOCKS5 proxy to use for Tor connections (e.g., <i>socks5://127.0.0.1:9050</i>).<br><br><b><b>-t</b>, <b>--timeout</b> <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the connection timeout in seconds for network requests.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br>


title: DESCRIPTION
content:
<i>onionsearch</i> is a command-line utility designed to query various search engines operating on the Tor network (dark web). It automates the process of searching for <b>.onion</b> hidden services, providing a convenient way to discover content not indexed by conventional search engines.<br><br>It typically uses the Tor proxy to anonymize requests, ensuring user privacy. The tool aggregates results from multiple dark web search engines, presenting them in a consolidated and often parsable format, making it valuable for researchers, journalists, and anyone exploring the hidden parts of the internet.


title: CAVEATS
content:
<i>onionsearch</i> is not a standard Linux command and must be installed separately (e.g., via <i>pip</i> for Python versions).<br><br>It relies on the Tor service being active and accessible, typically through a SOCKS5 proxy on 127.0.0.1:9050. Users should be aware that searching the dark web can expose them to potentially illegal or disturbing content, and they should understand the legal and ethical implications in their jurisdiction.


title: INSTALLATION
content:
<i>onionsearch</i> is typically installed via Python's package manager: <br>pip install onionsearch<br>Ensure Python 3 and <i>pip</i> are installed on your system.


title: DEPENDENCIES
content:
Requires Python, along with specific Python libraries such as <i>requests</i>, <i>socks</i>, and <i>stem</i>, which are usually handled automatically during <i>pip</i> installation.


title: HISTORY
content:
<i>onionsearch</i> emerged as a tool primarily developed by s0md3v, aiming to simplify the process of searching Tor hidden services. Its development reflects the growing need for accessible open-source intelligence (OSINT) tools capable of navigating the hidden layers of the internet. It leverages existing dark web search engines, abstracting away the complexities of direct interaction and offering a unified interface for discovery.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available commands and options.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <i>oomctl</i> utility.<br><br><b>--root <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative root path for the cgroup v2 hierarchy. Useful for testing or custom setups where cgroup v2 is not mounted at its default location.<br><br><b>status [CGROUP]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current OOM state and statistics for specified cgroups. If no <i>CGROUP</i> path is provided, it typically shows information for the cgroup from which the command is executed.<br><br><b>set <CGROUP> <PROPERTY> <VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets an OOM-related property for a specified cgroup. Common properties include <i>memory.oom.group</i> (enables/disables OOM killing for the cgroup as a whole) and <i>memory.oom.group.stat</i>. For example, 'set /sys/fs/cgroup/user.slice/user-1000.slice memory.oom.group 1' enables OOM group killing for that cgroup.<br><br><b>kill <CGROUP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually triggers an OOM kill within the specified cgroup. This can be used for debugging OOM scenarios or to proactively enforce resource limits by terminating processes in a specific cgroup.<br><br>


title: DESCRIPTION
content:
<i>oomctl</i> is a utility to inspect and control the Linux kernel's Out-Of-Memory (OOM) killer. It primarily interacts with the OOM killer's behavior within cgroup v2 memory controllers. System administrators can use <i>oomctl</i> to query the OOM status of specific cgroups, configure OOM protection settings for tasks and cgroups, and manually trigger OOM kills for debugging or resource management. This command provides a structured interface to kernel mechanisms that decide which process to terminate when system memory is exhausted, offering finer-grained control than global sysctl settings. It's crucial for managing resource contention in containerized or virtualized environments.


title: CAVEATS
content:
<i>oomctl</i> requires root privileges to operate. It is primarily designed for and interacts exclusively with the Linux kernel's cgroup v2 hierarchy. Incorrect usage, especially with the <i>kill</i> subcommand or by setting incorrect properties, can lead to unexpected process terminations or system instability. Always understand the implications before modifying OOM settings.


title: OOM KILLER
content:
The Out-Of-Memory (OOM) killer is a core Linux kernel mechanism that identifies and terminates processes when the system experiences severe memory exhaustion. Its primary goal is to free up memory and prevent the entire system from crashing or becoming unresponsive. <i>oomctl</i> allows administrators to influence how this mechanism behaves within specific cgroups, offering granular control over which processes are targeted.


title: CGROUP V2
content:
Control Groups version 2 (cgroup v2) is the unified, hierarchical resource management system in the Linux kernel. It provides a more robust and flexible way to allocate and isolate system resources like CPU, memory, and I/O for groups of processes. Unlike cgroup v1, it offers a single hierarchy. <i>oomctl</i> leverages the memory controller features of cgroup v2 to manage OOM behavior on a per-cgroup basis, enabling fine-grained memory management for applications and containers.


title: HISTORY
content:
<i>oomctl</i> is a relatively recent addition to Linux utility sets, designed to provide a more structured and user-friendly interface to the cgroup v2 OOM controls. Before its existence, managing OOM behavior within cgroups often involved direct manipulation of cgroup filesystem files (e.g., <i>memory.oom.group</i>) using commands like `echo`. Its development aimed to simplify OOM killer management, particularly in containerized and cloud environments where precise resource control is crucial for stability and efficiency.


title: SYNOPSIS
content:
<b>ooniprobe</b> [<I>GLOBAL OPTIONS</I>] <I>COMMAND</I> [<I>COMMAND OPTIONS</I>] [<I>ARGUMENTS</I>]<br><br>Examples:<br><b>ooniprobe run web_connectivity --input urls.txt</b><br><b>ooniprobe list tests</b><br><b>ooniprobe version</b>


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b><b>--verbose</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be verbose. Print more detailed output during execution.<br><br><b><b>--quiet</b>, <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be quiet. Suppress non-essential output.<br><br><b><b>--batch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in batch mode, do not ask for user input.<br><br><b><b>--software-name</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the software name to be included in the measurement metadata.<br><br><b><b>--software-version</b> <I>version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the software version to be included in the measurement metadata.<br><br><b><b>--probe-ip</b> <I>ip</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually set the probe's IP address. Use with caution as it affects location inference.<br><br><b><b>--probe-asn</b> <I>asn</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually set the probe's Autonomous System Number (ASN). For example, AS1234.<br><br><b><b>--probe-cc</b> <I>cc</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually set the probe's country code (ISO 3166-1 alpha-2). For example, US.<br><br><b><b>--resolver</b> <I>ip:port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific DNS resolver for network measurements. For example, 8.8.8.8:53.<br><br><b><b>--config</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific configuration file instead of the default.<br><br><b><b>--temp-dir</b> <I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific temporary directory for storing temporary files.<br><br><b><b>run</b> <I>TEST_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a specific OONI network measurement test. <I>TEST_NAME</I> can be 'web_connectivity', 'dns_consistency', 'http_invalid_request_line', etc.<br><br><b><b>--input</b> <I>file|URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'run' command: Path to a file or a URL containing a list of inputs for the test (e.g., URLs for 'web_connectivity').<br><br><b><b>--output</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'run' command: Write the measurement results to the specified file.<br><br><b><b>--num-measurements</b> <I>n</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'run' command: Perform a specific number of measurements for the test.<br><br>


title: DESCRIPTION
content:
<b>ooniprobe</b> is the command-line interface for the Open Observatory of Network Interference (OONI), a free software project dedicated to detecting internet censorship, surveillance, and traffic manipulation globally. It allows users to run a suite of network measurement tests to explore whether specific websites or services are blocked, if DNS resolution is tampered with, or if other forms of network interference are present.<br><br>The collected data is openly published on the <I>OONI Explorer</I>, contributing to transparency and accountability in internet freedom. Running <b>ooniprobe</b> helps identify internet blockages and understand the methods used for censorship in different regions. It's a vital tool for researchers, journalists, and anyone concerned about internet freedom.


title: CAVEATS
content:
<b>Privacy:</b> While OONI strives for privacy, running tests reveals your IP address to the tested services and OONI's infrastructure. OONI publishes anonymized measurement data openly on the <I>OONI Explorer</I>. Users should be aware that contributing data involves sharing information about their network and the test outcomes.<br><br><b>Legality:</b> In some jurisdictions, running network measurements, attempting to bypass censorship, or accessing certain content might be illegal. Users should check local laws before running <b>ooniprobe</b>.<br><br><b>Network Impact:</b> Running multiple measurements can consume significant network bandwidth and may impact network performance during the test period.


title: HISTORY
content:
OONI (Open Observatory of Network Interference) was founded in 2012 as a project of The Tor Project. Its primary goal was to empower users and researchers to detect, measure, and report on internet censorship and other forms of network interference around the globe. Over the years, OONI has grown into an independent organization, continually developing and refining its suite of measurement tools, including the <b>ooniprobe</b> command-line client, to provide increasingly accurate and comprehensive insights into internet freedom.


title: SYNOPSIS
content:
<b><I>op</I></b> [<i>GLOBAL_OPTIONS</i>] <i>COMMAND</i> [<i>COMMAND_OPTIONS</i>] [<i>ARGUMENTS...</i>]


title: PARAMETERS
content:
<b><b><I>--help</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b><I>op</I></b> command or a specific subcommand.<br><br><b><b><I>--version</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version of the <b><I>op</I></b> CLI tool.<br><br><b><b><I>--format</I></b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for commands that return structured data (e.g., <i>json</i>, <i>text</i>). Defaults to <i>text</i> for human-readable output.<br><br><b><b><I>--account</I></b> <i>&lt;shorthand&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the 1Password account to use when multiple accounts are configured. Uses the shorthand configured during sign-in.<br><br><b><b><I>--vault</I></b> <i>&lt;vault-name-or-UUID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with subcommands like <b><I>item create</I></b> or <b><I>item list</I></b> to specify the target vault. (Note: Most options are specific to subcommands, not global.)<br><br>


title: DESCRIPTION
content:
The <b><I>op</I></b> command-line tool is the official interface for interacting with 1Password accounts from the terminal. It enables users to securely manage and access their 1Password data, including logins, secure notes, credit cards, and more, directly from the command line.<br><br>Primarily, <b><I>op</I></b> is used for automation, scripting, and integrating 1Password into development workflows, CI/CD pipelines, and server environments. It allows retrieval of secrets, creation/updating of items, and management of vaults, users, and groups without requiring the graphical 1Password application. It supports various authentication methods, including session tokens and service account tokens, ensuring secure access to sensitive information.<br><br>While not a standard Linux utility, it is widely adopted in environments where secure secret management and programmatic access to 1Password are crucial.


title: CAVEATS
content:
The <b><I>op</I></b> command is the 1Password CLI tool and is not part of a standard Linux distribution; it must be installed separately. It requires an active 1Password account and subscription to function. Proper authentication (e.g., via <b><I>op signin</I></b>) is necessary to interact with your 1Password data. For security, it's crucial to manage session tokens carefully and avoid hardcoding them directly in scripts, especially in production environments.


title: SUBCOMMAND STRUCTURE
content:
The <b><I>op</I></b> command operates using a subcommand structure, where the main command is followed by a specific action. Examples include: <br><b><I>op signin</I></b>: Authenticates with your 1Password account.<br><b><I>op item get</I></b>: Retrieves an item from 1Password.<br><b><I>op item create</I></b>: Creates a new item.<br><b><I>op vault list</I></b>: Lists all vaults you have access to.<br><b><I>op read</I></b>: A convenient command to read specific fields from items or even entire documents. <br>Each subcommand has its own set of options and arguments, which can be viewed using <b><I>op &lt;subcommand&gt; --help</I></b>.


title: COMMON USE CASES
content:
<b><I>op</I></b> is frequently used for:<br> - Retrieving API keys or database credentials in scripts.<br> - Injecting secrets into environment variables for applications.<br> - Automating the provisioning of new login items or secure notes.<br> - Managing 1Password users and groups programmatically.<br> - Integrating with CI/CD systems to securely access secrets during build and deployment processes.


title: HISTORY
content:
The <b><I>op</I></b> command-line tool has been developed by AgileBits (now 1Password) to provide programmatic access to 1Password. It has evolved significantly over the years, with early versions primarily focused on item retrieval, and later versions expanding to full item management, vault management, and integration with 1Password Connect and Service Accounts for more robust automation and CI/CD use cases. Its development reflects the growing need for secure secret management in automated workflows.


title: SYNOPSIS
content:
<b>opam</b> [<I>global-options</I>] <I>command</I> [<I>command-options</I>] [<I>arguments</I>]<br><br>Common commands include:<br><b>opam init</b><br><b>opam switch</b> {list | create | set | remove} [<I>switch-name</I> | <I>ocaml-version</I>]<br><b>opam install</b> <I>package-name</I>...<br><b>opam update</b><br><b>opam upgrade</b><br><b>opam remove</b> <I>package-name</I>...<br><b>opam pin</b> {add | remove | list} <I>package-name</I> [<I>source-path</I>]<br><b>opam exec</b> -- <I>command</I> [<I>args</I>...]<br><b>opam config</b> {env | exec}


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <b>opam</b> or a specific command.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <b>opam</b> version number.<br><br><b>--root=<I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <b>opam</b> root directory (default: <I>~/.opam</I>).<br><br><b>--color=<I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls color output (<I>auto</I>, <I>always</I>, <I>never</I>).<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the command's actions without making actual changes.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs information in JSON format for commands that support it.<br><br><b>--yes, -y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically answers <I>yes</I> to all prompts.<br><br><b>--no-strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables strict sanity checks during operations.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output messages.<br><br>


title: DESCRIPTION
content:
<b>opam</b> is the official source-based package manager for OCaml. It enables users to install, upgrade, and manage multiple OCaml compilers and their associated libraries in isolated environments called <i>switches</i>. <b>opam</b> resolves package dependencies automatically, fetches sources, compiles, and installs software from official repositories and custom sources. This isolation prevents conflicts between different OCaml projects and ensures reproducibility. It provides powerful functionalities for managing development workflows, including pinning specific versions of packages, setting up development environments (via <b>opam env</b>), and extending its capabilities through plugins. <b>opam</b> is fundamental for modern OCaml development, offering a robust and flexible way to manage the entire OCaml toolchain and its ecosystem.


title: CAVEATS
content:
<b>Disk Usage</b>: <b>opam</b> can consume significant disk space, especially with multiple switches and compiled packages, as each switch often duplicates compilers and libraries.<br><b>Initial Setup</b>: Requires <b>opam init</b> to be run once to set up the <b>opam</b> root directory and integrate with your shell.<br><b>Shell Integration</b>: Proper shell integration (e.g., via <I>eval $(opam env)</I>) is crucial for <b>opam</b> to function correctly by adjusting environment variables (like <I>PATH</I> and <I>OCAML_TOPLEVEL_PATH</I>). Without it, OCaml tools installed by <b>opam</b> might not be found.<br><b>Complexity</b>: While powerful, <b>opam</b>'s advanced features (e.g., custom repositories, intricate switch management) can have a learning curve for new users.


title: SWITCHES
content:
<b>opam</b>'s core concept for managing isolated OCaml development environments. Each <i>switch</i> contains a specific OCaml compiler version and its own set of installed packages, preventing conflicts between different projects that might require different compiler versions or library dependencies. Users can easily create, list, and switch between these environments using the <b>opam switch</b> command.


title: REPOSITORIES
content:
<b>opam</b> retrieves packages from <i>repositories</i>, which are collections of package definitions (e.g., version constraints, build instructions). The main repository is <I>opam/opam-repository</I>, hosted on GitHub, containing thousands of OCaml packages. Users can add custom repositories for private packages or experimental versions.


title: ENVIRONMENT CONFIGURATION
content:
After <b>opam init</b>, <b>opam</b> requires shell integration (e.g., via <I>eval $(opam env)</I>) to correctly set environment variables. This ensures that the shell's <I>PATH</I> points to the executables within the current <b>opam</b> switch, and other variables like <I>OCAML_TOPLEVEL_PATH</I> are configured for interactive OCaml sessions. This setup is crucial for <b>opam</b>-managed tools to be accessible.


title: HISTORY
content:
<b>opam</b> was initially developed by OCamlPro and first released around 2012. It quickly became the de-facto package manager for the OCaml ecosystem, addressing the long-standing need for a robust and reproducible way to manage OCaml compilers and libraries. Its introduction significantly streamlined OCaml development, making it easier for developers to manage dependencies, switch between compiler versions, and share reproducible project environments. The project later transitioned to community maintenance under the OCaml Foundation, with active development continuing to enhance its features and stability. It is a cornerstone of modern OCaml tooling, underpinning many projects and development workflows.


title: SYNOPSIS
content:
<b>xdg-open</b> [<i>options</i>] {<i>file</i> | <i>URL</i>}<br><b>xdg-open</b> --help<br><b>xdg-open</b> --manual<br><b>xdg-open</b> --version<br><b>xdg-open</b> --dry-run {<i>file</i> | <i>URL</i>}


title: PARAMETERS
content:
<b><i>file</i> | <i>URL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the file or the URL to be opened. This is a mandatory argument.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run; instead of opening the file or URL, it prints the command that would have been executed. This is useful for debugging.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>--manual</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the full manual page for <i>xdg-open</i> and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>xdg-utils</i> version information and exits.<br><br>


title: DESCRIPTION
content:
<i>xdg-open</i> is a desktop-agnostic command-line utility designed to open files or URLs using the user's default preferred application. It's a core component of the <b>xdg-utils</b> package, providing a standardized way to interact with graphical desktop environments from the command line. When supplied with a file path, <i>xdg-open</i> determines the file's MIME type and launches the appropriate application (e.g., a web browser for HTML, an image viewer for JPEGs, a document viewer for PDFs). For URLs, it typically opens the default web browser. This command effectively abstracts away the differences between various desktop environments like GNOME, KDE, and XFCE, offering a unified interface for launching resources. Its functionality is built upon the freedesktop.org specifications, ensuring consistent behavior across most modern Linux distributions.


title: CAVEATS
content:
<b>xdg-open</b> is primarily intended for use within graphical desktop environments. Its functionality may be limited or non-existent in purely command-line or headless server setups without an X server.<br>Its behavior depends heavily on properly configured MIME types and default application associations within the desktop environment. If these are not set up correctly, <b>xdg-open</b> might fail to open resources or open them with unexpected applications.<br>It offers no direct options for controlling <i>how</i> an application opens a resource (e.g., new tab, specific window); this behavior is dictated by the default application itself.


title: EXIT STATUS
content:
<b>xdg-open</b> returns <i>0</i> on success. A non-zero exit code indicates an error, such as an invalid argument (<i>1</i>), no application handler found for the file/URL (<i>2</i>), an issue with the underlying desktop environment (<i>3</i>), or a generic failure (<i>4</i>).


title: ENVIRONMENT VARIABLES
content:
The behavior of <b>xdg-open</b> can be influenced by various environment variables that define preferred applications. For instance, <b>BROWSER</b> can specify the preferred web browser, <b>VISUAL</b> or <b>EDITOR</b> can specify the preferred text editor. If these are set, <b>xdg-open</b> may prioritize them when selecting an application.


title: HISTORY
content:
The development of <b>xdg-open</b> stems from the freedesktop.org initiative, which aims to standardize aspects of desktop environments on Linux and other Unix-like systems. Before its widespread adoption, applications often had to rely on desktop-specific commands like <i>gnome-open</i> or <i>kde-open</i> to launch files and URLs. This led to fragmented codebases and compatibility issues across different desktop environments.<br><b>xdg-open</b> was introduced as part of the <b>xdg-utils</b> package to provide a unified, desktop-agnostic interface for opening resources. It abstracts the underlying desktop environment's specific mechanisms, offering a consistent command for developers and users. Its role has grown significantly, making it the de facto standard for opening files and URLs from the command line in graphical Linux environments.


title: SEE ALSO
content:
xdg-mime(1), xdg-settings(1), xdg-email(1), sensible-browser(1), gio(1) (specifically <i>gio open</i>), gnome-open(1) (older, superseded by <i>xdg-open</i>), kde-open(1) (older, superseded by <i>xdg-open</i>)


title: PARAMETERS
content:
<b>-b, --background</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <b>openconnect</b> in the background after connecting.<br><br><b>-c, --certificate=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified client certificate file for authentication.<br><br><b>-k, --privatekey=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified private key file for the client certificate.<br><br><b>-u, --user=<i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the username to use for authentication.<br><br><b>-p, --passwd-on-stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read the password from standard input instead of prompting interactively.<br><br><b>--protocol=<i>PROT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the specified VPN protocol (e.g., anyconnect, nc, gp, fortinet, array).<br><br><b>--script=<i>SCRIPT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified script to configure network parameters after connection.<br><br><b>--servercert=<i>SHA1</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pin the server certificate to a specific SHA1 hash for security.<br><br><b>--no-dtls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable the DTLS data tunnel, forcing all data over the TLS control channel.<br><br><b>--disable-ipv6</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent the client from requesting or configuring IPv6 addresses.<br><br>


title: DESCRIPTION
content:
<b>openconnect</b> is a powerful, open-source command-line client for SSL VPNs, primarily designed for compatibility with Cisco AnyConnect VPNs. It extends its support to various other SSL VPN types, including Juniper SSL VPN (via <i>nc</i> protocol), Palo Alto Networks GlobalProtect, Fortinet FortiGate, and Array Networks AG. This utility enables users to securely connect to corporate networks, facilitating remote access to internal resources.<br><br><b>openconnect</b> establishes a secure tunnel over HTTPS, encrypting all traffic between the client and the VPN gateway. It is highly configurable, supporting a wide range of authentication methods like username/password, client certificates, and two-factor authentication. For network configuration, such as setting up DNS and routing, <b>openconnect</b> typically leverages external scripts, most commonly <i>vpnc-script</i>. It can operate in the foreground or background, making it suitable for both interactive and automated use cases. Its flexibility and open-source nature make it a popular choice for Linux users requiring robust VPN connectivity.


title: CAVEATS
content:
Proper functioning often relies on an external VPN script (like <i>vpnc-script</i>) for correct network configuration (DNS, routing). Without it, connectivity might not be fully established even if the tunnel is up. Certain authentication methods, especially those involving client certificates or complex multi-factor authentication, can require intricate configuration.


title: AUTHENTICATION METHODS
content:
<b>openconnect</b> supports a wide range of authentication methods, including basic username and password, client certificates (PKCS#12, PEM), smart cards, and various forms of two-factor authentication (e.g., TOTP, YubiKey) often handled through interactive prompts or form entry options.


title: NETWORK CONFIGURATION SCRIPTS
content:
For <b>openconnect</b> to properly configure network settings such as DNS servers, IP addresses, and routing tables, it relies on an external script specified by the <i>--script</i> option. The most commonly used is <i>vpnc-script</i>, which handles the necessary <i>ip</i> and <i>resolvconf</i> commands to integrate the VPN tunnel into the system's network stack.


title: HISTORY
content:
<b>openconnect</b> originated as a free, open-source alternative to Cisco's proprietary AnyConnect client for Linux and other Unix-like systems. Development began around 2008-2009, with significant contributions from key developers like Dan Luedtke and David Woodhouse. Over the years, its scope expanded beyond just AnyConnect compatibility, incorporating support for Juniper SSL VPN (<i>nc</i> protocol), Palo Alto GlobalProtect, Fortinet, and Array Networks. This evolution has made it a versatile tool for various SSL VPN environments, and its continued development ensures compatibility with newer VPN gateway versions and evolving security standards.


title: PARAMETERS
content:
<b>--config=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative configuration file.<br><br><b>--username=<user></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the VPN username.<br><br><b>--password=<pass></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the VPN password (not recommended on command line for security reasons).<br><br><b>--otp=<otp></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a One-Time Password (TOTP or FortiToken).<br><br><b>--trusted-cert=<hash></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the SHA256 hash of the server certificate to trust for authentication.<br><br><b>--ca-cert=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a CA certificate file for validating the server's certificate.<br><br><b>--client-cert=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a client certificate file for certificate-based authentication.<br><br><b>--client-key=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the private key file for the client certificate.<br><br><b>--port=<port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the default SSL port (443). Can also be specified in <i>host:port</i>.<br><br><b>--persistent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stay connected and re-establish the connection if it drops.<br><br><b>--set-routes=<0|1></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control automatic routing table modifications (1=enable, 0=disable).<br><br><b>--set-dns=<0|1></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control automatic DNS resolver modifications (1=enable, 0=disable).<br><br><b>--no-pppd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use <b>pppd</b> for IP configuration and routing setup.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output for debugging and informational messages.<br><br><b>--proxy=<host>:<port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to the VPN server through an HTTP or SOCKS proxy.<br><br><b>--insecure-ssl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass server certificate validation (<b>highly insecure, not recommended for production!</b>).<br><br><b>--device=<name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the TUN device to create (e.g., tun0).<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<br><i>openfortivpn</i> is an open-source client implementation for the Fortinet FortiGate SSL VPN protocol. It allows Linux and other Unix-like systems to establish a secure VPN connection to a FortiGate firewall, providing access to internal network resources. The client creates a virtual network interface (typically a TUN device) through which all VPN traffic is routed. It supports various authentication methods, including username and password, client certificates, and two-factor authentication (e.g., FortiToken, TOTP).<br><br>Beyond establishing the encrypted tunnel, <i>openfortivpn</i> also handles network configuration aspects like assigning an IP address to the virtual interface, setting up routing tables to direct traffic through the VPN, and managing DNS resolver settings to ensure proper name resolution within the VPN context. It aims to be a lightweight and robust alternative to the official FortiClient, offering compatibility with a wide range of FortiGate firmware versions.


title: CAVEATS
content:
<ul><li>Requires root privileges to set up the TUN device, configure IP addresses, and manipulate routing tables.</li><li>The effectiveness of DNS resolution management depends on the system's DNS setup (e.g., <b>resolvconf</b>, <b>systemd-resolved</b>).</li><li>Using <b>--insecure-ssl</b> compromises security by disabling server certificate validation, making the connection vulnerable to Man-in-the-Middle attacks.</li><li>Compatibility with specific FortiGate firmware versions may vary; regular updates are recommended.</li></ul>


title: CONFIGURATION FILE
content:
Many command-line options can be specified in a configuration file, typically found at <i>/etc/openfortivpn/config</i> or <i>~/.openfortivpn/config</i>. This makes invocation simpler and avoids exposing sensitive information on the command line.<br>The format is <i>option = value</i>. For example:<br>host = vpn.example.com<br>port = 10443<br>username = myuser<br>trusted-cert = abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234


title: ROOT PRIVILEGES
content:
Due to its network configuration tasks (creating a TUN device, setting IP addresses, and modifying routing tables), <i>openfortivpn</i> generally requires root privileges. It is commonly executed using <b>sudo</b> or configured to run as a system service.


title: DNS HANDLING
content:
By default, <i>openfortivpn</i> attempts to update the system's DNS resolver configuration (often <i>/etc/resolv.conf</i>) to use DNS servers provided by the VPN. On systems using <b>resolvconf</b> or <b>systemd-resolved</b>, it tries to integrate seamlessly. If automatic DNS modification is undesirable or problematic, it can be disabled using <b>--set-dns=0</b>, requiring manual DNS configuration.


title: HISTORY
content:
<br><i>openfortivpn</i> emerged as an open-source alternative to the proprietary FortiClient for Linux, which was often less flexible or not consistently updated across various distributions. Initial development aimed to provide a robust and user-friendly client for FortiGate SSL VPNs, focusing on broad compatibility with different FortiGate firmware versions and support for a wide range of authentication methods. It has since become a popular choice for Linux users needing to connect to FortiGate environments, with active community contributions continuously improving and maintaining the project.


title: SYNOPSIS
content:
For the purpose of illustrating interaction with the OpenRC system, the <code>rc-service</code> command is often used to manage individual services.<br><b><code>rc-service <i>&lt;service&gt;</i> [<i>&lt;command&gt;</i> [<i>&lt;arguments&gt;</i>]]</code></b><br><b><code>rc-service --ifneeded <i>&lt;service&gt;</i> [<i>&lt;command&gt;</i> [<i>&lt;arguments&gt;</i>]]</code></b><br><b><code>rc-service --exists <i>&lt;service&gt;</i></code></b><br><b><code>rc-service --resolve <i>&lt;service&gt;</i></code></b><br><b><code>rc-service --dependencies <i>&lt;service&gt;</i></code></b><br><b><code>rc-service --status-all</code></b>


title: PARAMETERS
content:
<b><code>--ifneeded</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Conditionally runs the command only if the service is not already running.<br><br><b><code>--exists</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the specified service script exists.<br><br><b><code>--resolve</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resolves the full path to the service script.<br><br><b><code>--dependencies</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all services that the specified service depends on.<br><br><b><code>--status-all</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the status of all services.<br><br><b><i>&lt;service&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the service to manage (e.g., <code>nginx</code>, <code>sshd</code>).<br><br><b><i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The action to perform on the service. Common commands include:<br><i>start</i>: Starts the service.<br><i>stop</i>: Stops the service.<br><i>restart</i>: Restarts the service.<br><i>reload</i>: Reloads the service's configuration.<br><i>status</i>: Displays the current status of the service.<br><i>zap</i>: Clears the PID file and ensures the service is not running.<br><i>crashed</i>: Checks if the service has crashed.<br><i>configcheck</i>: Checks the service's configuration.<br><br><b><i>&lt;arguments&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional arguments passed to the service script's command.<br><br>


title: DESCRIPTION
content:
OpenRC is a dependency-based init system for Unix-like operating systems. It is designed to be highly configurable, modular, and lightweight, providing a fast and efficient way to manage system services during boot-up and runtime. Unlike monolithic init systems, OpenRC uses a structured approach where service scripts are simple shell scripts that define dependencies, allowing services to start and stop in the correct order. <br><br>While "openrc" refers to the entire init system, direct user interaction often involves specific commands prefixed with <code>rc-</code>, such as <code>rc-service</code> for managing individual services, <code>rc-status</code> for viewing system runlevels and service states, and <code>rc-update</code> for adding or removing services from runlevels. It is a popular choice for distributions that prioritize simplicity and control, like Gentoo and Alpine Linux.


title: CAVEATS
content:
The name "openrc" refers to the entire init system, not a standalone executable command in the traditional sense like <code>ls</code> or <code>grep</code>. Interaction with the OpenRC system primarily occurs through a suite of <code>rc-</code> prefixed commands, such as <code>rc-service</code>, <code>rc-status</code>, <code>rc-update</code>, and <code>rc-config</code>. Therefore, direct <code>openrc</code> command usage as depicted in some command-line tools is atypical; instead, specific <code>rc-*</code> utilities are used to manage services and system state.


title: RUNLEVELS
content:
OpenRC organizes services into runlevels, which define sets of services to be started or stopped for specific system states (e.g., <code>default</code>, <code>boot</code>, <code>sysinit</code>, <code>shutdown</code>). Users can switch between runlevels to change the system's operational mode.


title: SERVICE SCRIPTS
content:
OpenRC service scripts are typically found in <code>/etc/init.d/</code> and are simple shell scripts that define start, stop, and status functions, along with metadata for dependencies and runlevels. This design promotes transparency and ease of customization.


title: DYNAMIC DEPENDENCIES
content:
OpenRC supports dynamic dependency resolution, meaning services can be started based on the presence of required resources (like network interfaces) rather than fixed ordering. This contributes to faster and more robust boot processes.


title: HISTORY
content:
OpenRC was created by Roy Marples, initially for the NetBSD operating system, and later adopted by Gentoo Linux as its default init system in 2007, replacing its traditional System V init scripts. Its design principles emphasize simplicity, POSIX compliance, and avoiding bloat, making it a popular alternative to systemd, especially in distributions like Alpine Linux, which values a small footprint and fast boot times. Development has continued with a focus on stability, performance, and flexibility in managing system services and dependencies.


title: SYNOPSIS
content:
<b>openscad</b> [<i>OPTIONS</i>] [<i>FILE</i>]<br><b>openscad</b> --help<br><b>openscad</b> --version<br><br><i>FILE</i> typically refers to an <i>.scad</i> script to be processed.


title: PARAMETERS
content:
<b>-o <i>&lt;file&gt;</i>, --output=<i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file path. The format is determined by the file extension or the <b>--export-format</b> option.<br><br><b>-D <i>&lt;var&gt;=&lt;val&gt;</i>, --define=<i>&lt;var&gt;=&lt;val&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines or overrides a variable in the <i>.scad</i> script. Multiple <b>-D</b> options can be used.<br><br><b>-p <i>&lt;file&gt;</i>, --parameter-file=<i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads parameters from a JSON file. Useful for managing complex sets of parameters.<br><br><b>-P <i>&lt;name&gt;</i>, --parameter-set=<i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific parameter set from the JSON file specified by <b>--parameter-file</b>.<br><br><b>--export-format=<i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly sets the output format (e.g., <i>stl</i>, <i>amf</i>, <i>3mf</i>, <i>dxf</i>, <i>svg</i>). Overrides format derived from filename.<br><br><b>--imgsize=<i>&lt;width&gt;,&lt;height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the dimensions for image output (e.g., PNG).<br><br><b>--autocenter</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Centers the model in the view before rendering or exporting.<br><br><b>--viewall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the camera to view the entire model before rendering or exporting.<br><br><b>--render</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a complete render of the model before exporting, even if not strictly necessary.<br><br><b>--hardcopy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates output suitable for 2D plotters or laser cutters, typically for SVG projections.<br><br><b>--check-parameters</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs type checking on parameters loaded from files or defined on the command line, reporting errors for mismatches.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most informational messages and warnings during execution.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>OpenSCAD</b> version information and exits.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a summary of command-line options and exits.<br><br>


title: DESCRIPTION
content:
<b>OpenSCAD</b> is a free software application for creating solid 3D CAD objects. Unlike interactive 3D modelers, it focuses on a programmatic approach, using a textual description language (the OpenSCAD language) to define objects. This allows designers to create highly parametric models by utilizing programming constructs such as variables, loops, and conditional statements. Models are typically defined in <i>.scad</i> files.<br><br>The command-line interface of <b>OpenSCAD</b> provides powerful capabilities for batch processing, automated rendering, and exporting models without the need for the graphical user interface. This makes it ideal for integrating into build systems, generating multiple variations of a design, or rendering complex models on remote servers. It supports exporting to common 3D formats like STL, AMF, 3MF, and DXF, making it a popular choice for 3D printing and precision engineering.


title: CAVEATS
content:
Rendering complex or large models can be computationally intensive, requiring significant CPU time and memory resources, especially for high-resolution exports. The programmatic nature of <b>OpenSCAD</b> means that debugging design logic relies on understanding the OpenSCAD language and its execution flow, rather than direct visual manipulation. The command-line interface requires explicit specification of view and output settings, which are handled automatically by the GUI.


title: USAGE EXAMPLES
content:
1. <b>Render a SCAD file to STL:</b><br><i>openscad -o output.stl input.scad</i><br><br>2. <b>Export a 2D projection to SVG for a laser cutter:</b><br><i>openscad -o cutting_board.svg --hardcopy input.scad</i><br><br>3. <b>Render with specific parameters:</b><br><i>openscad -D 'length=100' -D 'width=50' -o box.stl box_design.scad</i><br><br>4. <b>Render an animation frame:</b><br><i>openscad -o frame_001.png --imgsize=800,600 --animate=1 --animation-step=0 input.scad</i><br><br>5. <b>Use a parameter file:</b><br><i>openscad -p config.json -P 'large_version' -o large_model.stl design.scad</i>


title: HISTORY
content:
<b>OpenSCAD</b> was initially created by Marius Kintel, with its first public releases appearing around 2009. The project emerged from a need for a non-interactive, script-based CAD tool focused on constructive solid geometry (CSG) and extrusion. It quickly gained traction within the emerging 3D printing community due to its ability to generate precise, parametric models that are easily reproducible and modifiable through code. Its development has been driven by a strong open-source community, consistently adding features and improving performance, solidifying its role as a unique and powerful tool for algorithmic design.


title: SEE ALSO
content:
<b>make(1)</b>: Often used to automate the process of rendering and exporting <b>OpenSCAD</b> designs, especially in projects with multiple configurations or dependencies., <b>blender(1)</b>: While different in approach (GUI-based polygon modeler), it's another powerful tool for 3D modeling and rendering., <b>freecad(1)</b>: A general-purpose parametric 3D CAD modeler, offering both GUI and scripting capabilities, often used for engineering design.


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the program's version number and then exits.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message detailing the command-line options and then exits.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug messages, providing more detailed output in the terminal which can be useful for troubleshooting.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose messages, offering more detailed information about the application's operations.<br><br><b>-t, --test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables unit tests, typically used by developers for testing the software's components.<br><br><b>--profiler</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the profiler (qtgui.profiler), which helps in analyzing application performance.<br><br><b>--clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cleans all temporary assets generated by OpenShot, such as thumbnails, waveform data, and other cached files.<br><br><b>[project_file]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument to specify an OpenShot project file (.osp) to be opened automatically upon launching the application.<br><br>


title: DESCRIPTION
content:
The <b>openshot</b> command launches the OpenShot Video Editor, a user-friendly, open-source, non-linear video editing software. Designed for Linux, macOS, and Windows, OpenShot aims to provide a stable, feature-rich, and easy-to-use editor for beginners and intermediate users. It supports a wide range of video, audio, and image formats thanks to its integration with FFmpeg. Key features include trimming and slicing, video transitions, effects, title creation, compositing, and animated 3D titles. While primarily a graphical application, the command line allows launching with specific options for debugging, testing, or directly opening a project file.


title: CAVEATS
content:
OpenShot is fundamentally a graphical user interface (GUI) application. Its command-line interface is primarily for launching the program, opening projects, and enabling diagnostic modes. It does not provide extensive command-line options for non-interactive editing, rendering, or scripting of complex video production tasks.


title: CROSS-PLATFORM NATURE
content:
While primarily known and developed for Linux, OpenShot is also available and actively maintained for Windows and macOS, offering a consistent user experience across different operating systems.


title: UNDERLYING TECHNOLOGIES
content:
OpenShot leverages powerful open-source libraries: FFmpeg for video/audio processing, the MLT Framework for core video editing capabilities, and PyQt for its graphical user interface, making it robust and extensible.


title: HISTORY
content:
OpenShot Video Editor was created by Jonathan Thomas in 2008, with the initial goal of providing a free, simple, and stable video editor for Linux. It quickly gained popularity as an open-source alternative to proprietary video editing software. Over the years, it has evolved significantly, transitioning from GTK to PyQt for its GUI toolkit, improving performance, and expanding its features. Its development relies heavily on the MLT Framework and FFmpeg for core multimedia processing, allowing it to support a wide range of formats and effects.


title: SYNOPSIS
content:
<b>sshd</b> [<i>-deDqtv</i>] [<i>-f config_file</i>] [<i>-h host_key_file</i>] [<i>-i</i>] [<i>-p port</i>] [<i>-o option</i>]


title: PARAMETERS
content:
<b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Debug mode. The server will not detach and will log to standard error. Implies <b>-D</b>.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Log to standard error instead of syslog. Often used with <b>-d</b>.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When started, the server will not detach and become a daemon. Useful for running <b>sshd</b> under a process supervisor like <i>systemd</i>.<br><br><b><b>-f</b> <i>config_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default <i>/etc/ssh/sshd_config</i>.<br><br><b><b>-h</b> <i>host_key_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file from which a host key is read. This option may be specified multiple times for different host key types.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used by <i>inetd</i>; indicates that <b>sshd</b> is run from <i>inetd</i>. (Less common in modern systems).<br><br><b><b>-p</b> <i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number that <b>sshd</b> listens on. The default is 22.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test configuration file. <b>sshd</b> will check the validity of the configuration file and exit. This is very useful before restarting the service.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode. Causes <b>sshd</b> to suppress all warning and diagnostic messages.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose mode. Causes <b>sshd</b> to print debugging messages about its progress. This is helpful for debugging connection, authentication, and configuration problems. Multiple <b>-v</b> options increase the verbosity.<br><br>


