neulab/tldr huggingface dataset:
<supplementary group ID>, <supplementary group name>
and the necessary number of the following added after that for any remaining supplementary group IDs:
",%u(%s)"
and the necessary number of the following arguments added at the end of the argument list:
If any of the user ID, group ID, effective user ID, effective group ID, or supplementary/multiple group IDs cannot be mapped by the system into printable user or group names, the corresponding "(%s)" and name argument shall be omitted from the corresponding format string.
When any of the options are specified, the output format shall be as described in the OPTIONS section.
Output produced by the -G option and by the default case could potentially produce very long lines on systems that support large numbers of supplementary groups.  (On systems with user and group IDs that are 32-bit integers and with group names with a maximum of 8 bytes per name, 93 supplementary groups plus distinct effective and real group and user IDs could theoretically overflow the 2048-byte {LINE_MAX} text file line limit on the default output case. It would take about 186 supplementary groups to overflow the 2048-byte barrier using id -G).  This is not expected to be a problem in practice, but in cases where it is a concern, applications should consider using fold -s before post-processing the output of id.
The functionality provided by the 4 BSD groups utility can be simulated using:
id -Gn [ user ]
The 4 BSD command groups was considered, but it was not included because it did not provide the functionality of the id utility of the SVID. Also, it was thought that it would be easier to modify id to provide the additional functionality necessary to systems with multiple groups than to invent another command.
The options -u, -g, -n, and -r were added to ease the use of id with shell commands substitution. Without these options it is necessary to use some preprocessor such as sed to select the desired piece of information. Since output such as that produced by:
id -u -n
is frequently wanted, it seemed desirable to add the options.
fold, logname, who
The System Interfaces volume of POSIX.1‐2017, getgid(), getgroups(), getuid()
USERS(1)                          User Commands                         USERS(1)
users - print the user names of users currently logged in to the current host
users [OPTION]... [FILE]
Output who is currently logged in according to FILE.  If FILE is not specified, use /var/run/utmp.  /var/log/wtmp as FILE is common.
Written by Joseph Arceneaux and David MacKenzie.
getent(1), who(1)
Full documentation <https://www.gnu.org/software/coreutils/users> or available locally via: info '(coreutils) users invocation'
phpize(1)                      Scripting Language                      phpize(1)
phpize - prepare a PHP extension for compiling
phpize [options]
phpize is a shell script to prepare PHP extension for compiling.
--clean        Remove all created files --help         Prints usage information --version -v             Prints API version information
php(1)
VIRT-CLONE(1)                Virtualization Support                VIRT-CLONE(1)
virt-clone - clone existing virtual machine images
virt-clone [OPTION]...
virt-clone is a command line tool for cloning existing virtual machine images using the libvirt hypervisor management library. It will copy the disk images of any existing virtual machine, and define a new guest with an identical virtual hardware configuration. Elements which require uniqueness will be updated to avoid a clash between old and new guests.
By default, virt-clone will show an error if the necessary information to clone the guest is not provided. The --auto-clone option will generate all needed input, aside from the source guest to clone.
Please note, virt-clone does not change anything _inside_ the guest OS, it only duplicates disks and does host side changes. So things like changing passwords, changing static IP address, etc are outside the scope of this tool. For these types of changes, please see virt-sysprep.
Most options are not required. Minimum requirements are --original or --original-xml (to specify the guest to clone), --name, and appropriate storage options via -file.
--connect URI Connect to a non-default hypervisor. See virt-install(1) for details
-o, --original ORIGINAL_GUEST Name of the original guest to be cloned. This guest must be shut off.
--original-xml ORIGINAL_XML Libvirt guest xml file to use as the original guest. The guest does not need to be defined on the libvirt connection. This takes the place of the --original parameter.
--auto-clone Generate a new guest name, and paths for new storage.
An example of possible generated output:
Original name        : MyVM Generated clone name : MyVM-clone
Original disk path   : /home/user/foobar.img Generated disk path  : /home/user/foobar-clone.img
If generated names collide with existing VMs or storage, a number is appended, such as foobar-clone-1.img, or MyVM-clone-3.
-n, --name NAME Name of the new guest virtual machine instance. This must be unique amongst all guests known to the hypervisor connection, including those not currently active.
-u, --uuid UUID UUID for the guest; if none is given a random UUID will be generated. If you specify UUID, you should use a 32-digit hexadecimal number. UUID are intended to be unique across the entire data center, and indeed world. Bear this in mind if manually specifying a UUID
-f, --file PATH Path to the file, disk partition, or logical volume to use as the backing store for the new guest's virtual disk. If the original guest has multiple disks, this parameter must be repeated multiple times, once per disk in the original virtual machine.
--nvram NVRAMFILE Optional path to the new nvram VARS file, if no path is specified and the guest has nvram the new nvram path will be auto-generated. If the guest doesn't have nvram this option will be ignored.
--force-copy TARGET Force cloning the passed disk target ('hdc', 'sda', etc.). By default, virt-clone will skip certain disks, such as those marked 'readonly' or 'shareable'.
--skip-copy TARGET Skip cloning the passed disk target ('hdc', 'sda', etc.). By default, virt-clone will clone certain disk images, typically read/write devices. Use this to skip copying of a specific device, so the new VM uses the same storage path as the original VM.
--nonsparse Fully allocate the new storage if the path being cloned is a sparse file.  See virt-install(1) for more details on sparse vs. nonsparse.
--preserve-data No storage is cloned: disk images specific by --file are preserved as is, and referenced in the new clone XML. This is useful if you want to clone a VM XML template, but not the storage contents.
--reflink When --reflink is specified, perform a lightweight copy. This is much faster if source images and destination images are all on the same btrfs filesystem.  If COW copy is not possible, then virt-clone fails.
-m, --mac MAC Fixed MAC address for the guest; If this parameter is omitted, or the value RANDOM is specified a suitable address will be randomly generated. Addresses are applied sequentially to the networks as they are listed in the original guest XML.
--print-xml Print the generated clone XML and exit without cloning.
--replace Shutdown and remove any existing guest with the passed --name before cloning the original guest.
--check Enable or disable some validation checks. See virt-install(1) for more details.
-q, --quiet Suppress non-error output.
-d, --debug Print debugging information to the terminal when running the install process.  The debugging information is also stored in ~/.cache/virt-manager/virt-clone.log even if this parameter is omitted.
Clone the guest called demo on the default connection, auto generating a new name and disk clone path.
# virt-clone \ --original demo \ --auto-clone
Clone the guest called demo which has a single disk to copy
# virt-clone \ --original demo \ --name newdemo \ --file /var/lib/xen/images/newdemo.img
Clone a QEMU guest with multiple disks
# virt-clone \ --connect qemu:///system \ --original demo \ --name newdemo \ --file /var/lib/xen/images/newdemo.img \ --file /var/lib/xen/images/newdata.img
Clone a guest to a physical device which is at least as big as the original guests disks. If the destination device is bigger, the new guest can do a filesystem resize when it boots.
# virt-clone \ --connect qemu:///system \ --original demo \ --name newdemo \ --file /dev/HostVG/DemoVM \ --mac 52:54:00:34:11:54
Copyright (C) Fujitsu Limited, Copyright (C) Red Hat, Inc, and various contributors.  This is free software. You may redistribute copies of it under the terms of the GNU General Public License https://www.gnu.org/licenses/gpl.html.  There is NO WARRANTY, to the extent permitted by law.
virt-sysprep(1), virsh(1), virt-install(1), virt-manager(1), the project website https://virt-manager.org
MYCLI(1)                     General Commands Manual                    MYCLI(1)
mycli - Command line client for MySQL/MariaDB and Percona
mycli [OPTIONS] [DATABASE]
mycli is a command line interface for MySQL, MariaDB, and Percona with auto-completion and syntax highlighting. The CLI is also capable of pretty printing tabular data.
-h|--host TEXT Host address of the database
-P|--port INTEGER Port number to use for connection. Honors $MYSQL_TCP_PORT
-u|--user TEXT User name to connect to the database
-S|--socket TEXT The socket file to use for connection.
-p|--password|--pass TEXT Password to connect to the database
-v|--version Version of mycli
-D|--database TEXT Database to use
-R|--prompt TEXT Prompt format (Default: "\t \u@\h:\d> ")
-l|--logfile FILENAME Log every query and its results to a file
--defaults-group-suffix TEXT Read config group with the specified suffix
--defaults-file PATH Only read default options from the given file
--login-path TEXT Read this path from the login file
--help Shows the help message and exit
mycli is written by Amjith Ramanujam (http://mycli.net)
This manual page was written by Lennart Weller <lhw@ring0.de>, for the Debian project (but may be used by others).
TTY(1)                            User Commands                           TTY(1)
tty - print the file name of the terminal connected to standard input
tty [OPTION]...
Print the file name of the terminal connected to standard input.
-s, --silent, --quiet print nothing, only return an exit status
Full documentation <https://www.gnu.org/software/coreutils/tty> or available locally via: info '(coreutils) tty invocation'
dpkg-deb(1)                        dpkg suite                        dpkg-deb(1)
dpkg-deb - Debian package archive (.deb) manipulation tool
dpkg-deb [option...] command
dpkg-deb packs, unpacks and provides information about Debian archives.
Use dpkg to install and remove packages from your system.
You can also invoke dpkg-deb by calling dpkg with whatever options you want to pass to dpkg-deb. dpkg will spot that you wanted dpkg-deb and run it for you.
For most commands taking an input archive argument, the archive can be read from standard input if the archive name is given as a single minus character («-»); otherwise lack of support will be documented in their respective command description.
-b, --build binary-directory [archive|directory] Creates a debian archive from the filesystem tree stored in binary- directory. binary-directory must have a DEBIAN subdirectory, which contains the control information files such as the control file itself. This directory will not appear in the binary package's filesystem archive, but instead the files in it will be put in the binary package's control information area.
Unless you specify --nocheck, dpkg-deb will read DEBIAN/control and parse it. It will check the file for syntax errors and other problems, and display the name of the binary package being built. dpkg-deb will also check the permissions of the maintainer scripts and other files found in the DEBIAN control information directory.
If no archive is specified then dpkg-deb will write the package into the file binary-directory.deb.
If the archive to be created already exists it will be overwritten.
If the second argument is a directory then dpkg-deb will write to the file directory/package_version_arch.deb.  When a target directory is specified, rather than a file, the --nocheck option may not be used (since dpkg-deb needs to read and parse the package control file to determine which filename to use).
-I, --info archive [control-file-name...] Provides information about a binary package archive.
If no control-file-names are specified then it will print a summary of the contents of the package as well as its control file.
If any control-file-names are specified then dpkg-deb will print them in the order they were specified; if any of the components weren't present it will print an error message to stderr about each one and exit with status 2.
-W, --show archive Provides information about a binary package archive in the format specified by the --showformat argument. The default format displays the package's name and version on one line, separated by a tabulator.
-f, --field archive [control-field-name...] Extracts control file information from a binary package archive.
If no control-field-names are specified then it will print the whole control file.
If any are specified then dpkg-deb will print their contents, in the order in which they appear in the control file. If more than one control-field-name is specified then dpkg-deb will precede each with its field name (and a colon and space).
No errors are reported for fields requested but not found.
-c, --contents archive Lists the contents of the filesystem tree archive portion of the package archive. It is currently produced in the format generated by tar's verbose listing.
-x, --extract archive directory Extracts the filesystem tree from a package archive into the specified directory.
Note that extracting a package to the root directory will not result in a correct installation! Use dpkg to install packages.
directory (but not its parents) will be created if necessary, and its permissions modified to match the contents of the package.
-X, --vextract archive directory Is like --extract (-x) with --verbose (-v) which prints a listing of the files extracted as it goes.
-R, --raw-extract archive directory Extracts the filesystem tree from a package archive into a specified directory, and the control information files into a DEBIAN subdirectory of the specified directory (since dpkg 1.16.1).
The target directory (but not its parents) will be created if necessary.
The input archive is not (currently) processed sequentially, so reading it from standard input («-») is not supported.
--ctrl-tarfile archive Extracts the control data from a binary package and sends it to standard output in tar format (since dpkg 1.17.14). Together with tar(1) this can be used to extract a particular control file from a package archive.  The input archive will always be processed sequentially.
--fsys-tarfile archive Extracts the filesystem tree data from a binary package and sends it to standard output in tar format. Together with tar(1) this can be used to extract a particular file from a package archive.  The input archive will always be processed sequentially.
-e, --control archive [directory] Extracts the control information files from a package archive into the specified directory.
If no directory is specified then a subdirectory DEBIAN in the current directory is used.
-?, --help Show the usage message and exit.
--showformat=format This option is used to specify the format of the output --show will produce. The format is a string that will be output for each package listed.
The string may reference any status field using the “${field-name}” form, a list of the valid fields can be easily produced using -I on the same package. A complete explanation of the formatting options (including escape sequences and field tabbing) can be found in the explanation of the --showformat option in dpkg-query(1).
The default for this field is “${Package}\t${Version}\n”.
-zcompress-level Specify which compression level to use on the compressor backend, when building a package (default is 9 for gzip, 6 for xz).  The accepted values are 0-9 with: 0 being mapped to compressor none for gzip.  Before dpkg 1.16.2 level 0 was equivalent to compressor none for all compressors.
-Scompress-strategy Specify which compression strategy to use on the compressor backend, when building a package (since dpkg 1.16.2). Allowed values are none (since dpkg 1.16.4), filtered, huffman, rle and fixed for gzip (since dpkg 1.17.0) and extreme for xz.
-Zcompress-type Specify which compression type to use when building a package. Allowed values are gzip, xz (since dpkg 1.15.6), and none (default is xz).
--[no-]uniform-compression Specify that the same compression parameters should be used for all archive members (i.e. control.tar and data.tar; since dpkg 1.17.6). Otherwise only the data.tar member will use those parameters. The only supported compression types allowed to be uniformly used are none, gzip and xz.  The --no-uniform-compression option disables uniform compression (since dpkg 1.19.0).  Uniform compression is the default (since dpkg 1.19.0).
--root-owner-group Set the owner and group for each entry in the filesystem tree data to root with id 0 (since dpkg 1.19.0).
Note: This option can be useful for rootless builds (see rootless-builds.txt), but should not be used when the entries have an owner or group that is not root.  Support for these will be added later in the form of a meta manifest.
--deb-format=format Set the archive format version used when building (since dpkg 1.17.0).  Allowed values are 2.0 for the new format, and 0.939000 for the old one (default is 2.0).
The old archive format is less easily parsed by non-Debian tools and is now obsolete; its only use is when building packages to be parsed by versions of dpkg older than 0.93.76 (September 1995), which was released as i386 a.out only.
--nocheck Inhibits dpkg-deb --build's usual checks on the proposed contents of an archive. You can build any archive you want, no matter how broken, this way.
-v, --verbose Enables verbose output (since dpkg 1.16.1).  This currently only affects --extract making it behave like --vextract.
-D, --debug Enables debugging output. This is not very interesting.
0   The requested action was successfully performed.
2   Fatal or unrecoverable error due to invalid command-line usage, or interactions with the system, such as accesses to the database, memory allocations, etc.
DPKG_COLORS Sets the color mode (since dpkg 1.18.5).  The currently accepted values are: auto (default), always and never.
TMPDIR If set, dpkg-deb will use it as the directory in which to create temporary files and directories.
SOURCE_DATE_EPOCH If set, it will be used as the timestamp (as seconds since the epoch) in the deb(5)'s ar(5) container and used to clamp the mtime in the tar(5) file entries.
Do not attempt to use just dpkg-deb to install software! You must use dpkg proper to ensure that all the files are correctly placed and the package's scripts run and its status and contents recorded.
dpkg-deb -I package1.deb package2.deb does the wrong thing.
There is no authentication on .deb files; in fact, there isn't even a straightforward checksum.  (Higher level tools like APT support authenticating .deb packages retrieved from a given repository, and most packages nowadays provide an md5sum control file generated by debian/rules. Though this is not directly supported by the lower level tools.)
deb(5), deb-control(5), dpkg(1), dselect(1).
CTEST(1)                              CMake                             CTEST(1)
ctest - CTest Command-Line Reference
Contents • ctest(1)
• Synopsis
• Label Matching
• Label and Subproject Summary
• Build and Test Mode
• Dashboard Client
• Dashboard Client Steps
• Dashboard Client Modes
• Dashboard Client via CTest Command-Line
• Dashboard Client via CTest Script
• Dashboard Client Configuration
• CTest Start Step
• CTest Update Step
• CTest Configure Step
• CTest Build Step
• CTest Test Step
• CTest Coverage Step
• CTest MemCheck Step
• CTest Submit Step
• Show as JSON Object Model
• Resource Allocation
• Resource Specification File
• RESOURCE_GROUPS Property
• Environment Variables
• See Also
ctest [<options>] ctest --build-and-test <path-to-source> <path-to-build> --build-generator <generator> [<options>...] [--build-options <opts>...] [--test-command <command> [<args>...]] ctest {-D <dashboard> | -M <model> -T <action> | -S <script> | -SP <script>} [-- <dashboard-options>...]
The ctest executable is the CMake test driver program.  CMake-generated build trees created for projects that use the enable_testing() and add_test() commands have testing support.  This program will run the tests and report results.
--preset <preset>, --preset=<preset> Use a test preset to specify test options. The project binary directory is inferred from the configurePreset key. The current working directory must contain CMake preset files.  See preset for more details.
--list-presets Lists the available test presets. The current working directory must contain CMake preset files.
-C <cfg>, --build-config <cfg> Choose configuration to test.
Some CMake-generated build trees can have multiple build configurations in the same tree.  This option can be used to specify which one should be tested.  Example configurations are Debug and Release.
--progress Enable short progress output from tests.
When the output of ctest is being sent directly to a terminal, the progress through the set of tests is reported by updating the same line rather than printing start and end messages for each test on new lines.  This can significantly reduce the verbosity of the test output.  Test completion messages are still output on their own line for failed tests and the final test summary will also still be logged.
This option can also be enabled by setting the environment variable CTEST_PROGRESS_OUTPUT.
-V,--verbose Enable verbose output from tests.
Test output is normally suppressed and only summary information is displayed.  This option will show all test output.
-VV,--extra-verbose Enable more verbose output from tests.
Test output is normally suppressed and only summary information is displayed.  This option will show even more test output.
--debug Displaying more verbose internals of CTest.
This feature will result in a large number of output that is mostly useful for debugging dashboard problems.
--output-on-failure Output anything outputted by the test program if the test should fail.  This option can also be enabled by setting the CTEST_OUTPUT_ON_FAILURE environment variable
--stop-on-failure Stop running the tests when the first failure happens.
-F     Enable failover.
This option allows CTest to resume a test set execution that was previously interrupted.  If no interruption occurred, the -F option will have no effect.
-j <jobs>, --parallel <jobs> Run the tests in parallel using the given number of jobs.
This option tells CTest to run the tests in parallel using given number of jobs. This option can also be set by setting the CTEST_PARALLEL_LEVEL environment variable.
This option can be used with the PROCESSORS test property.
See Label and Subproject Summary.
--resource-spec-file <file> Run CTest with resource allocation enabled, using the resource specification file specified in <file>.
When ctest is run as a Dashboard Client this sets the ResourceSpecFile option of the CTest Test Step.
--test-load <level> While running tests in parallel (e.g. with -j), try not to start tests when they may cause the CPU load to pass above a given threshold.
When ctest is run as a Dashboard Client this sets the TestLoad option of the CTest Test Step.
-Q,--quiet Make CTest quiet.
This option will suppress all the output.  The output log file will still be generated if the --output-log is specified.  Options such as --verbose, --extra-verbose, and --debug are ignored if --quiet is specified.
-O <file>, --output-log <file> Output to log file.
This option tells CTest to write all its output to a <file> log file.
--output-junit <file> Write test results in JUnit format.
This option tells CTest to write test results to <file> in JUnit XML format. If <file> already exists, it will be overwritten. If using the -S option to run a dashboard script, use the OUTPUT_JUNIT keyword with the ctest_test() command instead.
-N,--show-only[=<format>] Disable actual execution of tests.
This option tells CTest to list the tests that would be run but not actually run them.  Useful in conjunction with the -R and -E options.
<format> can be one of the following values.
human  Human-friendly output.  This is not guaranteed to be stable.  This is the default.
json-v1 Dump the test information in JSON format.  See Show as JSON Object Model.
-L <regex>, --label-regex <regex> Run tests with labels matching regular expression as described under string(REGEX).
This option tells CTest to run only the tests whose labels match the given regular expression.  When more than one -L option is given, a test will only be run if each regular expression matches at least one of the test's labels (i.e. the multiple -L labels form an AND relationship).  See Label Matching.
-R <regex>, --tests-regex <regex> Run tests matching regular expression.
This option tells CTest to run only the tests whose names match the given regular expression.
-E <regex>, --exclude-regex <regex> Exclude tests matching regular expression.
This option tells CTest to NOT run the tests whose names match the given regular expression.
-LE <regex>, --label-exclude <regex> Exclude tests with labels matching regular expression.
This option tells CTest to NOT run the tests whose labels match the given regular expression.  When more than one -LE option is given, a test will only be excluded if each regular expression matches at least one of the test's labels (i.e. the multiple -LE labels form an AND relationship).  See Label Matching.
-FA <regex>, --fixture-exclude-any <regex> Exclude fixtures matching <regex> from automatically adding any tests to the test set.
If a test in the set of tests to be executed requires a particular fixture, that fixture's setup and cleanup tests would normally be added to the test set automatically. This option prevents adding setup or cleanup tests for fixtures matching the <regex>. Note that all other fixture behavior is retained, including test dependencies and skipping tests that have fixture setup tests that fail.
-FS <regex>, --fixture-exclude-setup <regex> Same as -FA except only matching setup tests are excluded.
-FC <regex>, --fixture-exclude-cleanup <regex> Same as -FA except only matching cleanup tests are excluded.
-D <dashboard>, --dashboard <dashboard> Execute dashboard test.
This option tells CTest to act as a CDash client and perform a dashboard test.  All tests are <Mode><Test>, where <Mode> can be Experimental, Nightly, and Continuous, and <Test> can be Start, Update, Configure, Build, Test, Coverage, and Submit.
See Dashboard Client.
-D <var>:<type>=<value> Define a variable for script mode.
Pass in variable values on the command line.  Use in conjunction with -S to pass variable values to a dashboard script.  Parsing -D arguments as variable values is only attempted if the value following -D does not match any of the known dashboard types.
-M <model>, --test-model <model> Sets the model for a dashboard.
This option tells CTest to act as a CDash client where the <model> can be Experimental, Nightly, and Continuous.  Combining -M and -T is similar to -D.
-T <action>, --test-action <action> Sets the dashboard action to perform.
This option tells CTest to act as a CDash client and perform some action such as start, build, test etc. See Dashboard Client Steps for the full list of actions.  Combining -M and -T is similar to -D.
-S <script>, --script <script> Execute a dashboard for a configuration.
This option tells CTest to load in a configuration script which sets a number of parameters such as the binary and source directories.  Then CTest will do what is required to create and run a dashboard.  This option basically sets up a dashboard and then runs ctest -D with the appropriate options.
-SP <script>, --script-new-process <script> Execute a dashboard for a configuration.
This option does the same operations as -S but it will do them in a separate process.  This is primarily useful in cases where the script may modify the environment and you do not want the modified environment to impact other -S scripts.
-I [Start,End,Stride,test#,test#|Test file], --tests-information Run a specific number of tests by number.
This option causes CTest to run tests starting at number Start, ending at number End, and incrementing by Stride.  Any additional numbers after Stride are considered individual test numbers. Start, End, or Stride can be empty.  Optionally a file can be given that contains the same syntax as the command line.
-U, --union Take the Union of -I and -R.
When both -R and -I are specified by default the intersection of tests are run.  By specifying -U the union of tests is run instead.
--rerun-failed Run only the tests that failed previously.
This option tells CTest to perform only the tests that failed during its previous run.  When this option is specified, CTest ignores all other options intended to modify the list of tests to run (-L, -R, -E, -LE, -I, etc).  In the event that CTest runs and no tests fail, subsequent calls to CTest with the --rerun-failed option will run the set of tests that most recently failed (if any).
--repeat <mode>:<n> Run tests repeatedly based on the given <mode> up to <n> times. The modes are:
until-fail Require each test to run <n> times without failing in order to pass.  This is useful in finding sporadic failures in test cases.
until-pass Allow each test to run up to <n> times in order to pass. Repeats tests if they fail for any reason.  This is useful in tolerating sporadic failures in test cases.
after-timeout Allow each test to run up to <n> times in order to pass. Repeats tests only if they timeout.  This is useful in tolerating sporadic timeouts in test cases on busy machines.
--repeat-until-fail <n> Equivalent to --repeat until-fail:<n>.
--max-width <width> Set the max width for a test name to output.
Set the maximum width for each test name to show in the output. This allows the user to widen the output to avoid clipping the test name which can be very annoying.
--interactive-debug-mode [0|1] Set the interactive mode to 0 or 1.
This option causes CTest to run tests in either an interactive mode or a non-interactive mode.  In dashboard mode (Experimental, Nightly, Continuous), the default is non-interactive.  In non-interactive mode, the environment variable DASHBOARD_TEST_FROM_CTEST is set.
Prior to CMake 3.11, interactive mode on Windows allowed system debug popup windows to appear.  Now, due to CTest's use of libuv to launch test processes, all system debug popup windows are always blocked.
--no-label-summary Disable timing summary information for labels.
This option tells CTest not to print summary information for each label associated with the tests run.  If there are no labels on the tests, nothing extra is printed.
--no-subproject-summary Disable timing summary information for subprojects.
This option tells CTest not to print summary information for each subproject associated with the tests run.  If there are no subprojects on the tests, nothing extra is printed.
--build-and-test See Build and Test Mode.
--test-dir <dir> Specify the directory in which to look for tests.
--test-output-size-passed <size> Limit the output for passed tests to <size> bytes.
--test-output-size-failed <size> Limit the output for failed tests to <size> bytes.
--overwrite Overwrite CTest configuration option.
By default CTest uses configuration options from configuration file.  This option will overwrite the configuration option.
--force-new-ctest-process Run child CTest instances as new processes.
By default CTest will run child CTest instances within the same process.  If this behavior is not desired, this argument will enforce new processes for child CTest processes.
--schedule-random Use a random order for scheduling tests.
This option will run the tests in a random order.  It is commonly used to detect implicit dependencies in a test suite.
--submit-index Legacy option for old Dart2 dashboard server feature.  Do not use.
--timeout <seconds> Set the default test timeout.
This option effectively sets a timeout on all tests that do not already have a timeout set on them via the TIMEOUT property.
--stop-time <time> Set a time at which all tests should stop running.
Set a real time of day at which all tests should timeout. Example: 7:00:00 -0400.  Any time format understood by the curl date parser is accepted.  Local time is assumed if no timezone is specified.
--print-labels Print all available test labels.
This option will not run any tests, it will simply print the list of all labels associated with the test set.
--no-tests=<[error|ignore]> Regard no tests found either as error or ignore it.
If no tests were found, the default behavior of CTest is to always log an error message but to return an error code in script mode only.  This option unifies the behavior of CTest by either returning an error code if no tests were found or by ignoring it.
--help,-help,-usage,-h,-H,/? Print usage information and exit.
Usage describes the basic command line interface and its options.
--version,-version,/V [<f>] Show program name/version banner and exit.
If a file is specified, the version is written into it.  The help is printed to a named <f>ile if given.
--help-full [<f>] Print all help manuals and exit.
All manuals are printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-manual <man> [<f>] Print one help manual and exit.
The specified manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.
--help-manual-list [<f>] List help manuals available and exit.
The list contains all manuals for which help may be obtained by using the --help-manual option followed by a manual name.  The help is printed to a named <f>ile if given.
--help-command <cmd> [<f>] Print help for one command and exit.
The cmake-commands(7) manual entry for <cmd> is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-command-list [<f>] List commands with help available and exit.
The list contains all commands for which help may be obtained by using the --help-command option followed by a command name.  The help is printed to a named <f>ile if given.
--help-commands [<f>] Print cmake-commands manual and exit.
The cmake-commands(7) manual is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-module <mod> [<f>] Print help for one module and exit.
The cmake-modules(7) manual entry for <mod> is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-module-list [<f>] List modules with help available and exit.
The list contains all modules for which help may be obtained by using the --help-module option followed by a module name.  The help is printed to a named <f>ile if given.
--help-modules [<f>] Print cmake-modules manual and exit.
The cmake-modules(7) manual is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-policy <cmp> [<f>] Print help for one policy and exit.
The cmake-policies(7) manual entry for <cmp> is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-policy-list [<f>] List policies with help available and exit.
The list contains all policies for which help may be obtained by using the --help-policy option followed by a policy name.  The help is printed to a named <f>ile if given.
--help-policies [<f>] Print cmake-policies manual and exit.
The cmake-policies(7) manual is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-property <prop> [<f>] Print help for one property and exit.
The cmake-properties(7) manual entries for <prop> are printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-property-list [<f>] List properties with help available and exit.
The list contains all properties for which help may be obtained by using the --help-property option followed by a property name.  The help is printed to a named <f>ile if given.
--help-properties [<f>] Print cmake-properties manual and exit.
The cmake-properties(7) manual is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-variable <var> [<f>] Print help for one variable and exit.
The cmake-variables(7) manual entry for <var> is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
--help-variable-list [<f>] List variables with help available and exit.
The list contains all variables for which help may be obtained by using the --help-variable option followed by a variable name.  The help is printed to a named <f>ile if given.
--help-variables [<f>] Print cmake-variables manual and exit.
The cmake-variables(7) manual is printed in a human-readable text format.  The help is printed to a named <f>ile if given.
Tests may have labels attached to them. Tests may be included or excluded from a test run by filtering on the labels.  Each individual filter is a regular expression applied to the labels attached to a test.
When -L is used, in order for a test to be included in a test run, each regular expression must match at least one label.  Using more than one -L option means "match all of these".
The -LE option works just like -L, but excludes tests rather than including them. A test is excluded if each regular expression matches at least one label.
If a test has no labels attached to it, then -L will never include that test, and -LE will never exclude that test.  As an example of tests with labels, consider five tests, with the following labels:
• test1 has labels tuesday and production
• test2 has labels tuesday and test
• test3 has labels wednesday and production
• test4 has label wednesday
• test5 has labels friday and test
Running ctest with -L tuesday -L test will select test2, which has both labels. Running CTest with -L test will select test2 and test5, because both of them have a label that matches that regular expression.
Because the matching works with regular expressions, take note that running CTest with -L es will match all five tests.  To select the tuesday and wednesday tests together, use a single regular expression that matches either of them, like -L "tue|wed".
CTest prints timing summary information for each LABEL and subproject associated with the tests run. The label time summary will not include labels that are mapped to subprojects.
New in version 3.22: Labels added dynamically during test execution are also reported in the timing summary.  See Additional Labels.
When the PROCESSORS test property is set, CTest will display a weighted test timing result in label and subproject summaries. The time is reported with sec*proc instead of just sec.
The weighted time summary reported for each label or subproject j is computed as:
Weighted Time Summary for Label/Subproject j = sum(raw_test_time[j,i] * num_processors[j,i], i=1...num_tests[j])
for labels/subprojects j=1...total
• raw_test_time[j,i]: Wall-clock time for the i test for the j label or subproject
• num_processors[j,i]: Value of the CTest PROCESSORS property for the i test for the j label or subproject
• num_tests[j]: Number of tests associated with the j label or subproject
• total: Total number of labels or subprojects that have at least one test run
Therefore, the weighted time summary for each label or subproject represents the amount of time that CTest gave to run the tests for each label or subproject and gives a good representation of the total expense of the tests for each label or subproject when compared to other labels or subprojects.
For example, if SubprojectA showed 100 sec*proc and SubprojectB showed 10 sec*proc, then CTest allocated approximately 10 times the CPU/core time to run the tests for SubprojectA than for SubprojectB (e.g. so if effort is going to be expended to reduce the cost of the test suite for the whole project, then reducing the cost of the test suite for SubprojectA would likely have a larger impact than effort to reduce the cost of the test suite for SubprojectB).
CTest provides a command-line signature to configure (i.e. run cmake on), build, and/or execute a test:
ctest --build-and-test <path-to-source> <path-to-build> --build-generator <generator> [<options>...] [--build-options <opts>...] [--test-command <command> [<args>...]]
The configure and test steps are optional. The arguments to this command line are the source and binary directories.  The --build-generator option must be provided to use --build-and-test.  If --test-command is specified then that will be run after the build is complete.  Other options that affect this mode include:
--build-target Specify a specific target to build.
If left out the all target is built.
--build-nocmake Run the build without running cmake first.
Skip the cmake step.
--build-run-dir Specify directory to run programs from.
Directory where programs will be after it has been compiled.
--build-two-config Run CMake twice.
--build-exe-dir Specify the directory for the executable.
--build-generator Specify the generator to use. See the cmake-generators(7) manual.
--build-generator-platform Specify the generator-specific platform.
--build-generator-toolset Specify the generator-specific toolset.
--build-project Specify the name of the project to build.
--build-makeprogram Specify the explicit make program to be used by CMake when configuring and building the project. Only applicable for Make and Ninja based generators.
--build-noclean Skip the make clean step.
--build-config-sample A sample executable to use to determine the configuration that should be used.  e.g.  Debug, Release etc.
--build-options Additional options for configuring the build (i.e. for CMake, not for the build tool).  Note that if this is specified, the --build-options keyword and its arguments must be the last option given on the command line, with the possible exception of --test-command.
--test-command The command to run as the test step with the --build-and-test option.  All arguments following this keyword will be assumed to be part of the test command line, so it must be the last option given.
--test-timeout The time limit in seconds
CTest can operate as a client for the CDash software quality dashboard application.  As a dashboard client, CTest performs a sequence of steps to configure, build, and test software, and then submits the results to a CDash server. The command-line signature used to submit to CDash is:
ctest (-D <dashboard> | -M <model> -T <action> | -S <script> | -SP <script>) [-- <dashboard-options>...]
Options for Dashboard Client include:
--group <group> Specify what group you'd like to submit results to
Submit dashboard to specified group instead of default one.  By default, the dashboard is submitted to Nightly, Experimental, or Continuous group, but by specifying this option, the group can be arbitrary.
This replaces the deprecated option --track.  Despite the name change its behavior is unchanged.
-A <file>, --add-notes <file> Add a notes file with submission.
This option tells CTest to include a notes file when submitting dashboard.
--tomorrow-tag Nightly or Experimental starts with next day tag.
This is useful if the build will not finish in one day.
--extra-submit <file>[;<file>] Submit extra files to the dashboard.
This option will submit extra files to the dashboard.
--http1.0 Submit using HTTP 1.0.
This option will force CTest to use HTTP 1.0 to submit files to the dashboard, instead of HTTP 1.1.
--no-compress-output Do not compress test output when submitting.
This flag will turn off automatic compression of test output.  Use this to maintain compatibility with an older version of CDash which doesn't support compressed test output.
Dashboard Client Steps CTest defines an ordered list of testing steps of which some or all may be run as a dashboard client:
Start  Start a new dashboard submission to be composed of results recorded by the following steps.  See the CTest Start Step section below.
Update Update the source tree from its version control repository. Record the old and new versions and the list of updated source files.  See the CTest Update Step section below.
Configure Configure the software by running a command in the build tree. Record the configuration output log.  See the CTest Configure Step section below.
Build  Build the software by running a command in the build tree.  Record the build output log and detect warnings and errors.  See the CTest Build Step section below.
Test   Test the software by loading a CTestTestfile.cmake from the build tree and executing the defined tests.  Record the output and result of each test.  See the CTest Test Step section below.
Coverage Compute coverage of the source code by running a coverage analysis tool and recording its output.  See the CTest Coverage Step section below.
MemCheck Run the software test suite through a memory check tool.  Record the test output, results, and issues reported by the tool.  See the CTest MemCheck Step section below.
Submit Submit results recorded from other testing steps to the software quality dashboard server.  See the CTest Submit Step section below.
Dashboard Client Modes CTest defines three modes of operation as a dashboard client:
Nightly This mode is intended to be invoked once per day, typically at night.  It enables the Start, Update, Configure, Build, Test, Coverage, and Submit steps by default.  Selected steps run even if the Update step reports no changes to the source tree.
Continuous This mode is intended to be invoked repeatedly throughout the day. It enables the Start, Update, Configure, Build, Test, Coverage, and Submit steps by default, but exits after the Update step if it reports no changes to the source tree.
Experimental This mode is intended to be invoked by a developer to test local changes.  It enables the Start, Configure, Build, Test, Coverage, and Submit steps by default.
Dashboard Client via CTest Command-Line CTest can perform testing on an already-generated build tree.  Run the ctest command with the current working directory set to the build tree and use one of these signatures:
ctest -D <mode>[<step>] ctest -M <mode> [ -T <step> ]...
The <mode> must be one of the above Dashboard Client Modes, and each <step> must be one of the above Dashboard Client Steps.
CTest reads the Dashboard Client Configuration settings from a file in the build tree called either CTestConfiguration.ini or DartConfiguration.tcl (the names are historical).  The format of the file is:
# Lines starting in '#' are comments. # Other non-blank lines are key-value pairs. <setting>: <value>
where <setting> is the setting name and <value> is the setting value.
In build trees generated by CMake, this configuration file is generated by the CTest module if included by the project.  The module uses variables to obtain a value for each setting as documented with the settings below.
Dashboard Client via CTest Script CTest can perform testing driven by a cmake-language(7) script that creates and maintains the source and build tree as well as performing the testing steps.  Run the ctest command with the current working directory set outside of any build tree and use one of these signatures:
ctest -S <script> ctest -SP <script>
The <script> file must call CTest Commands commands to run testing steps explicitly as documented below.  The commands obtain Dashboard Client Configuration settings from their arguments or from variables set in the script.
The Dashboard Client Steps may be configured by named settings as documented in the following sections.
CTest Start Step Start a new dashboard submission to be composed of results recorded by the following steps.
In a CTest Script, the ctest_start() command runs this step.  Arguments to the command may specify some of the step settings.  The command first runs the command-line specified by the CTEST_CHECKOUT_COMMAND variable, if set, to initialize the source directory.
Configuration settings include:
BuildDirectory The full path to the project build tree.
• CTest Script variable: CTEST_BINARY_DIRECTORY
• CTest module variable: PROJECT_BINARY_DIR
SourceDirectory The full path to the project source tree.
• CTest Script variable: CTEST_SOURCE_DIRECTORY
• CTest module variable: PROJECT_SOURCE_DIR