neulab/tldr huggingface dataset:
If one or more <file> parameters are given, the merge tool program will be run to resolve differences on each file (skipping those without conflicts). Specifying a directory will include all unresolved files in that path. If no <file> names are specified, git mergetool will run the merge tool program on every file with merge conflicts.
-t <tool>, --tool=<tool> Use the merge resolution program specified by <tool>. Valid values include emerge, gvimdiff, kdiff3, meld, vimdiff, and tortoisemerge. Run git mergetool --tool-help for the list of valid <tool> settings.
If a merge resolution program is not specified, git mergetool will use the configuration variable merge.tool. If the configuration variable merge.tool is not set, git mergetool will pick a suitable default.
You can explicitly provide a full path to the tool by setting the configuration variable mergetool.<tool>.path. For example, you can configure the absolute path to kdiff3 by setting mergetool.kdiff3.path. Otherwise, git mergetool assumes the tool is available in PATH.
Instead of running one of the known merge tool programs, git mergetool can be customized to run an alternative program by specifying the command line to invoke in a configuration variable mergetool.<tool>.cmd.
When git mergetool is invoked with this tool (either through the -t or --tool option or the merge.tool configuration variable) the configured command line will be invoked with $BASE set to the name of a temporary file containing the common base for the merge, if available; $LOCAL set to the name of a temporary file containing the contents of the file on the current branch; $REMOTE set to the name of a temporary file containing the contents of the file to be merged, and $MERGED set to the name of the file to which the merge tool should write the result of the merge resolution.
If the custom merge tool correctly indicates the success of a merge resolution with its exit code, then the configuration variable mergetool.<tool>.trustExitCode can be set to true. Otherwise, git mergetool will prompt the user to indicate the success of the resolution after the custom tool has exited.
--tool-help Print a list of merge tools that may be used with --tool.
-y, --no-prompt Don’t prompt before each invocation of the merge resolution program. This is the default if the merge resolution program is explicitly specified with the --tool option or with the merge.tool configuration variable.
--prompt Prompt before each invocation of the merge resolution program to give the user a chance to skip the path.
-g, --gui When git-mergetool is invoked with the -g or --gui option the default merge tool will be read from the configured merge.guitool variable instead of merge.tool. If merge.guitool is not set, we will fallback to the tool configured under merge.tool.
--no-gui This overrides a previous -g or --gui setting and reads the default merge tool will be read from the configured merge.tool variable.
-O<orderfile> Process files in the order specified in the <orderfile>, which has one shell glob pattern per line. This overrides the diff.orderFile configuration variable (see git-config(1)). To cancel diff.orderFile, use -O/dev/null.
mergetool.<tool>.path Override the path for the given tool. This is useful in case your tool is not in the PATH.
mergetool.<tool>.cmd Specify the command to invoke the specified merge tool. The specified command is evaluated in shell with the following variables available: BASE is the name of a temporary file containing the common base of the files to be merged, if available; LOCAL is the name of a temporary file containing the contents of the file on the current branch; REMOTE is the name of a temporary file containing the contents of the file from the branch being merged; MERGED contains the name of the file to which the merge tool should write the results of a successful merge.
mergetool.<tool>.hideResolved Allows the user to override the global mergetool.hideResolved value for a specific tool. See mergetool.hideResolved for the full description.
mergetool.<tool>.trustExitCode For a custom merge command, specify whether the exit code of the merge command can be used to determine whether the merge was successful. If this is not set to true then the merge target file timestamp is checked and the merge assumed to have been successful if the file has been updated, otherwise the user is prompted to indicate the success of the merge.
mergetool.meld.hasOutput Older versions of meld do not support the --output option. Git will attempt to detect whether meld supports --output by inspecting the output of meld --help. Configuring mergetool.meld.hasOutput will make Git skip these checks and use the configured value instead. Setting mergetool.meld.hasOutput to true tells Git to unconditionally use the --output option, and false avoids using --output.
mergetool.meld.useAutoMerge When the --auto-merge is given, meld will merge all non-conflicting parts automatically, highlight the conflicting parts and wait for user decision. Setting mergetool.meld.useAutoMerge to true tells Git to unconditionally use the --auto-merge option with meld. Setting this value to auto makes git detect whether --auto-merge is supported and will only use --auto-merge when available. A value of false avoids using --auto-merge altogether, and is the default value.
mergetool.hideResolved During a merge Git will automatically resolve as many conflicts as possible and write the MERGED file containing conflict markers around any conflicts that it cannot resolve; LOCAL and REMOTE normally represent the versions of the file from before Git’s conflict resolution. This flag causes LOCAL and REMOTE to be overwriten so that only the unresolved conflicts are presented to the merge tool. Can be configured per-tool via the mergetool.<tool>.hideResolved configuration variable. Defaults to false.
mergetool.keepBackup After performing a merge, the original file with conflict markers can be saved as a file with a .orig extension. If this variable is set to false then this file is not preserved. Defaults to true (i.e. keep the backup files).
mergetool.keepTemporaries When invoking a custom merge tool, Git uses a set of temporary files to pass to the tool. If the tool returns an error and this variable is set to true, then these temporary files will be preserved, otherwise they will be removed after the tool has exited. Defaults to false.
mergetool.writeToTemp Git writes temporary BASE, LOCAL, and REMOTE versions of conflicting files in the worktree by default. Git will attempt to use a temporary directory for these files when set true. Defaults to false.
mergetool.prompt Prompt before each invocation of the merge resolution program.
git mergetool creates *.orig backup files while resolving merges. These are safe to remove once a file has been merged and its git mergetool session has completed.
Setting the mergetool.keepBackup configuration variable to false causes git mergetool to automatically remove the backup as files are successfully merged.
TCPTRACEROUTE(8)             System Manager's Manual            TCPTRACEROUTE(8)
tcptraceroute - A traceroute implementation using TCP packets
tcptraceroute [-nFE] [ -i interface ] [ -f first ttl ] [ -l length ] [ -q number of queries ] [ -t tos ] [ -m max ttl ] [ -p source port ] [ -s source address ] [ -w wait time ] host [ destination port ] [ length ]
tcptraceroute is a traceroute implementation using TCP packets.
The more traditional traceroute(8) sends out either UDP or ICMP ECHO packets with a TTL of one, and increments the TTL until the destination has been reached.  By printing the gateways that generate ICMP time exceeded messages along the way, it is able to determine the path packets are taking to reach the destination.
The problem is that with the widespread use of firewalls on the modern Internet, many of the packets that traceroute(8) sends out end up being filtered, making it impossible to completely trace the path to the destination.  However, in many cases, these firewalls will permit inbound TCP packets to specific ports that hosts sitting behind the firewall are listening for connections on.  By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters.
It is worth noting that tcptraceroute never completely establishes a TCP connection with the destination host.  If the host is not listening for incoming connections, it will respond with an RST indicating that the port is closed.  If the host instead responds with a SYN|ACK, the port is known to be open, and an RST is sent by the kernel tcptraceroute is running on to tear down the connection without completing three-way handshake.  This is the same half-open scanning technique that nmap(1) uses when passed the -sS flag.
-n     Display numeric output, rather than doing a reverse DNS lookup for each hop.  Reverse lookups are never attempted on RFC1918 address space, regardless of the -n flag.
-f     Set the initial TTL used in the first outgoing packet.  The default is 1.
-m     Set the maximum TTL used in outgoing packets.  The default is 30.
-p     Use the specified local TCP port in outgoing packets.  The default is to obtain a free port from the kernel using bind(2).  Unlike with traditional traceroute(8), this number will not increase with each hop.
-s     Set the source address for outgoing packets.  See also the -i flag.
-i     Use the specified interface for outgoing packets.
-q     Set the number of probes to be sent to each hop.  The default is 3.
-t     Set the IP type of service to be used in outgoing packets.  The default is to not set any type of service option.
-F     Set the "don't fragment" bit in outgoing packets.
-E     Send ECN SYN packets, as described in RFC2481.
-w     Set the timeout, in seconds, to wait for a response for each probe.  The default is 3.
-l     Set the total packet length to be used in outgoing packets.  If the length is greater than the minimum size required to assemble the necessary probe packet headers, this value is automatically increased.
-d     Enable debugging, which may or may not be useful.
Please see the examples.txt file included in the tcptraceroute distribution for a few real world examples.
To trace the path to a web server listening for connections on port 80:
tcptraceroute webserver
To trace the path to a mail server listening for connections on port 25:
tcptraceroute mailserver 25
No error checking is performed on the source address specified by the -s flag, and it is therefore possible for tcptraceroute to send out TCP SYN packets for which it has no chance of seeing a response to.
Complete portability to other Unix systems has not been tested; specifically, tcptraceroute will not function on systems which modify the IP ID field of packets written to a raw socket.  As of the time of this writing, tcptraceroute is known to compile and function properly on Linux, OpenBSD, and FreeBSD systems.  If you run into complications on another platform, please let me know.
Michael C. Toren <mct@toren.net>
For updates, please see: http://michael.toren.net/code/tcptraceroute/
traceroute(8), ping(8), nmap(1)
SUP(1)                       General Commands Manual                      SUP(1)
sup - software upgrade protocol
sup [ flags ] [ supfile ] [ collection ...]
Sup is a program used for upgrading collections of files from other machines to your machine.  You execute sup, the client program, which talks over the network using IP/TCP to a file server process.  The file server process cooperates with sup to determine which files of the collection need to be upgraded on your machine.
Sup collections can have multiple releases. One use for such releases is to provide different versions of the same files. At CMU, for example, system binaries have alpha, beta and default release corresponding to different staging levels of the software. We also use release names default and minimal to provide complete releases or subset releases.  In both of these cases, it only makes sense to sup one release of the collections. Releases have also been used in private or external sups to provide subsets of collections where it makes sense to pick up several of the releases. For example the Mach 3.0 kernel sources has a default release of machine independent sources and separate releases of machine dependent sources for each supported platform.
In performing an upgrade, the file server constructs a list of files included in the specified release of the collection.  The list is sent to your machine, which determines which files are needed.  Those files are then sent from the file server.  It will be most useful to run sup as a daemon each night so you will continually have the latest version of the files in the needed collections.
The only required argument to sup is the name of a supfile.  It must either be given explicitly on the command line, or the -s flag must be specified.  If the -s flag is given, the system supfile will be used and a supfile command argument should not be specified.  The list of collections is optional and if specified will be the only collections upgraded.  The following flags affect all collections specified:
-s     As described above.
-t     When this flag is given, sup will print the time that each collection was last upgraded, rather than performing actual upgrades.
-u     When this flag is given, sup will not try to restore the user access and modified times of files in the collections from the server.
-S     Operate silently printing messages only on errors.
-N     Sup will trace network messages sent and received that implement the sup network protocol.
-P     Sup will use a set of non-privileged network ports reserved for debugging purposes.
The remaining flags affect all collections unless an explicit list of collections are given with the flags.  Multiple flags may be specified together that affect the same collections.  For the sake of convenience, any flags that always affect all collections can be specified with flags that affect only some collections.  For example, sup -sde=coll1,coll2 would perform a system upgrade, and the first two collections would allow both file deletions and command executions.  Note that this is not the same command as sup -sde=coll1 coll2, which would perform a system upgrade of just the coll2 collection and would ignore the flags given for the coll1 collection.
-a     All files in the collection will be copied from the repository, regardless of their status on the current machine.  Because of this, it is a very expensive operation and should only be done for small collections if data corruption is suspected and been confirmed.  In most cases, the -o flag should be sufficient.
-b     If the -b flag if given, or the backup supfile option is specified, the contents of regular files on the local system will be saved before they are overwritten with new data.  The file collection maintainer can designate specific files to be worthy of backing up whenever they are upgraded.  However, such backup will only take place if you specify this flag or the backup option to allow backups for a file collection on your machine.  The backup mechanism will create a copy of the current version of a file immediately before a new copy is received from the file server; the copy is given the same name as the original file but is put into a directory called BACKUP within the directory containing the original file.  For example, /usr/sas/src/foo.c would have a backup copy called /usr/sas/src/BACKUP/foo.c.  There is no provision for automatically maintaining multiple old versions of files; you would have to do this yourself.
-B     The -B flag overrides and disables the -b flag and the backup supfile option.
-d     Files that are no longer in the collection on the repository will be deleted if present on the local machine and were put there by a previous sup.  This may also be specified in a supfile with the delete option.
-D     The -D flag overrides and disables the -d flag and the delete supfile option.
-e     Sup will execute commands sent from the repository that should be run when a file is upgraded.  If the -e flag is omitted, Sup will print a message that specifies the command to execute.  This may also be specified in a supfile with the execute option.
-E     The -E flag overrides and disables the -e flag and the execute supfile option.
-f     A list-only upgrade will be performed.  Messages will be printed that indicate what would happen if an actual upgrade were done.
-k     Sup will check the modification times of files on the local disk before updating them.  Only files which are newer on the repository than on the local disk will be updated; files that are newer on the local disk will be kept as they are.  This may also be specified in a supfile with the keep option.
-K     The -K flag overrides and disables the -k flag and the keep supfile option.
-l     Normally, sup will not upgrade a collection if the repository is on the same machine.  This allows users to run upgrades on all machines without having to make special checks for the repository machine.  If the -l flag is specified, collections will be upgraded even if the repository is local.
-m     Normally, sup used standard output for messages.  If the -m flag if given, sup will send mail to the user running sup, or a user specified with the notify supfile option, that contains messages printed by sup.
-M <user> like -m but send mail to the specified user.
-o     Sup will normally only upgrade files that have changed on the repository since the last time an upgrade was performed. That is, if the file in the repository is newer than the date stored in the when file on the client.  The -o flag, or the old supfile option, will cause sup to check all files in the collection for changes instead of just the new ones.
-O     The -O flag overrides and disables the -o flag and the old supfile option.
-z     Normally sup transfers files directly without any other processing, but with the -z flag, or the compress supfile option, sup will compress the file before sending it across the network and uncompress it and restore all the correct file attributes at the receiving end.
-Z     The -Z flag overrides and disables the -z flag and the compress supfile option.
-v     Normally, sup will only print messages if there are problems. This flag causes sup to also print messages during normal progress showing what sup is doing.
Each file collection to be upgraded must have a base directory which contains a subdirectory called sup that will be used by the sup program; it will be created automatically if you do not create it.  Sup will put subdirectories and files into this directory as needed.
Sup will look for a subdirectory with the same name as the collection within the sup subdirectory of the base directory.  If it exists it may contain any of the following files:
when.<rel-suffix> This file is automatically updated by sup when a collection is successfully upgraded and contains the time that the file server, or possibly supscan, created the list of files in the upgrade list.  Sup will send this time to the file server for generating the list of files that have been changed on the repository machine.
refuse This file contains a list of files and directories, one per line, that the client is not interested in that should not be upgraded.
lock   This file is used by sup to lock a collection while it is being upgraded.  Sup will get exclusive access to the lock file using flock(2), preventing more than one sup from upgrading the same collection at the same time.
last.<rel-suffix> This file contains a list of files and directories, one per line, that have been upgraded by sup in the past.  This information is used when the delete option, or the -d flag is used to locate files previously upgraded that are no longer in the collection that should be deleted.
Each file collection must also be described in one or more supfiles. When sup is executed, it reads the specified supfile to determine what file collections  and releases to upgrade.  Each collection-release set is described by a single line of text in the supfile; this line must contain the name of the collection, and possibly one or more options separated by spaces.  The options are:
release=releasename If a collection contains multiple releases, you need to specify which release you want. You can only specify one release per line, so if you want multiple releases from the same collections, you will need to specify the collection more than once. In this case, you should use the use-rel-suffix option in the supfile to keep the last and when files for the two releases separate.
base=directory The usual default name of the base directory for a collection is described below (see FILES); if you want to specify another directory name, use this option specifying the desired directory.
prefix=directory Each collection may also have an associated prefix directory which is used instead of the base directory to specify in what directory files within the collection will be placed.
host=hostname hostbase=directory System collections are supported by the system maintainers, and sup will automatically find out the name of the host machine and base directory on that machine.  However, you can also upgrade private collections; you simply specify with these options the hostname of the machine containing the files and the directory used as a base directory for the file server on that machine. Details of setting up a file collection are given in the section below.
login=accountid password=password crypt=key Files on the file server may be protected, and network transmissions may be encrypted.  This prevents unauthorized access to files via sup.  When files are not accessible to the default account (e.g.  the anon anonymous account), you can specify an alternative accountid and password for the file server to use on the repository host.  Network transmission of the password will be always be encrypted.  You can also have the actual file data encrypted by specifying a key; the file collection on the repository must specify the same key or else sup will not be able to upgrade files from that collection.  In this case, the default account used by the file server on the repository machine will be the owner of the encryption key file (see FILES) rather than the anon anonymous account.
notify=address If you use the -m option to receive log messages by mail, you can have the mail sent to different user, possibly on another host, than the user running the sup program.  Messages will be sent to the specified address, which can be any legal netmail address.  In particular, a project maintainer can be designated to receive mail for that project's file collection from all users running sup to upgrade that collection.
backup As described above under the -b flag.
delete As described above under the -d flag.
execute As described above under the -e flag.
keep   As described above under the -k flag.
old    As described above under the -o flag.
use-rel-suffix Causes the release name to be used as a suffix to the last and when files. This is necessary whenever you are supping more than one release in the same collection.
A set of files residing on a repository must be prepared before sup client processes can upgrade those files.  The collection must be given a name and a base directory.  If it is a private collection, client users must be told the name of the collection, repository host, and base directory; these will be specified in the supfile via the host and hostbase options.  For a system-maintained file collection, entries must be placed into the host list file and directory list file as described in supservers(8).
Within the base directory, a subdirectory must be created called sup . Within this directory there must be a subdirectory for each collection using that base directory, whose name is the name of the collection; within each of these directories will be a list file and possibly a prefix file, a host file, an encryption key file, a log file and a scan file.  The filenames are listed under FILES below.
prefix Normally, all files in the collection are relative to the base directory.  This file contains a single line which is the name of a directory to be used in place of the base directory for file references.
host   Normally, all remote host machines are allowed access to a file collection.  If you wish to restrict access to specific remote hosts for this collection, put each allowed hostname on a separate line of text in this file.  If a host has more than one name, only one of its names needs to be listed.  The name LOCAL can be used to grant access to all hosts on the local network. The host name may be a  numeric network address or a network name. If a crypt appears on the same line as the host name, that crypt will be used for that host. Otherwise, the crypt appearing in the crypt file, if any will be used.
crypt  If you wish to use the sup data encryption mechanism, create an encryption file containing, on a single line of text, the desired encryption key.  Client processes must then specify the same key with the crypt option in the supfile or they will be denied access to the files.  In addition, actual network transmission of file contents and filenames will be encrypted.
list   This file describes the actual list of files to be included in this file collection, in a format described below.
releases This file describes any releases that the collection may have. Each line starts with the release name and then may specify any of the following files: prefix=<dirname> to use a different parent directory for the files in this release.  list=<listname> to specify the list of files in the release.  scan=<scanfile> must be used in multi-release collections that are scanned to keep the scan files for the different releases separate.  host=<hostfile> to allow different host restrictions for this release. next=<release> used to chain releases together. This has the effect of making one release be a combination of several other releases. If the same file appears in more than one chained release, the first one found will be used.  If these files are not specified for a release the default names: prefix,list,scan and host will be used.
scan   This file, created by supscan, is the list of filenames that correspond to the instructions in the list file.  The scan file is only used for frequently updated file collections; it makes the file server run much faster.  See supservers(8) for more information.
lock   As previously mentioned, this file is used to indicate that the collection should be locked while upgrades are in progress.  All file servers will try to get shared access to the lock file with flock(2).
logfile If a log file exists in the collection directory, the file server will append the last time an upgrade was successfully completed, the time the last upgrade started and finished, and the name of the host requesting the upgrade.
It should be noted that sup allows several different named collections to use the same base directory.  Separate encryption, remote host access, and file lists are used for each collection, since these files reside in subdirectories <basedir>/sup/<coll.name>.
The list file is a text file with one command on each line.  Each command contains a keyword and a number of operands separated by spaces.  All filenames in the list file are evaluated on the repository machine relative to the host's base directory, or prefix directory if one is specified, and on your machine with respect to the base, or prefix, directory for the client.  The filenames below (except exec-command) may all include wild-cards and meta-characters as used by csh(1) including *, ?, [...], and {...}.  The commands are:
upgrade filename ... The specified file(s) (or directories) will be included in the list of files to be upgraded.  If a directory name is given, it recursively includes all subdirectories and files within that directory.
always filename ... The always command is identical to upgrade, except that omit and omitany commands do not affect filenames specified with the always command.
omit filename ... The specified file(s) (or directories) will be excluded from the list of files to be upgraded.  For example, by specifying upgrade /usr/vision and omit /usr/vision/exp, the generated list of files would include all subdirectories and files of /usr/vision except /usr/vision/exp (and its subdirectories and files).
omitany pattern ... The specified patterns are compared against the files in the upgrade list.  If a pattern matches, the file is omitted.  The omitany command currently supports all wild-card patterns except {...}.  Also, the pattern must match the entire filename, so a leading */, or a trailing /*, may be necessary in the pattern.
backup filename ... The specified file(s) are marked for backup; if they are upgraded and the client has specified the backup option in the corresponding line of the supfile, then backup copies will be created as described above.  Directories may not be specified, and no recursive filename construction is performed; you must specify the names of the specific files to be backed up before upgrading.
noaccount filename ... The accounting information of the specified file(s) will not be preserved by sup.  Accounting information consists of the owner, group, mode and modified time of a file.
symlink filename ... The specified file(s) are to be treated as symbolic links and will be transferred as such and not followed.  By default, sup will follow symbolic links.
rsymlink dirname ... All symbolic links in the specified directory and its subdirectories are to be treated as symbolic links. That is the links will be transferred and not the files to which they point.
execute exec-command (filename ...) The exec-command you specified will be executed on the client process whenever any of the files listed in parentheses are upgraded.  A special token, %s, may be specified in the exec- command and will be replaced by the name of the file that was upgraded.  For example, if you say execute ranlib %s (libc.a), then whenever libc.a is upgraded, the client machine will execute ranlib libc.a.  As described above, the client must invoke sup with the -e flag to allow the automatic execution of command files.
include listfile ... The specified listfiles will be read at this point.  This is useful when one collection subsumes other collections; the larger collection can simply specify the listfiles for the smaller collections contained within it.
The order in which the command lines appear in the list file does not matter.  Blank lines may appear freely in the list file.
Files on the client machine for sup:
/etc/supfiles/coll.list supfile used for -s flag
/etc/supfiles/coll.what supfile used for -s flag when -t flag is also specified
/etc/supfiles/coll.host host name list for system collections
<base-directory>/sup/<collection>/last<.release> recorded list of files in collection as of last upgrade
<base-directory>/sup/<collection>/lock file used to lock collection
<base-directory>/sup/<collection>/refuse list of files to refuse in collection
<base-directory>/sup/<collection>/when<.release> recorded time of last upgrade
/usr/sup/<collection> default base directory for file collection
Files needed on each repository machine for the file server:
/etc/supfiles/coll.dir base directory list for system collections
<base-directory>/sup/<collection>/crypt data encryption key for a collection. the owner of this file is the default account used when data encryption is specified
<base-directory>/sup/<collection>/host list of remote hosts allowed to upgrade a collection
<base-directory>/sup/<collection>/list list file for a collection
<base-directory>/sup/<collection>/lock lock file for a collection
<base-directory>/sup/<collection>/logfile log file for a collection
<base-directory>/sup/<collection>/prefix file containing the name of the prefix directory for a collection
<base-directory>/sup/<collection>/scan scan file for a collection
/usr/<collection> default base directory for a file collection
supservers(8) The SUP Software Upgrade Protocol, S. A. Shafer, CMU Computer Science Department, 1985.
<example>
The encryption mechanism should be strengthened, although it's not trivial.
sup can delete files it should not with the delete option.  This is because in the delete pass, it tries to delete all files in the old list that don't exist in the new list.  This is a problem when a directory becomes a symlink to a hierarchy that contains the same names.  Then sup will cross the symlink and start deleting files and directories from the destination.  This is not easily fixed.  Don't use sup with symlink/rsymlink and the delete option at the same time or *be careful*!
UUIDD(8)                      System Administration                     UUIDD(8)
uuidd - UUID generation daemon
uuidd [options]
The uuidd daemon is used by the UUID library to generate universally unique identifiers (UUIDs), especially time-based UUIDs, in a secure and guaranteed-unique fashion, even in the face of large numbers of threads running on different CPUs trying to grab UUIDs.
-d, --debug Run uuidd in debugging mode. This prevents uuidd from running as a daemon.
-F, --no-fork Do not daemonize using a double-fork.
-k, --kill If currently a uuidd daemon is running, kill it.
-n, --uuids number When issuing a test request to a running uuidd, request a bulk response of number UUIDs.
-P, --no-pid Do not create a pid file.
-p, --pid path Specify the pathname where the pid file should be written. By default, the pid file is written to {runstatedir}/uuidd/uuidd.pid.
-q, --quiet Suppress some failure messages.
-r, --random Test uuidd by trying to connect to a running uuidd daemon and request it to return a random-based UUID.
-S, --socket-activation Do not create a socket but instead expect it to be provided by the calling process. This implies --no-fork and --no-pid. This option is intended to be used only with systemd(1). It needs to be enabled with a configure option.
-s, --socket path Make uuidd use this pathname for the unix-domain socket. By default, the pathname used is {runstatedir}/uuidd/request. This option is primarily for debugging purposes, since the pathname is hard-coded in the libuuid library.
-T, --timeout number Make uuidd exit after number seconds of inactivity.
-t, --time Test uuidd by trying to connect to a running uuidd daemon and request it to return a time-based UUID.
-V, --version Output version information and exit.
-h, --help Display help screen and exit.
Start up a daemon, print 42 random keys, and then stop the daemon:
uuidd -p /tmp/uuidd.pid -s /tmp/uuidd.socket uuidd -d -r -n 42 -s /tmp/uuidd.socket uuidd -d -k -s /tmp/uuidd.socket
The uuidd daemon was written by Theodore Tsâ€™o <tytso@mit.edu>.
uuid(3), uuidgen(1)
The uuidd command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
CMAKE(1)                              CMake                             CMAKE(1)
cmake - CMake Command-Line Reference
Generate a Project Buildsystem cmake [<options>] <path-to-source> cmake [<options>] <path-to-existing-build> cmake [<options>] -S <path-to-source> -B <path-to-build>
Build a Project cmake --build <dir> [<options>] [-- <build-tool-options>]
Install a Project cmake --install <dir> [<options>]
Open a Project cmake --open <dir>
Run a Script cmake [{-D <var>=<value>}...] -P <cmake-script-file>
Run a Command-Line Tool cmake -E <command> [<options>]
Run the Find-Package Tool cmake --find-package [<options>]
View Help cmake --help[-<topic>]
The cmake executable is the command-line interface of the cross-platform buildsystem generator CMake.  The above Synopsis lists various actions the tool can perform as described in sections below.
To build a software project with CMake, Generate a Project Buildsystem. Optionally use cmake to Build a Project, Install a Project or just run the corresponding build tool (e.g. make) directly.  cmake can also be used to View Help.
The other actions are meant for use by software developers writing scripts in the CMake language to support their builds.
For graphical user interfaces that may be used in place of cmake, see ccmake and cmake-gui.  For command-line interfaces to the CMake testing and packaging facilities, see ctest and cpack.
For more information on CMake at large, see also the links at the end of this manual.
A buildsystem describes how to build a project's executables and libraries from its source code using a build tool to automate the process.  For example, a buildsystem may be a Makefile for use with a command-line make tool or a project file for an Integrated Development Environment (IDE).  In order to avoid maintaining multiple such buildsystems, a project may specify its buildsystem abstractly using files written in the CMake language.  From these files CMake generates a preferred buildsystem locally for each user through a backend called a generator.
To generate a buildsystem with CMake, the following must be selected:
Source Tree The top-level directory containing source files provided by the project.  The project specifies its buildsystem using files as described in the cmake-language(7) manual, starting with a top-level file named CMakeLists.txt.  These files specify build targets and their dependencies as described in the cmake-buildsystem(7) manual.
Build Tree The top-level directory in which buildsystem files and build output artifacts (e.g. executables and libraries) are to be stored.  CMake will write a CMakeCache.txt file to identify the directory as a build tree and store persistent information such as buildsystem configuration options.
To maintain a pristine source tree, perform an out-of-source build by using a separate dedicated build tree.  An in-source build in which the build tree is placed in the same directory as the source tree is also supported, but discouraged.
Generator This chooses the kind of buildsystem to generate.  See the cmake-generators(7) manual for documentation of all generators. Run cmake --help to see a list of generators available locally. Optionally use the -G option below to specify a generator, or simply accept the default CMake chooses for the current platform.
When using one of the Command-Line Build Tool Generators CMake expects that the environment needed by the compiler toolchain is already configured in the shell.  When using one of the IDE Build Tool Generators, no particular environment is needed.
Run CMake with one of the following command signatures to specify the source and build trees and generate a buildsystem:
cmake [<options>] <path-to-source> Uses the current working directory as the build tree, and <path-to-source> as the source tree.  The specified path may be absolute or relative to the current working directory.  The source tree must contain a CMakeLists.txt file and must not contain a CMakeCache.txt file because the latter identifies an existing build tree.  For example:
$ mkdir build ; cd build $ cmake ../src
cmake [<options>] <path-to-existing-build> Uses <path-to-existing-build> as the build tree, and loads the path to the source tree from its CMakeCache.txt file, which must have already been generated by a previous run of CMake.  The specified path may be absolute or relative to the current working directory.  For example:
$ cd build $ cmake .
cmake [<options>] -S <path-to-source> -B <path-to-build> Uses <path-to-build> as the build tree and <path-to-source> as the source tree.  The specified paths may be absolute or relative to the current working directory.  The source tree must contain a CMakeLists.txt file.  The build tree will be created automatically if it does not already exist.  For example:
$ cmake -S src -B build
In all cases the <options> may be zero or more of the Options below.
After generating a buildsystem one may use the corresponding native build tool to build the project.  For example, after using the Unix Makefiles generator one may run make directly:
$ make $ make install
Alternatively, one may use cmake to Build a Project by automatically choosing and invoking the appropriate native build tool.
Options -S <path-to-source> Path to root directory of the CMake project to build.
-B <path-to-build> Path to directory which CMake will use as the root of build directory.
If the directory doesn't already exist CMake will make it.
-C <initial-cache> Pre-load a script to populate the cache.
When CMake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project.  This option may be used to specify a file from which to load cache entries before the first pass through the project's CMake listfiles.  The loaded entries take priority over the project's default values.  The given file should be a CMake script containing set() commands that use the CACHE option, not a cache-format file.
References to CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR within the script evaluate to the top-level source and build tree.
-D <var>:<type>=<value>, -D <var>=<value> Create or update a CMake CACHE entry.
When CMake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project.  This option may be used to specify a setting that takes priority over the project's default value.  The option may be repeated for as many CACHE entries as desired.
If the :<type> portion is given it must be one of the types specified by the set() command documentation for its CACHE signature.  If the :<type> portion is omitted the entry will be created with no type if it does not exist with a type already.  If a command in the project sets the type to PATH or FILEPATH then the <value> will be converted to an absolute path.
This option may also be given as a single argument: -D<var>:<type>=<value> or -D<var>=<value>.
-U <globbing_expr> Remove matching entries from CMake CACHE.
This option may be used to remove one or more variables from the CMakeCache.txt file, globbing expressions using * and ? are supported.  The option may be repeated for as many CACHE entries as desired.
Use with care, you can make your CMakeCache.txt non-working.
-G <generator-name> Specify a build system generator.
CMake may support multiple native build systems on certain platforms.  A generator is responsible for generating a particular build system.  Possible generator names are specified in the cmake-generators(7) manual.
If not specified, CMake checks the CMAKE_GENERATOR environment variable and otherwise falls back to a builtin default selection.
-T <toolset-spec> Toolset specification for the generator, if supported.
Some CMake generators support a toolset specification to tell the native build system how to choose a compiler.  See the CMAKE_GENERATOR_TOOLSET variable for details.
-A <platform-name> Specify platform name if supported by generator.
Some CMake generators support a platform name to be given to the native build system to choose a compiler or SDK.  See the CMAKE_GENERATOR_PLATFORM variable for details.
--toolchain <path-to-file> Specify the cross compiling toolchain file, equivalent to setting CMAKE_TOOLCHAIN_FILE variable.
--install-prefix <directory> Specify the installation directory, used by the CMAKE_INSTALL_PREFIX variable. Must be an absolute path.
-Wno-dev Suppress developer warnings.
Suppress warnings that are meant for the author of the CMakeLists.txt files. By default this will also turn off deprecation warnings.
-Wdev  Enable developer warnings.
Enable warnings that are meant for the author of the CMakeLists.txt files. By default this will also turn on deprecation warnings.
-Werror=dev Make developer warnings errors.
Make warnings that are meant for the author of the CMakeLists.txt files errors. By default this will also turn on deprecated warnings as errors.
-Wno-error=dev Make developer warnings not errors.
Make warnings that are meant for the author of the CMakeLists.txt files not errors. By default this will also turn off deprecated warnings as errors.
-Wdeprecated Enable deprecated functionality warnings.
Enable warnings for usage of deprecated functionality, that are meant for the author of the CMakeLists.txt files.
-Wno-deprecated Suppress deprecated functionality warnings.
Suppress warnings for usage of deprecated functionality, that are meant for the author of the CMakeLists.txt files.
-Werror=deprecated Make deprecated macro and function warnings errors.
Make warnings for usage of deprecated macros and functions, that are meant for the author of the CMakeLists.txt files, errors.
-Wno-error=deprecated Make deprecated macro and function warnings not errors.
Make warnings for usage of deprecated macros and functions, that are meant for the author of the CMakeLists.txt files, not errors.
-L[A][H] List non-advanced cached variables.
List CACHE variables will run CMake and list all the variables from the CMake CACHE that are not marked as INTERNAL or ADVANCED. This will effectively display current CMake settings, which can then be changed with -D option.  Changing some of the variables may result in more variables being created.  If A is specified, then it will display also advanced variables.  If H is specified, it will also display help for each variable.
-N     View mode only.
Only load the cache.  Do not actually run configure and generate steps.
--graphviz=[file] Generate graphviz of dependencies, see CMakeGraphVizOptions for more.
Generate a graphviz input file that will contain all the library and executable dependencies in the project.  See the documentation for CMakeGraphVizOptions for more details.
--system-information [file] Dump information about this system.
Dump a wide range of information about the current system.  If run from the top of a binary tree for a CMake project it will dump additional information such as the cache, log files etc.
--log-level=<ERROR|WARNING|NOTICE|STATUS|VERBOSE|DEBUG|TRACE> Set the log level.
The message() command will only output messages of the specified log level or higher.  The default log level is STATUS.
To make a log level persist between CMake runs, set CMAKE_MESSAGE_LOG_LEVEL as a cache variable instead.  If both the command line option and the variable are given, the command line option takes precedence.
For backward compatibility reasons, --loglevel is also accepted as a synonym for this option.
--log-context Enable the message() command outputting context attached to each message.
This option turns on showing context for the current CMake run only.  To make showing the context persistent for all subsequent CMake runs, set CMAKE_MESSAGE_CONTEXT_SHOW as a cache variable instead.  When this command line option is given, CMAKE_MESSAGE_CONTEXT_SHOW is ignored.
--debug-trycompile Do not delete the try_compile() build tree.  Only useful on one try_compile() at a time.
Do not delete the files and directories created for try_compile() calls.  This is useful in debugging failed try_compiles.  It may however change the results of the try-compiles as old junk from a previous try-compile may cause a different test to either pass or fail incorrectly.  This option is best used for one try-compile at a time, and only when debugging.
--debug-output Put cmake in a debug mode.
Print extra information during the cmake run like stack traces with message(SEND_ERROR) calls.
--debug-find Put cmake find commands in a debug mode.
Print extra find call information during the cmake run to standard error. Output is designed for human consumption and not for parsing.  See also the CMAKE_FIND_DEBUG_MODE variable for debugging a more local part of the project.
--trace Put cmake in trace mode.
Print a trace of all calls made and from where.
--trace-expand Put cmake in trace mode.
Like --trace, but with variables expanded.
--trace-format=<format> Put cmake in trace mode and sets the trace output format.
human  Prints each trace line in a human-readable format. This is the default format.
json-v1 Prints each line as a separate JSON document. Each document is separated by a newline ( \n ). It is guaranteed that no newline characters will be present inside a JSON document.
JSON trace format:
{ "file": "/full/path/to/the/CMake/file.txt", "line": 0, "cmd": "add_executable", "args": ["foo", "bar"], "time": 1579512535.9687231, "frame": 2 }
file   The full path to the CMake source file where the function was called.
line   The line in file of the function call.
defer  Optional member that is present when the function call was deferred by cmake_language(DEFER).  If present, its value is a string containing the deferred call <id>.
cmd    The name of the function that was called.
args   A string list of all function parameters.