neulab/tldr huggingface dataset:
OPTIONS The following options are common to ::safe::interpCreate, ::safe::interpInit, and ::safe::interpConfigure.  Any option name can be abbreviated to its minimal non-ambiguous name.  Option names are not case sensitive.
-accessPath directoryList This option sets the list of directories from which the safe interpreter can source and load files.  If this option is not specified, or if it is given as the empty list, the safe interpreter will use the same directories as its master for auto- loading.  See the section SECURITY below for more detail about virtual paths, tokens and access control.
-statics boolean This option specifies if the safe interpreter will be allowed to load statically linked packages (like load {} Tk).  The default value is true : safe interpreters are allowed to load statically linked packages.
-noStatics This option is a convenience shortcut for -statics false and thus specifies that the safe interpreter will not be allowed to load statically linked packages.
-nested boolean This option specifies if the safe interpreter will be allowed to load packages into its own sub-interpreters.  The default value is false : safe interpreters are not allowed to load packages into their own sub-interpreters.
-nestedLoadOk This option is a convenience shortcut for -nested true and thus specifies the safe interpreter will be allowed to load packages into its own sub-interpreters.
-deleteHook script When this option is given a non-empty script, it will be evaluated in the master with the name of the safe interpreter as an additional argument just before actually deleting the safe interpreter.  Giving an empty value removes any currently installed deletion hook script for that safe interpreter.  The default value ({}) is not to have any deletion call back.
The following aliases are provided in a safe interpreter:
source fileName The requested file, a Tcl source file, is sourced into the safe interpreter if it is found.  The source alias can only source files from directories in the virtual path for the safe interpreter. The source alias requires the safe interpreter to use one of the token names in its virtual path to denote the directory in which the file to be sourced can be found.  See the section on SECURITY for more discussion of restrictions on valid filenames.
load fileName The requested file, a shared object file, is dynamically loaded into the safe interpreter if it is found.  The filename must contain a token name mentioned in the virtual path for the safe interpreter for it to be found successfully.  Additionally, the shared object file must contain a safe entry point; see the manual page for the load command for more details.
file ?subCmd args...? The file alias provides access to a safe subset of the subcommands of the file command; it allows only dirname, join, extension, root, tail, pathname and split subcommands. For more details on what these subcommands do see the manual page for the file command.
encoding ?subCmd args...? The encoding alias provides access to a safe subset of the subcommands of the encoding command;  it disallows setting of the system encoding, but allows all other subcommands including system to check the current encoding.
exit   The calling interpreter is deleted and its computation is stopped, but the Tcl process in which this interpreter exists is not terminated.
Safe Tcl does not attempt to completely prevent annoyance and denial of service attacks. These forms of attack prevent the application or user from temporarily using the computer to perform useful work, for example by consuming all available CPU time or all available screen real estate. These attacks, while aggravating, are deemed to be of lesser importance in general than integrity and privacy attacks that Safe Tcl is to prevent.
The commands available in a safe interpreter, in addition to the safe set as defined in interp manual page, are mediated aliases for source, load, exit, and safe subsets of file and encoding. The safe interpreter can also auto-load code and it can request that packages be loaded.
Because some of these commands access the local file system, there is a potential for information leakage about its directory structure.  To prevent this, commands that take file names as arguments in a safe interpreter use tokens instead of the real directory names.  These tokens are translated to the real directory name while a request to, e.g., source a file is mediated by the master interpreter.  This virtual path system is maintained in the master interpreter for each safe interpreter created by ::safe::interpCreate or initialized by ::safe::interpInit and the path maps tokens accessible in the safe interpreter into real path names on the local file system thus preventing safe interpreters from gaining knowledge about the structure of the file system of the host on which the interpreter is executing.  The only valid file names arguments for the source and load aliases provided to the slave are path in the form of [file join token filename] (i.e. when using the native file path formats: token/filename on Unix and token\filename on Windows), where token is representing one of the directories of the accessPath list and filename is one file in that directory (no sub directories access are allowed).
When a token is used in a safe interpreter in a request to source or load a file, the token is checked and translated to a real path name and the file to be sourced or loaded is located on the file system.  The safe interpreter never gains knowledge of the actual path name under which the file is stored on the file system.
To further prevent potential information leakage from sensitive files that are accidentally included in the set of files that can be sourced by a safe interpreter, the source alias restricts access to files meeting the following constraints: the file name must fourteen characters or shorter, must not contain more than one dot (“.”), must end up with the extension (“.tcl”) or be called (“tclIndex”.)
Each element of the initial access path list will be assigned a token that will be set in the slave auto_path and the first element of that list will be set as the tcl_library for that slave.
If the access path argument is not given or is the empty list, the default behavior is to let the slave access the same packages as the master has access to (Or to be more precise: only packages written in Tcl (which by definition cannot be dangerous as they run in the slave interpreter) and C extensions that provides a _SafeInit entry point). For that purpose, the master's auto_path will be used to construct the slave access path.  In order that the slave successfully loads the Tcl library files (which includes the auto-loading mechanism itself) the tcl_library will be added or moved to the first position if necessary, in the slave access path, so the slave tcl_library will be the same as the master's (its real path will still be invisible to the slave though).  In order that auto-loading works the same for the slave and the master in this by default case, the first-level sub directories of each directory in the master auto_path will also be added (if not already included) to the slave access path.  You can always specify a more restrictive path for which sub directories will never be searched by explicitly specifying your directory list with the -accessPath flag instead of relying on this default mechanism.
When the accessPath is changed after the first creation or initialization (i.e. through interpConfigure -accessPath list), an auto_reset is automatically evaluated in the safe interpreter to synchronize its auto_index with the new token list.
interp(3tcl), library(3tcl), load(3tcl), package(3tcl), source(3tcl), unknown(3tcl)
alias, auto-loading, auto_mkindex, load, master interpreter, safe interpreter, slave interpreter, source
OPENRC(8)                    System Manager's Manual                   OPENRC(8)
openrc â€” stops and starts services for the specified runlevel
openrc [-n, --no-stop] [-o, --override] [runlevel]
openrc first stops any services that are not in the specified runlevel unless --no-stop is specified, then starts any services in the runlevel and stacked runlevels added by rc-update that are not currently started.  If no runlevel is specified, we use the current runlevel.
There are some special runlevels that you should be aware of:
sysinit   Brings up any system specific stuff such as /dev, /proc and optionally /sys for Linux based systems. It also mounts /lib/rc/init.d as a ramdisk using tmpfs where available unless / is mounted rw at boot.  openrc uses /lib/rc/init.d to hold state information about the services it runs.  sysinit always runs when the host first starts should not be run again.
boot      Generally the only services you should add to the boot runlevel are those which deal with the mounting of filesystems, set the initial state of attached peripherals and logging.  Hotplugged services are added to the boot runlevel by the system.  All services in the boot and sysinit runlevels are automatically included in all other runlevels except for those listed here.
single    Stops all services except for those in the sysinit runlevel.
reboot    Changes to the shutdown runlevel and then reboots the host.
shutdown  Changes to the shutdown runlevel and then halts the host.
You should not call any of these runlevels yourself.  Instead you should use init(8) and shutdown(8) and let them call these special runlevels.
openrc-run(8), rc-status(8), rc-update(8), init(8), shutdown(8)
sr elvisname -local-help
Copyright (c) 2003‐2018 The Surfraw-Devel Team <surfraw-devel@lists.alioth.debian.org> Copyright (c) 2000‐2001 Julian Assange <proff@iq.org> Copyright (c) 2001 Australian Institute for Collaborative Research Copyright (c) 2000 Melbourne Institute for Advanced Study
COREDUMPCTL(1)                     coredumpctl                    COREDUMPCTL(1)
coredumpctl - Retrieve and process saved core dumps and metadata
coredumpctl [OPTIONS...] {COMMAND} [PID|COMM|EXE|MATCH...]
coredumpctl is a tool that can be used to retrieve and process core dumps and metadata which were saved by systemd-coredump(8).
list List core dumps captured in the journal matching specified characteristics. If no command is specified, this is the implied default.
The output is designed to be human readable and contains a table with the following columns:
TIME The timestamp of the crash, as reported by the kernel.
PID The identifier of the process that crashed.
UID, GID The user and group identifiers of the process that crashed.
SIGNAL The signal that caused the process to crash, when applicable.
COREFILE Information whether the coredump was stored, and whether it is still accessible: "none" means the core was not stored, "-" means that it was not available (for example because the process was not terminated by a signal), "present" means that the core file is accessible by the current user, "journal" means that the core was stored in the "journal", "truncated" is the same as one of the previous two, but the core was too large and was not stored in its entirety, "error" means that the core file cannot be accessed, most likely because of insufficient permissions, and "missing" means that the core was stored in a file, but this file has since been removed.
EXE The full path to the executable. For backtraces of scripts this is the name of the interpreter.
It's worth noting that different restrictions apply to data saved in the journal and core dump files saved in /var/lib/systemd/coredump, see overview in systemd-coredump(8). Thus it may very well happen that a particular core dump is still listed in the journal while its corresponding core dump file has already been removed.
info Show detailed information about the last core dump or core dumps matching specified characteristics captured in the journal.
dump Extract the last core dump matching specified characteristics. The core dump will be written on standard output, unless an output file is specified with --output=.
debug Invoke a debugger on the last core dump matching specified characteristics. By default, gdb(1) will be used. This may be changed using the --debugger= option or the $SYSTEMD_DEBUGGER environment variable. Use the --debugger-arguments= option to pass extra command line arguments to the debugger.
-1 Show information of the most recent core dump only, instead of listing all known core dumps. Equivalent to --reverse -n 1.
-n INT Show at most the specified number of entries. The specified parameter must be an integer greater or equal to 1.
-S, --since Only print entries which are since the specified date.
-U, --until Only print entries which are until the specified date.
-F FIELD, --field=FIELD Print all possible data values the specified field takes in matching core dump entries of the journal.
-o FILE, --output=FILE Write the core to FILE.
--debugger=DEBUGGER Use the given debugger for the debug command. If not given and $SYSTEMD_DEBUGGER is unset, then gdb(1) will be used.
-A ARGS, --debugger-arguments=ARGS Pass the given ARGS as extra command line arguments to the debugger. Quote as appropriate when ARGS contain whitespace. (See Examples.)
--file=GLOB Takes a file glob as an argument. If specified, coredumpctl will operate on the specified journal files matching GLOB instead of the default runtime and system journal paths. May be specified multiple times, in which case files will be suitably interleaved.
-D DIR, --directory=DIR Use the journal files in the specified DIR.
-q, --quiet Suppresses informational messages about lack of access to journal files and possible in-flight coredumps.
A match can be:
PID Process ID of the process that dumped core. An integer.
COMM Name of the executable (matches COREDUMP_COMM=). Must not contain slashes.
EXE Path to the executable (matches COREDUMP_EXE=). Must contain at least one slash.
MATCH General journalctl match filter, must contain an equals sign ("="). See journalctl(1).
On success, 0 is returned; otherwise, a non-zero failure code is returned. Not finding any matching core dumps is treated as failure.
$SYSTEMD_DEBUGGER Use the given debugger for the debug command. See the --debugger= option.
Example 1. List all the core dumps of a program
$ coredumpctl list /usr/lib64/firefox/firefox TIME     PID  UID  GID SIG     COREFILE EXE                         SIZE Tue ...   8018 1000 1000 SIGSEGV missing  /usr/lib64/firefox/firefox   n/a Wed ... 251609 1000 1000 SIGTRAP missing  /usr/lib64/firefox/firefox   n/a Fri ... 552351 1000 1000 SIGSEGV present  /usr/lib64/firefox/firefox 28.7M
The journal has three entries pertaining to /usr/lib64/firefox/firefox, and only the last entry still has an available core file (in external storage on disk).
Note that coredumpctl needs access to the journal files to retrieve the relevant entries from the journal. Thus, an unprivileged user will normally only see information about crashing programs of this user.
Example 2. Invoke gdb on the last core dump
$ coredumpctl debug
Example 3. Use gdb to display full register info from the last core dump
$ coredumpctl debug --debugger-arguments="-batch -ex 'info all-registers'"
Example 4. Show information about a core dump matched by PID
$ coredumpctl info 6654 PID: 6654 (bash) UID: 1000 (user) GID: 1000 (user) Signal: 11 (SEGV) Timestamp: Mon 2021-01-01 00:00:01 CET (20s ago) Command Line: bash -c $'kill -SEGV $$' Executable: /usr/bin/bash Control Group: /user.slice/user-1000.slice/... Unit: user@1000.service User Unit: vte-spawn-....scope Slice: user-1000.slice Owner UID: 1000 (user) Boot ID: ... Machine ID: ... Hostname: ... Storage: /var/lib/systemd/coredump/core.bash.1000.....zst (present) Disk Size: 51.7K Message: Process 130414 (bash) of user 1000 dumped core.
Stack trace of thread 130414: #0  0x00007f398142358b kill (libc.so.6 + 0x3d58b) #1  0x0000558c2c7fda09 kill_builtin (bash + 0xb1a09) #2  0x0000558c2c79dc59 execute_builtin.lto_priv.0 (bash + 0x51c59) #3  0x0000558c2c79709c execute_simple_command (bash + 0x4b09c) #4  0x0000558c2c798408 execute_command_internal (bash + 0x4c408) #5  0x0000558c2c7f6bdc parse_and_execute (bash + 0xaabdc) #6  0x0000558c2c85415c run_one_command.isra.0 (bash + 0x10815c) #7  0x0000558c2c77d040 main (bash + 0x31040) #8  0x00007f398140db75 __libc_start_main (libc.so.6 + 0x27b75) #9  0x0000558c2c77dd1e _start (bash + 0x31d1e)
Example 5. Extract the last core dump of /usr/bin/bar to a file named bar.coredump
$ coredumpctl -o bar.coredump dump /usr/bin/bar
systemd-coredump(8), coredump.conf(5), systemd-journald.service(8), gdb(1)
PIP(1)                                 pip                                PIP(1)
pip - package manager for Python packages
pip is the PyPA recommended package manager for Python packages
--isolated Run pip in an isolated mode, ignoring environment variables and user configuration.
-q, --quiet Give less output. Option is additive, and can be used up to 3 times (corresponding to WARNING, ERROR, and CRITICAL logging levels).
--log <path> Path to a verbose appending log.
--no-input Disable prompting for input.
--retries <retries> Maximum number of retries each connection should attempt (default 5 times).
--exists-action <action> Default action when a path already exists: (s)witch, (i)gnore, (w)ipe, (b)ackup, (a)bort.
--trusted-host <hostname> Mark this host or host:port pair as trusted, even though it does not have valid or any HTTPS.
--client-cert <path> Path to SSL client certificate, a single file containing the private key and the certificate in PEM format.
--cache-dir <dir> Store the cache data in <dir>.
--no-cache-dir Disable the cache.
--disable-pip-version-check Don't periodically check PyPI to determine whether a new version of pip is available for download. Implied with --no-index.
--no-color Suppress colored output.
--no-python-version-warning Silence deprecation warnings for upcoming unsupported Pythons.
--use-feature <feature> Enable new functionality, that may be backward incompatible.
--use-deprecated <feature> Enable deprecated functionality, that will be removed in the future.
pip-install(1) Install packages.
pip-download(1) Download packages.
pip-uninstall(1) Uninstall packages.
pip-freeze(1) Output installed packages in requirements format.
pip-list(1) List installed packages.
pip-show(1) Show information about installed packages.
pip-check(1) Verify installed packages have compatible dependencies.
pip-search(1) Search PyPI for packages.
pip-wheel(1) Build wheels from your requirements.
pip-hash(1) Compute hashes of package archives.
pip-help(1) Show help for pip commands.
EXPAND(1)                         User Commands                        EXPAND(1)
expand - convert tabs to spaces
expand [OPTION]... [FILE]...
Convert tabs in each FILE to spaces, writing to standard output.
-i, --initial do not convert tabs after non blanks
-t, --tabs=N have tabs N characters apart, not 8
unexpand(1)
Full documentation <https://www.gnu.org/software/coreutils/expand> or available locally via: info '(coreutils) expand invocation'
GOIMPORTS(1)                 General Commands Manual                GOIMPORTS(1)
goimports - updates your Go import lines
goimports [flags] [ path ...  ]
Command goimports updates your Go import lines, adding missing ones and removing unreferenced ones.
Run goimports -help for more details.
NMAP(1)                       Nmap Reference Guide                       NMAP(1)
nmap - Network exploration tool and security / port scanner
nmap [Scan Type...] [Options] {target specification}
Nmap (“Network Mapper”) is an open source tool for network exploration and security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. While Nmap is commonly used for security audits, many systems and network administrators find it useful for routine tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime.
The output from Nmap is a list of scanned targets, with supplemental information on each depending on the options used. Key among that information is the “interesting ports table”.  That table lists the port number and protocol, service name, and state. The state is either open, filtered, closed, or unfiltered.  Open means that an application on the target machine is listening for connections/packets on that port. Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed. Closed ports have no application listening on them, though they could open up at any time. Ports are classified as unfiltered when they are responsive to Nmap's probes, but Nmap cannot determine whether they are open or closed. Nmap reports the state combinations open|filtered and closed|filtered when it cannot determine which of the two states describe a port. The port table may also include software version details when version detection has been requested. When an IP protocol scan is requested (-sO), Nmap provides information on supported IP protocols rather than listening ports.
In addition to the interesting ports table, Nmap can provide further information on targets, including reverse DNS names, operating system guesses, device types, and MAC addresses.
A typical Nmap scan is shown in Example 1. The only Nmap arguments used in this example are -A, to enable OS and version detection, script scanning, and traceroute; -T4 for faster execution; and then the hostname.
Example 1. A representative Nmap scan
# nmap -A -T4 scanme.nmap.org
Nmap scan report for scanme.nmap.org (74.207.244.221) Host is up (0.029s latency). rDNS record for 74.207.244.221: li86-221.members.linode.com Not shown: 995 closed ports PORT     STATE    SERVICE     VERSION 22/tcp   open     ssh         OpenSSH 5.3p1 Debian 3ubuntu7 (protocol 2.0) | ssh-hostkey: 1024 8d:60:f1:7c:ca:b7:3d:0a:d6:67:54:9d:69:d9:b9:dd (DSA) |_2048 79:f8:09:ac:d4:e2:32:42:10:49:d3:bd:20:82:85:ec (RSA) 80/tcp   open     http        Apache httpd 2.2.14 ((Ubuntu)) |_http-title: Go ahead and ScanMe! 646/tcp  filtered ldp 1720/tcp filtered H.323/Q.931 9929/tcp open     nping-echo  Nping echo Device type: general purpose Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6.39 OS details: Linux 2.6.39 Network Distance: 11 hops Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
TRACEROUTE (using port 53/tcp) HOP RTT      ADDRESS [Cut first 10 hops for brevity] 11  17.65 ms li86-221.members.linode.com (74.207.244.221)
Nmap done: 1 IP address (1 host up) scanned in 14.40 seconds
The newest version of Nmap can be obtained from https://nmap.org. The newest version of this man page is available at https://nmap.org/book/man.html.  It is also included as a chapter of Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning (see https://nmap.org/book/).
This options summary is printed when Nmap is run with no arguments, and the latest version is always available at https://svn.nmap.org/nmap/docs/nmap.usage.txt. It helps people remember the most common options, but is no substitute for the in-depth documentation in the rest of this manual. Some obscure options aren't even included here.
Everything on the Nmap command-line that isn't an option (or option argument) is treated as a target host specification. The simplest case is to specify a target IP address or hostname for scanning.
When a hostname is given as a target, it is resolved via the Domain Name System (DNS) to determine the IP address to scan. If the name resolves to more than one IP address, only the first one will be scanned. To make Nmap scan all the resolved addresses instead of only the first one, use the --resolve-all option.
Sometimes you wish to scan a whole network of adjacent hosts. For this, Nmap supports CIDR-style addressing. You can append /numbits to an IP address or hostname and Nmap will scan every IP address for which the first numbits are the same as for the reference IP or hostname given. For example, 192.168.10.0/24 would scan the 256 hosts between 192.168.10.0 (binary: 11000000 10101000 00001010 00000000) and 192.168.10.255 (binary: 11000000 10101000 00001010 11111111), inclusive.  192.168.10.40/24 would scan exactly the same targets. Given that the host scanme.nmap.org is at the IP address 64.13.134.52, the specification scanme.nmap.org/16 would scan the 65,536 IP addresses between 64.13.0.0 and 64.13.255.255. The smallest allowed value is /0, which targets the whole Internet. The largest value for IPv4 is /32, which scans just the named host or IP address because all address bits are fixed. The largest value for IPv6 is /128, which does the same thing.
CIDR notation is short but not always flexible enough. For example, you might want to scan 192.168.0.0/16 but skip any IPs ending with .0 or .255 because they may be used as subnet network and broadcast addresses. Nmap supports this through octet range addressing. Rather than specify a normal IP address, you can specify a comma-separated list of numbers or ranges for each octet. For example, 192.168.0-255.1-254 will skip all addresses in the range that end in .0 or .255, and 192.168.3-5,7.1 will scan the four addresses 192.168.3.1, 192.168.4.1, 192.168.5.1, and 192.168.7.1. Either side of a range may be omitted; the default values are 0 on the left and 255 on the right. Using - by itself is the same as 0-255, but remember to use 0- in the first octet so the target specification doesn't look like a command-line option. Ranges need not be limited to the final octets: the specifier 0-255.0-255.13.37 will perform an Internet-wide scan for all IP addresses ending in 13.37. This sort of broad sampling can be useful for Internet surveys and research.
IPv6 addresses can be specified by their fully qualified IPv6 address or hostname or with CIDR notation for subnets. Octet ranges aren't yet supported for IPv6.
IPv6 addresses with non-global scope need to have a zone ID suffix. On Unix systems, this is a percent sign followed by an interface name; a complete address might be fe80::a8bb:ccff:fedd:eeff%eth0. On Windows, use an interface index number in place of an interface name: fe80::a8bb:ccff:fedd:eeff%1. You can see a list of interface indexes by running the command netsh.exe interface ipv6 show interface.
Nmap accepts multiple host specifications on the command line, and they don't need to be the same type. The command nmap scanme.nmap.org 192.168.0.0/8 10.0.0,1,3-7.- does what you would expect.
While targets are usually specified on the command lines, the following options are also available to control target selection:
-iL inputfilename (Input from list) Reads target specifications from inputfilename. Passing a huge list of hosts is often awkward on the command line, yet it is a common desire. For example, your DHCP server might export a list of 10,000 current leases that you wish to scan. Or maybe you want to scan all IP addresses except for those to locate hosts using unauthorized static IP addresses. Simply generate the list of hosts to scan and pass that filename to Nmap as an argument to the -iL option. Entries can be in any of the formats accepted by Nmap on the command line (IP address, hostname, CIDR, IPv6, or octet ranges). Each entry must be separated by one or more spaces, tabs, or newlines. You can specify a hyphen (-) as the filename if you want Nmap to read hosts from standard input rather than an actual file.
The input file may contain comments that start with # and extend to the end of the line.
-iR num hosts (Choose random targets) For Internet-wide surveys and other research, you may want to choose targets at random. The num hosts argument tells Nmap how many IPs to generate. Undesirable IPs such as those in certain private, multicast, or unallocated address ranges are automatically skipped. The argument 0 can be specified for a never-ending scan. Keep in mind that some network administrators bristle at unauthorized scans of their networks and may complain. Use this option at your own risk! If you find yourself really bored one rainy afternoon, try the command nmap -Pn -sS -p 80 -iR 0 --open to locate random web servers for browsing.
--exclude host1[,host2[,...]] (Exclude hosts/networks) Specifies a comma-separated list of targets to be excluded from the scan even if they are part of the overall network range you specify. The list you pass in uses normal Nmap syntax, so it can include hostnames, CIDR netblocks, octet ranges, etc. This can be useful when the network you wish to scan includes untouchable mission-critical servers, systems that are known to react adversely to port scans, or subnets administered by other people.
--excludefile exclude_file (Exclude list from file) This offers the same functionality as the --exclude option, except that the excluded targets are provided in a newline-, space-, or tab-delimited exclude_file rather than on the command line.
The exclude file may contain comments that start with # and extend to the end of the line.
One of the very first steps in any network reconnaissance mission is to reduce a (sometimes huge) set of IP ranges into a list of active or interesting hosts. Scanning every port of every single IP address is slow and usually unnecessary. Of course what makes a host interesting depends greatly on the scan purposes. Network administrators may only be interested in hosts running a certain service, while security auditors may care about every single device with an IP address. An administrator may be comfortable using just an ICMP ping to locate hosts on his internal network, while an external penetration tester may use a diverse set of dozens of probes in an attempt to evade firewall restrictions.
Because host discovery needs are so diverse, Nmap offers a wide variety of options for customizing the techniques used. Host discovery is sometimes called ping scan, but it goes well beyond the simple ICMP echo request packets associated with the ubiquitous ping tool. Users can skip the discovery step entirely with a list scan (-sL) or by disabling host discovery (-Pn), or engage the network with arbitrary combinations of multi-port TCP SYN/ACK, UDP, SCTP INIT and ICMP probes. The goal of these probes is to solicit responses which demonstrate that an IP address is actually active (is being used by a host or network device). On many networks, only a small percentage of IP addresses are active at any given time. This is particularly common with private address space such as 10.0.0.0/8. That network has 16 million IPs, but I have seen it used by companies with less than a thousand machines. Host discovery can find those machines in a sparsely allocated sea of IP addresses.
If no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request. (For IPv6, the ICMP timestamp request is omitted because it is not part of ICMPv6.) These defaults are equivalent to the -PE -PS443 -PA80 -PP options. The exceptions to this are the ARP (for IPv4) and Neighbor Discovery (for IPv6) scans which are used for any targets on a local ethernet network. For unprivileged Unix shell users, the default probes are a SYN packet to ports 80 and 443 using the connect system call.  This host discovery is often sufficient when scanning local networks, but a more comprehensive set of discovery probes is recommended for security auditing.
The -P* options (which select ping types) can be combined. You can increase your odds of penetrating strict firewalls by sending many probe types using different TCP ports/flags and ICMP codes. Also note that ARP/Neighbor Discovery is done by default against targets on a local Ethernet network even if you specify other -P* options, because it is almost always faster and more effective.
By default, Nmap does host discovery and then performs a port scan against each host it determines is online. This is true even if you specify non-default host discovery types such as UDP probes (-PU). Read about the -sn option to learn how to perform only host discovery, or use -Pn to skip host discovery and port scan all target addresses. The following options control host discovery:
-sL (List Scan) The list scan is a degenerate form of host discovery that simply lists each host of the network(s) specified, without sending any packets to the target hosts. By default, Nmap still does reverse-DNS resolution on the hosts to learn their names. It is often surprising how much useful information simple hostnames give out. For example, fw.chi is the name of one company's Chicago firewall.
Nmap also reports the total number of IP addresses at the end. The list scan is a good sanity check to ensure that you have proper IP addresses for your targets. If the hosts sport domain names you do not recognize, it is worth investigating further to prevent scanning the wrong company's network.
Since the idea is to simply print a list of target hosts, options for higher level functionality such as port scanning, OS detection, or host discovery cannot be combined with this. If you wish to disable host discovery while still performing such higher level functionality, read up on the -Pn (skip host discovery) option.
-sn (No port scan) This option tells Nmap not to do a port scan after host discovery, and only print out the available hosts that responded to the host discovery probes. This is often known as a “ping scan”, but you can also request that traceroute and NSE host scripts be run. This is by default one step more intrusive than the list scan, and can often be used for the same purposes. It allows light reconnaissance of a target network without attracting much attention. Knowing how many hosts are up is more valuable to attackers than the list provided by list scan of every single IP and host name.
Systems administrators often find this option valuable as well. It can easily be used to count available machines on a network or monitor server availability. This is often called a ping sweep, and is more reliable than pinging the broadcast address because many hosts do not reply to broadcast queries.
The default host discovery done with -sn consists of an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default. When executed by an unprivileged user, only SYN packets are sent (using a connect call) to ports 80 and 443 on the target. When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified. The -sn option can be combined with any of the discovery probe types (the -P* options) for greater flexibility. If any of those probe type and port number options are used, the default probes are overridden. When strict firewalls are in place between the source host running Nmap and the target network, using those advanced techniques is recommended. Otherwise hosts could be missed when the firewall drops probes or their responses.
In previous releases of Nmap, -sn was known as -sP.
-Pn (No ping) This option skips the host discovery stage altogether. Normally, Nmap uses this stage to determine active machines for heavier scanning and to gauge the speed of the network. By default, Nmap only performs heavy probing such as port scans, version detection, or OS detection against hosts that are found to be up. Disabling host discovery with -Pn causes Nmap to attempt the requested scanning functions against every target IP address specified. So if a /16 sized network is specified on the command line, all 65,536 IP addresses are scanned. Proper host discovery is skipped as with the list scan, but instead of stopping and printing the target list, Nmap continues to perform requested functions as if each target IP is active. Default timing parameters are used, which may result in slower scans. To skip host discovery and port scan, while still allowing NSE to run, use the two options -Pn -sn together.
For machines on a local ethernet network, ARP scanning will still be performed (unless --disable-arp-ping or --send-ip is specified) because Nmap needs MAC addresses to further scan target hosts. In previous versions of Nmap, -Pn was -P0 and -PN.
-PS port list (TCP SYN Ping) This option sends an empty TCP packet with the SYN flag set. The default destination port is 80 (configurable at compile time by changing DEFAULT_TCP_PROBE_PORT_SPEC in nmap.h).  Alternate ports can be specified as a parameter. The syntax is the same as for the -p except that port type specifiers like T: are not allowed. Examples are -PS22 and -PS22-25,80,113,1050,35000. Note that there can be no space between -PS and the port list. If multiple probes are specified they will be sent in parallel.
The SYN flag suggests to the remote system that you are attempting to establish a connection. Normally the destination port will be closed, and a RST (reset) packet sent back. If the port happens to be open, the target will take the second step of a TCP three-way-handshake by responding with a SYN/ACK TCP packet. The machine running Nmap then tears down the nascent connection by responding with a RST rather than sending an ACK packet which would complete the three-way-handshake and establish a full connection. The RST packet is sent by the kernel of the machine running Nmap in response to the unexpected SYN/ACK, not by Nmap itself.
Nmap does not care whether the port is open or closed. Either the RST or SYN/ACK response discussed previously tell Nmap that the host is available and responsive.
On Unix boxes, only the privileged user root is generally able to send and receive raw TCP packets.  For unprivileged users, a workaround is automatically employed whereby the connect system call is initiated against each target port. This has the effect of sending a SYN packet to the target host, in an attempt to establish a connection. If connect returns with a quick success or an ECONNREFUSED failure, the underlying TCP stack must have received a SYN/ACK or RST and the host is marked available. If the connection attempt is left hanging until a timeout is reached, the host is marked as down.
-PA port list (TCP ACK Ping) The TCP ACK ping is quite similar to the just-discussed SYN ping. The difference, as you could likely guess, is that the TCP ACK flag is set instead of the SYN flag. Such an ACK packet purports to be acknowledging data over an established TCP connection, but no such connection exists. So remote hosts should always respond with a RST packet, disclosing their existence in the process.
The -PA option uses the same default port as the SYN probe (80) and can also take a list of destination ports in the same format. If an unprivileged user tries this, the connect workaround discussed previously is used. This workaround is imperfect because connect is actually sending a SYN packet rather than an ACK.
The reason for offering both SYN and ACK ping probes is to maximize the chances of bypassing firewalls. Many administrators configure routers and other simple firewalls to block incoming SYN packets except for those destined for public services like the company web site or mail server. This prevents other incoming connections to the organization, while allowing users to make unobstructed outgoing connections to the Internet. This non-stateful approach takes up few resources on the firewall/router and is widely supported by hardware and software filters. The Linux Netfilter/iptables firewall software offers the --syn convenience option to implement this stateless approach. When stateless firewall rules such as this are in place, SYN ping probes (-PS) are likely to be blocked when sent to closed target ports. In such cases, the ACK probe shines as it cuts right through these rules.
Another common type of firewall uses stateful rules that drop unexpected packets. This feature was initially found mostly on high-end firewalls, though it has become much more common over the years. The Linux Netfilter/iptables system supports this through the --state option, which categorizes packets based on connection state. A SYN probe is more likely to work against such a system, as unexpected ACK packets are generally recognized as bogus and dropped. A solution to this quandary is to send both SYN and ACK probes by specifying -PS and -PA.
-PU port list (UDP Ping) Another host discovery option is the UDP ping, which sends a UDP packet to the given ports. For most ports, the packet will be empty, though some use a protocol-specific payload that is more likely to elicit a response.  The payload database is described at https://nmap.org/book/nmap-payloads.html.
Packet content can also be affected with the --data, --data-string, and --data-length options.
The port list takes the same format as with the previously discussed -PS and -PA options. If no ports are specified, the default is 40125. This default can be configured at compile-time by changing DEFAULT_UDP_PROBE_PORT_SPEC in nmap.h.  A highly uncommon port is used by default because sending to open ports is often undesirable for this particular scan type.
Upon hitting a closed port on the target machine, the UDP probe should elicit an ICMP port unreachable packet in return. This signifies to Nmap that the machine is up and available. Many other types of ICMP errors, such as host/network unreachables or TTL exceeded are indicative of a down or unreachable host. A lack of response is also interpreted this way. If an open port is reached, most services simply ignore the empty packet and fail to return any response. This is why the default probe port is 40125, which is highly unlikely to be in use. A few services, such as the Character Generator (chargen) protocol, will respond to an empty UDP packet, and thus disclose to Nmap that the machine is available.
The primary advantage of this scan type is that it bypasses firewalls and filters that only screen TCP. For example, I once owned a Linksys BEFW11S4 wireless broadband router. The external interface of this device filtered all TCP ports by default, but UDP probes would still elicit port unreachable messages and thus give away the device.
-PY port list (SCTP INIT Ping) This option sends an SCTP packet containing a minimal INIT chunk. The default destination port is 80 (configurable at compile time by changing DEFAULT_SCTP_PROBE_PORT_SPEC in nmap.h). Alternate ports can be specified as a parameter. The syntax is the same as for the -p except that port type specifiers like S: are not allowed. Examples are -PY22 and -PY22,80,179,5060. Note that there can be no space between -PY and the port list. If multiple probes are specified they will be sent in parallel.
The INIT chunk suggests to the remote system that you are attempting to establish an association. Normally the destination port will be closed, and an ABORT chunk will be sent back. If the port happens to be open, the target will take the second step of an SCTP four-way-handshake by responding with an INIT-ACK chunk. If the machine running Nmap has a functional SCTP stack, then it tears down the nascent association by responding with an ABORT chunk rather than sending a COOKIE-ECHO chunk which would be the next step in the four-way-handshake. The ABORT packet is sent by the kernel of the machine running Nmap in response to the unexpected INIT-ACK, not by Nmap itself.
Nmap does not care whether the port is open or closed. Either the ABORT or INIT-ACK response discussed previously tell Nmap that the host is available and responsive.
On Unix boxes, only the privileged user root is generally able to send and receive raw SCTP packets.  Using SCTP INIT Pings is currently not possible for unprivileged users.
-PE; -PP; -PM (ICMP Ping Types) In addition to the unusual TCP, UDP and SCTP host discovery types discussed previously, Nmap can send the standard packets sent by the ubiquitous ping program. Nmap sends an ICMP type 8 (echo request) packet to the target IP addresses, expecting a type 0 (echo reply) in return from available hosts.  Unfortunately for network explorers, many hosts and firewalls now block these packets, rather than responding as required by RFC 1122[2].  For this reason, ICMP-only scans are rarely reliable enough against unknown targets over the Internet. But for system administrators monitoring an internal network, they can be a practical and efficient approach. Use the -PE option to enable this echo request behavior.
While echo request is the standard ICMP ping query, Nmap does not stop there. The ICMP standards (RFC 792[3] and RFC 950[4] ) also specify timestamp request, information request, and address mask request packets as codes 13, 15, and 17, respectively. While the ostensible purpose for these queries is to learn information such as address masks and current times, they can easily be used for host discovery. A system that replies is up and available. Nmap does not currently implement information request packets, as they are not widely supported. RFC 1122 insists that “a host SHOULD NOT implement these messages”. Timestamp and address mask queries can be sent with the -PP and -PM options, respectively. A timestamp reply (ICMP code 14) or address mask reply (code 18) discloses that the host is available. These two queries can be valuable when administrators specifically block echo request packets while forgetting that other ICMP queries can be used for the same purpose.
-PO protocol list (IP Protocol Ping) One of the newer host discovery options is the IP protocol ping, which sends IP packets with the specified protocol number set in their IP header. The protocol list takes the same format as do port lists in the previously discussed TCP, UDP and SCTP host discovery options. If no protocols are specified, the default is to send multiple IP packets for ICMP (protocol 1), IGMP (protocol 2), and IP-in-IP (protocol 4). The default protocols can be configured at compile-time by changing DEFAULT_PROTO_PROBE_PORT_SPEC in nmap.h. Note that for the ICMP, IGMP, TCP (protocol 6), UDP (protocol 17) and SCTP (protocol 132), the packets are sent with the proper protocol headers while other protocols are sent with no additional data beyond the IP header (unless any of --data, --data-string, or --data-length options are specified).
This host discovery method looks for either responses using the same protocol as a probe, or ICMP protocol unreachable messages which signify that the given protocol isn't supported on the destination host. Either type of response signifies that the target host is alive.
--disable-arp-ping (No ARP or ND Ping) Nmap normally does ARP or IPv6 Neighbor Discovery (ND) discovery of locally connected ethernet hosts, even if other host discovery options such as -Pn or -PE are used. To disable this implicit behavior, use the --disable-arp-ping option.
The default behavior is normally faster, but this option is useful on networks using proxy ARP, in which a router speculatively replies to all ARP requests, making every target appear to be up according to ARP scan.
--discovery-ignore-rst In some cases, firewalls may spoof TCP reset (RST) replies in response to probes to unoccupied or disallowed addresses. Since Nmap ordinarily considers RST replies to be proof that the target is up, this can lead to wasted time scanning targets that aren't there. Using the --discovery-ignore-rst will prevent Nmap from considering these replies during host discovery. You may need to select extra host discovery options to ensure you don't miss targets in this case.
--traceroute (Trace path to host) Traceroutes are performed post-scan using information from the scan results to determine the port and protocol most likely to reach the target. It works with all scan types except connect scans (-sT) and idle scans (-sI). All traces use Nmap's dynamic timing model and are performed in parallel.
Traceroute works by sending packets with a low TTL (time-to-live) in an attempt to elicit ICMP Time Exceeded messages from intermediate hops between the scanner and the target host. Standard traceroute implementations start with a TTL of 1 and increment the TTL until the destination host is reached. Nmap's traceroute starts with a high TTL and then decrements the TTL until it reaches zero. Doing it backwards lets Nmap employ clever caching algorithms to speed up traces over multiple hosts. On average Nmap sends 5–10 fewer packets per host, depending on network conditions. If a single subnet is being scanned (i.e. 192.168.0.0/24) Nmap may only have to send two packets to most hosts.
-n (No DNS resolution)