neulab/tldr huggingface dataset:
There are also virtual disks which typically have no useful information to convey to smartmontools, but could conceivably in the future.  An example of a virtual disk is the OS's view of a RAID 1 box.  There are most likely two SATA disks inside a RAID 1 box.  Addressing those SATA disks from a distant OS is a challenge for smartmontools.  Another approach is running a tool like smartmontools inside the RAID 1 box (e.g. a Network Attached Storage (NAS) box) and fetching the logs via a browser.
smartctl -a /dev/sda Print a large amount of SMART information for drive /dev/sda.
smartctl -s off /dev/sdd Disable SMART monitoring and data log collection on drive /dev/sdd.
smartctl --smart=on --offlineauto=on --saveauto=on /dev/sda Enable SMART on drive /dev/sda, enable automatic offline testing every four hours, and enable autosaving of SMART Attributes.  This is a good start-up line for your system's init files.  You can issue this command on a running system.
smartctl -t long /dev/sdc Begin an extended self-test of drive /dev/sdc.  You can issue this command on a running system.  The results can be seen in the self-test log visible with the '-l selftest' option after it has completed.
smartctl -s on -t offline /dev/sda Enable SMART on the disk, and begin an immediate offline test of drive /dev/sda.  You can issue this command on a running system.  The results are only used to update the SMART Attributes, visible with the '-A' option.  If any device errors occur, they are logged to the SMART error log, which can be seen with the '-l error' option.
smartctl -A -v 9,minutes /dev/sda Shows the vendor Attributes, when the disk stores its power-on time internally in minutes rather than hours.
smartctl -q errorsonly -H -l selftest /dev/sda Produces output only if the device returns failing SMART status, or if some of the logged self-tests ended with errors.
smartctl -q silent -a /dev/sda Examine all SMART data for device /dev/sda, but produce no printed output.  You must use the exit status (the $?  shell variable) to learn if any Attributes are out of bound, if the SMART status is failing, if there are errors recorded in the self-test log, or if there are errors recorded in the disk error log.
smartctl -a -d 3ware,0 /dev/twl0 Examine all SMART data for the first SATA (not SAS) disk connected to a 3ware RAID 9750 controller card.
smartctl -t long -d areca,4 /dev/sg2 Start a long self-test on the fourth SATA disk connected to an Areca RAID controller addressed by /dev/sg2.
smartctl -a -d hpt,1/3 /dev/sda (under Linux) smartctl -a -d hpt,1/3 /dev/hptrr (under FreeBSD) Examine all SMART data for the (S)ATA disk directly connected to the third channel of the first HighPoint RocketRAID controller card.
smartctl -t short -d hpt,1/1/2 /dev/sda (under Linux) smartctl -t short -d hpt,1/1/2 /dev/hptrr (under FreeBSD) Start a short self-test on the (S)ATA disk connected to second pmport on the first channel of the first HighPoint RocketRAID controller card.
smartctl -t select,10-100 -t select,30-300 -t afterselect,on -t pending,45 /dev/sda Run a selective self-test on LBAs 10 to 100 and 30 to 300.  After the these LBAs have been tested, read-scan the remainder of the disk.  If the disk is power-cycled during the read-scan, resume the scan 45 minutes after power to the device is restored.
smartctl -a -d cciss,0 /dev/cciss/c0d0 Examine all SMART data for the first SCSI disk connected to a cciss RAID controller card.
The exit statuses of smartctl are defined by a bitmask.  If all is well with the disk, the exit status (return value) of smartctl is 0 (all bits turned off).  If a problem occurs, or an error, potential error, or fault is detected, then a non-zero status is returned.  In this case, the eight different bits in the exit status have the following meanings for ATA disks; some of these values may also be returned for SCSI disks.
Bit 0: Command line did not parse.
Bit 1: Device open failed, device did not return an IDENTIFY DEVICE structure, or device is in a low-power mode (see '-n' option above).
Bit 2: Some SMART or other ATA command to the disk failed, or there was a checksum error in a SMART data structure (see '-b' option above).
Bit 3: SMART status check returned "DISK FAILING".
Bit 4: We found prefail Attributes <= threshold.
Bit 5: SMART status check returned "DISK OK" but we found that some (usage or prefail) Attributes have been <= threshold at some time in the past.
Bit 6: The device error log contains records of errors.
Bit 7: The device self-test log contains records of errors.  [ATA only] Failed self-tests outdated by a newer successful extended self- test are ignored.
To test within the shell for whether or not the different bits are turned on or off, you can use the following type of construction (which should work with any POSIX compatible shell): smartstat=$(($? & 8)) This looks at only at bit 3 of the exit status $?  (since 8=2^3).  The shell variable $smartstat will be nonzero if SMART status check returned "disk failing" and zero otherwise.
This shell script prints all status bits: val=$?; mask=1 for i in 0 1 2 3 4 5 6 7; do echo "Bit $i: $(((val & mask) && 1))" mask=$((mask << 1)) done
/usr/bin/smartctl full path of this executable.
/usr/share/smartmontools/drivedb.h drive database (see '-B' option).
/etc/smart_drivedb.h optional local drive database (see '-B' option).
Bruce Allen (project initiator), Christian Franke (project manager, Windows port and all sort of things), Douglas Gilbert (SCSI subsystem), Volker Kuhlmann (moderator of support and database mailing list), Gabriele Pohl (wiki & development team support), Alex Samorukov (FreeBSD port and more, new Trac wiki).
Many other individuals have made contributions and corrections, see AUTHORS, ChangeLog and repository files.
The first smartmontools code was derived from the smartsuite package, written by Michael Cornwell and Andre Hedrick.
To submit a bug report, create a ticket in smartmontools wiki: <https://www.smartmontools.org/>. Alternatively send the info to the smartmontools support mailing list: <https://listi.jpberlin.de/mailman/listinfo/smartmontools-support>.
smartd(8). update-smart-drivedb(8).
Please see the following web site for more info: <https://www.smartmontools.org/>
An introductory article about smartmontools is Monitoring Hard Disks with SMART, by Bruce Allen, Linux Journal, January 2004, pages 74–77.  See <https://www.linuxjournal.com/article/6983>.
If you would like to understand better how SMART works, and what it does, a good place to start is with Sections 4.8 and 6.54 of the first volume of the 'AT Attachment with Packet Interface-7' (ATA/ATAPI-7) specification Revision 4b.  This documents the SMART functionality which the smartmontools utilities provide access to.
The functioning of SMART was originally defined by the SFF-8035i revision 2 and the SFF-8055i revision 1.4 specifications.  These are publications of the Small Form Factors (SFF) Committee.
Links to these and other documents may be found on the Links page of the smartmontools Wiki at <https://www.smartmontools.org/wiki/Links>.
smartmontools-7.2 2020-12-30 r5155 $Id: smartctl.8.in 5143 2020-12-21 18:34:31Z chrfranke $
Nemo(1)                      General Commands Manual                     Nemo(1)
nemo - the Cinnamon File Manager
nemo [options] URIs...
This manual page documents briefly the nemo command.
Nemo is the file manager for the Cinnamon desktop.
Nemo follows the usual GNU command line syntax, with long options starting with two dashes (`-'). A summary of options is included below.
--geometry=GEOMETRY Create the initial window with the given geometry.
--tabs Open URIs in tabs.
--existing-window Open URIs in an existing window.
--no-default-window Only create windows for explicitly specified URIs.
--no-desktop Ignored - left for compatibility only.
--fix-cache Repair the user thumbnail cache - this can be useful if you're having trouble with file thumbnails.  Must be run as root.
--quit Quit Nemo.
--help Show a summary of options.
--version Show Nemo' version.
Ordinarily, nemo and nemo-desktop treat being run as the root user as special, with certain restrictions and UI changes. This behavior can be bypassed via a gsettings key. You can use the following command to enable/disable this override:
gsettings set org.nemo.preferences treat-root-as-normal true|false
Please report bugs and feature requests here: https://github.com/linuxmint/nemo
This manual page was originally written for Nautilus by Takuo KITAME <kitame@debian.org> and Dafydd Harries <daf@muse.19inch.net> for the Debian GNU/Linux system (but may be used by others).
CGEXEC(1)                       libcgroup Manual                       CGEXEC(1)
cgexec - run the task in given control groups
cgexec [-h] [-g <controllers>:<path>] [--sticky] command [arguments]
The cgexec program executes the task command with arguments arguments in the given control groups.
-g <controllers>:<path> defines the control groups in which the task will be run. controllers is a list of controllers and path is the relative path to control groups in the given controllers list.
This flag can be used multiple times to define multiple pairs of lists of controllers and relative paths.  Instead of the list of all mounted controllers, the wildcard b"*b" can be used.
If this option is not used, cgexec will automatically place the task in the right cgroup based on /etc/cgrules.conf.
If /etc/cgrules.conf configuration file is used, there can be used template names. Then the control group name contains a template in destination tag (see cgrules.conf (5)) and if the cgroup does not exist in execution time, it is created, based on /etc/cgconfig.conf specification.  If the specifications are not present the group is created with the default kernel values.
-h, --help Display this help and exit.
--sticky If running the task command with this option, the daemon of service cgred (cgrulesengd process) does not change both the task of the command and the child tasks. Without this option, the daemon does not change the task of the command but it changes the child tasks to the right cgroup based on /etc/cgrules.conf automatically.
cgexec -g *:test1 ls runs command ls in control group test1 in all mounted controllers.
cgexec -g cpu,memory:test1 ls -l runs command ls -l in control group test1 in controllers cpu and memory.
cgexec -g cpu,memory:test1 -g swap:test2 ls -l runs command ls -l in control group test1 in controllers cpu and memory and control group test2 in controller swap.
CGROUP_LOGLEVEL controls verbosity of the tool. Allowed values are DEBUG, INFO, WARNING or ERROR.
/etc/cgrules.conf default libcgroup configuration file
cgrules.conf (5)
inotifywait(1)               General Commands Manual              inotifywait(1)
inotifywait, fsnotifywait - wait for changes to files using inotify or fanotify
inotifywait [-hcmrPq] [-e <event> ] [-t <seconds> ] [--format <fmt> ] [--timefmt <fmt> ] <file> [ ... ]
fsnotifywait [-hcmrPqIFS] [-e <event> ] [-t <seconds> ] [--format <fmt> ] [--timefmt <fmt> ] <file> [ ... ]
inotifywait efficiently waits for changes to files using Linux's inotify(7) interface.  It is suitable for waiting for changes to files from shell scripts.  It can either exit once an event occurs, or continually execute and output events as they occur.
fsnotifywait is similar to inotifywait but it is using Linux's fanotify(7) interface by default. If explicitly specified, it uses the inotify(7) interface.
inotifywait and fsnotifywait will output diagnostic information on standard error and event information on standard output.  The event output can be configured, but by default it consists of lines of the following form:
watched_filename EVENT_NAMES event_filename
watched_filename is the name of the file on which the event occurred.  If the file is a directory, a trailing slash is output.
EVENT_NAMES are the names of the inotify events which occurred, separated by commas.
event_filename is output only when the event occurred on a directory, and in this case the name of the file within the directory which caused this event is output.
By default, any special characters in filenames are not escaped in any way.  This can make the output of inotifywait difficult to parse in awk scripts or similar.  The --csv and --format options will be helpful in this case.
-h, --help Output some helpful usage information.
@<file> When watching a directory tree recursively, exclude the specified file from being watched.  The file must be specified with a relative or absolute path according to whether a relative or absolute path is given for watched directories.  If a specific path is explicitly both included and excluded, it will always be watched.
Note: If you need to watch a directory or file whose name starts with @, give the absolute path.
--fromfile <file> Read filenames to watch or exclude from a file, one filename per line.  If filenames begin with @ they are excluded as described above.  If <file> is `-', filenames are read from standard input. Use this option if you need to watch too many files to pass in as command line arguments.
-m, --monitor Instead of exiting after receiving a single event, execute indefinitely.  The default behaviour is to exit after the first event occurs.
-d, --daemon Same as --monitor, except run in the background logging events to a file that must be specified by --outfile. Implies --syslog.
-o, --outfile <file> Output events to <file> rather than stdout.
-s, --syslog Output errors to syslog(3) system log module rather than stderr.
-P, --no-dereference Do not follow symlinks.
-r, --recursive Watch all subdirectories of any directories passed as arguments. Watches will be set up recursively to an unlimited depth. Symbolic links are not traversed.  Newly created subdirectories will also be watched.
Warning: If you use this option while watching the root directory of a large tree, it may take quite a while until all inotify watches are established, and events will not be received in this time.  Also, since one inotify watch will be established per subdirectory, it is possible that the maximum amount of inotify watches per user will be reached.  The default maximum is 8192; it can be increased by writing to /proc/sys/fs/inotify/max_user_watches.
-q, --quiet If specified once, the program will be less verbose. Specifically, it will not state when it has completed establishing all inotify watches.
If specified twice, the program will output nothing at all, except in the case of fatal errors.
--exclude <pattern> Do not process any events for the subset of files whose filenames match the specified POSIX regular expression, case sensitive.
--excludei <pattern> Do not process any events for the subset of files whose filenames match the specified POSIX regular expression, case insensitive.
--include <pattern> Process events only for the subset of files whose filenames match the specified POSIX regular expression, case sensitive.
--includei <pattern> Process events only for the subset of files whose filenames match the specified POSIX regular expression, case insensitive.
-t <seconds>, --timeout <seconds> Exit if an appropriate event has not occurred within <seconds> seconds. If <seconds> is zero (the default), wait indefinitely for an event.
-e <event>, --event <event> Listen for specific event(s) only.  The events which can be listened for are listed in the EVENTS section.  This option can be specified more than once.  If omitted, all events are listened for.
-c, --csv Output in CSV (comma-separated values) format.  This is useful when filenames may contain spaces, since in this case it is not safe to simply split the output at each space character.
--timefmt <fmt> Set a time format string as accepted by strftime(3) for use with the `%T' conversion in the --format option.
--no-newline Don't print newline symbol after user-specified format in the --format option.
--format <fmt> Output in a user-specified format, using printf-like syntax.  The event strings output are limited to around 4000 characters and will be truncated to this length.  The following conversions are supported:
%w     This will be replaced with the name of the Watched file on which an event occurred.
%f     When an event occurs within a directory, this will be replaced with the name of the File which caused the event to occur. Otherwise, this will be replaced with an empty string.
%e     Replaced with the Event(s) which occurred, comma-separated.
%Xe    Replaced with the Event(s) which occurred, separated by whichever character is in the place of `X'.
%T     Replaced with the current Time in the format specified by the --timefmt option, which should be a format string suitable for passing to strftime(3).
%0     Replaced with NUL.
%n     Replaced with Line Feed.
fsnotifywait The following additional options are available:
-I, --inotify Watch using inotify.
-F, --fanotify Watch using fanotify (default).  fanotify support for reporting events with inotify compatible information was added in kernel v5.9.  With older kernels the command will fail.  As of kernel v5.12, fanotify requires admin privileges.
-S, --filesystem Watch entire filesystem of any directories passed as arguments using fanotify.
0      The program executed successfully, and an event occurred which was being listened for.
1      An error occurred in execution of the program, or an event occurred which was not being listened for.  The latter generally occurs if something happens which forcibly removes the inotify watch, such as a watched file being deleted or the filesystem containing a watched file being unmounted.
2      The -t option was used and an event did not occur in the specified interval of time.
The following events are valid for use with the -e option:
access A watched file or a file within a watched directory was read from.
modify A watched file or a file within a watched directory was written to.
attrib The metadata of a watched file or a file within a watched directory was modified.  This includes timestamps, file permissions, extended attributes etc.
close_write A watched file or a file within a watched directory was closed, after being opened in writable mode.  This does not necessarily imply the file was written to.
close_nowrite A watched file or a file within a watched directory was closed, after being opened in read-only mode.
close  A watched file or a file within a watched directory was closed, regardless of how it was opened.  Note that this is actually implemented simply by listening for both close_write and close_nowrite, hence all close events received will be output as one of these, not CLOSE.
open   A watched file or a file within a watched directory was opened.
moved_to A file or directory was moved into a watched directory.  This event occurs even if the file is simply moved from and to the same directory.
moved_from A file or directory was moved from a watched directory.  This event occurs even if the file is simply moved from and to the same directory.
move   A file or directory was moved from or to a watched directory. Note that this is actually implemented simply by listening for both moved_to and moved_from, hence all move events received will be output as one or both of these, not MOVE.
move_self A watched file or directory was moved. After this event, the file or directory is no longer being watched.
create A file or directory was created within a watched directory.
delete A file or directory within a watched directory was deleted.
delete_self A watched file or directory was deleted.  After this event the file or directory is no longer being watched.  Note that this event can occur even if it is not explicitly being listened for.
unmount The filesystem on which a watched file or directory resides was unmounted.  After this event the file or directory is no longer being watched.  Note that this event can occur even if it is not explicitly being listened to.
Example 1 Running inotifywait at the command-line to wait for any file in the `test' directory to be accessed.  After running inotifywait, `cat test/foo' is run in a separate console.
% inotifywait test Setting up watches. Watches established. test/ ACCESS foo
Example 2 A short shell script to efficiently wait for httpd-related log messages and do something appropriate.
#!/bin/sh while ! inotifywait -e modify /var/log/messages; do if tail -n1 /var/log/messages | grep httpd; then kdialog --msgbox "Apache needs love!" fi done
Example 3 A custom output format is used to watch `~/test'.  Meanwhile, someone runs `touch ~/test/badfile; touch ~/test/goodfile; rm ~/test/badfile' in another console.
% inotifywait -m -r --format '%:e %f' ~/test Setting up watches.  Beware: since -r was given, this may take a while! Watches established. CREATE badfile OPEN badfile ATTRIB badfile CLOSE_WRITE:CLOSE badfile CREATE goodfile OPEN goodfile ATTRIB goodfile CLOSE_WRITE:CLOSE goodfile DELETE badfile
Example 4 Enforce file permissions in directory `~/test'
inotifywait -qmr -e 'moved_to,create' --format '%w%f%0' --no-newline ~/test |\ while IFS= read -r -d '' file do chmod -v a+rX "$file" done
When using inotifywait, the filename that is outputted is not guaranteed to be up to date after a move because it is the inode that is being monitored. Additionally, none of the observed operations are guaranteed to have been performed on the filename inotifywait was instructed to monitor in cases when the file is known by several names in the filesystem.
There are race conditions in the recursive directory watching code which can cause events to be missed if they occur in a directory immediately after that directory is created.  This is probably not fixable.
It is assumed the inotify event queue will never overflow.
inotifywait was started by Rohan McGovern, and is currently maintained by Eric Curtin and Radu Voicilas.  https://www.openhub.net/p/inotify- tools/contributors/summary gives you a more complete list of contributors.
inotifywait is part of inotify-tools.  The inotify-tools website is located at: https://github.com/inotify-tools/inotify-tools/wiki
inotifywatch(1), strftime(3), inotify(7)
GPG(1)                        GNU Privacy Guard 2.2                       GPG(1)
gpg - OpenPGP encryption and signing tool
gpg [--homedir dir] [--options file] [options] command [args]
gpg is the OpenPGP part of the GNU Privacy Guard (GnuPG). It is a tool to provide digital encryption and signing services using the OpenPGP standard. gpg features complete key management and all the bells and whistles you would expect from a full OpenPGP implementation.
There are two main versions of GnuPG: GnuPG 1.x and GnuPG 2.x.  GnuPG 2.x supports modern encryption algorithms and thus should be preferred over GnuPG 1.x.  You only need to use GnuPG 1.x if your platform doesn't support GnuPG 2.x, or you need support for some features that GnuPG 2.x has deprecated, e.g., decrypting data created with PGP-2 keys.
If you are looking for version 1 of GnuPG, you may find that version installed under the name gpg1.
The program returns 0 if there are no severe errors, 1 if at least a signature was bad, and other error codes for fatal errors.
Note that signature verification requires exact knowledge of what has been signed and by whom it has beensigned.  Using only the return code is thus not an appropriate way to verify a signature by a script.  Either make proper use or the status codes or use the gpgv tool which has been designed to make signature verification easy for scripts.
Use a good password for your user account and make sure that all security issues are always fixed on your machine.  Also employ diligent physical protection to your machine.  Consider to use a good passphrase as a last resort protection to your secret key in the case your machine gets stolen.  It is important that your secret key is never leaked.  Using an easy to carry around token or smartcard with the secret key is often a advisable.
If you are going to verify detached signatures, make sure that the program knows about it; either give both filenames on the command line or use ‘-’ to specify STDIN.
For scripted or other unattended use of gpg make sure to use the machine- parseable interface and not the default interface which is intended for direct use by humans.  The machine-parseable interface provides a stable and well documented API independent of the locale or future changes of gpg.  To enable this interface use the options --with-colons and --status-fd.  For certain operations the option --command-fd may come handy too.  See this man page and the file ‘DETAILS’ for the specification of the interface.  Note that the GnuPG ``info'' pages as well as the PDF version of the GnuPG manual features a chapter on unattended use of GnuPG.  As an alternative the library GPGME can be used as a high-level abstraction on top of that interface.
GnuPG tries to be a very flexible implementation of the OpenPGP standard. In particular, GnuPG implements many of the optional parts of the standard, such as the SHA-512 hash, and the ZLIB and BZIP2 compression algorithms. It is important to be aware that not all OpenPGP programs implement these optional algorithms and that by forcing their use via the --cipher-algo, --digest-algo, --cert-digest-algo, or --compress-algo options in GnuPG, it is possible to create a perfectly valid OpenPGP message, but one that cannot be read by the intended recipient.
There are dozens of variations of OpenPGP programs available, and each supports a slightly different subset of these optional algorithms.  For example, until recently, no (unhacked) version of PGP supported the BLOWFISH cipher algorithm. A message using BLOWFISH simply could not be read by a PGP user. By default, GnuPG uses the standard OpenPGP preferences system that will always do the right thing and create messages that are usable by all recipients, regardless of which OpenPGP program they use. Only override this safe default if you really know what you are doing.
If you absolutely must override the safe default, or if the preferences on a given key are invalid for some reason, you are far better off using the --pgp6, --pgp7, or --pgp8 options. These options are safe as they do not force any particular algorithms in violation of OpenPGP, but rather reduce the available algorithms to a "PGP-safe" list.
Commands are not distinguished from options except for the fact that only one command is allowed.  Generally speaking, irrelevant options are silently ignored, and may not be checked for correctness.
gpg may be run with no commands. In this case it will print a warning perform a reasonable action depending on the type of file it is given as input (an encrypted message is decrypted, a signature is verified, a file containing keys is listed, etc.).
If you run into any problems, please add the option --verbose to the invocation to see more diagnostics.
Commands not specific to the function
--version Print the program version and licensing information.  Note that you cannot abbreviate this command.
--help -h     Print a usage message summarizing the most useful command-line options.  Note that you cannot arbitrarily abbreviate this command (though you can use its short form -h).
--warranty Print warranty information.
--dump-options Print a list of all available options and commands.  Note that you cannot abbreviate this command.
Commands to select the type of operation
--sign -s     Sign a message. This command may be combined with --encrypt (to sign and encrypt a message), --symmetric (to sign and symmetrically encrypt a message), or both --encrypt and --symmetric (to sign and encrypt a message that can be decrypted using a secret key or a passphrase).  The signing key is chosen by default or can be set explicitly using the --local-user and --default-key options.
--clear-sign --clearsign Make a cleartext signature.  The content in a cleartext signature is readable without any special software. OpenPGP software is only needed to verify the signature.  cleartext signatures may modify end-of-line whitespace for platform independence and are not intended to be reversible.  The signing key is chosen by default or can be set explicitly using the --local-user and --default-key options.
--detach-sign -b     Make a detached signature.
--encrypt -e     Encrypt data to one or more public keys. This command may be combined with --sign (to sign and encrypt a message), --symmetric (to encrypt a message that can be decrypted using a secret key or a passphrase), or --sign and --symmetric together (for a signed message that can be decrypted using a secret key or a passphrase). --recipient and related options specify which public keys to use for encryption.
--symmetric -c     Encrypt with a symmetric cipher using a passphrase. The default symmetric cipher used is AES-128, but may be chosen with the --cipher-algo option. This command may be combined with --sign (for a signed and symmetrically encrypted message), --encrypt (for a message that may be decrypted via a secret key or a passphrase), or --sign and --encrypt together (for a signed message that may be decrypted via a secret key or a passphrase).  gpg caches the passphrase used for symmetric encryption so that a decrypt operation may not require that the user needs to enter the passphrase.  The option --no-symkey-cache can be used to disable this feature.
--store Store only (make a simple literal data packet).
--decrypt -d     Decrypt the file given on the command line (or STDIN if no file is specified) and write it to STDOUT (or the file specified with --output). If the decrypted file is signed, the signature is also verified. This command differs from the default operation, as it never writes to the filename which is included in the file and it rejects files that don't begin with an encrypted message.
--verify Assume that the first argument is a signed file and verify it without generating any output.  With no arguments, the signature packet is read from STDIN.  If only one argument is given, the specified file is expected to include a complete signature.
With more than one argument, the first argument should specify a file with a detached signature and the remaining files should contain the signed data. To read the signed data from STDIN, use ‘-’ as the second filename.  For security reasons, a detached signature will not read the signed material from STDIN if not explicitly specified.
Note: If the option --batch is not used, gpg may assume that a single argument is a file with a detached signature, and it will try to find a matching data file by stripping certain suffixes. Using this historical feature to verify a detached signature is strongly discouraged; you should always specify the data file explicitly.
Note: When verifying a cleartext signature, gpg verifies only what makes up the cleartext signed data and not any extra data outside of the cleartext signature or the header lines directly following the dash marker line.  The option --output may be used to write out the actual signed data, but there are other pitfalls with this format as well.  It is suggested to avoid cleartext signatures in favor of detached signatures.
Note: Sometimes the use of the gpgv tool is easier than using the full-fledged gpg with this option.  gpgv is designed to compare signed data against a list of trusted keys and returns with success only for a good signature.  It has its own manual page.
--multifile This modifies certain other commands to accept multiple files for processing on the command line or read from STDIN with each filename on a separate line. This allows for many files to be processed at once. --multifile may currently be used along with --verify, --encrypt, and --decrypt. Note that --multifile --verify may not be used with detached signatures.
--verify-files Identical to --multifile --verify.
--encrypt-files Identical to --multifile --encrypt.
--decrypt-files Identical to --multifile --decrypt.
--list-keys -k --list-public-keys List the specified keys.  If no keys are specified, then all keys from the configured public keyrings are listed.
Never use the output of this command in scripts or other programs. The output is intended only for humans and its format is likely to change.  The --with-colons option emits the output in a stable, machine-parseable format, which is intended for use by scripts and other programs.
--list-secret-keys -K     List the specified secret keys.  If no keys are specified, then all known secret keys are listed.  A # after the initial tags sec or ssb means that the secret key or subkey is currently not usable.  We also say that this key has been taken offline (for example, a primary key can be taken offline by exporting the key using the command --export-secret-subkeys).  A > after these tags indicate that the key is stored on a smartcard.  See also --list- keys.
--check-signatures --check-sigs Same as --list-keys, but the key signatures are verified and listed too.  Note that for performance reasons the revocation status of a signing key is not shown.  This command has the same effect as using --list-keys with --with-sig-check.
The status of the verification is indicated by a flag directly following the "sig" tag (and thus before the flags described below.  A "!" indicates that the signature has been successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported algorithm).  Signatures where the public key is not available are not listed; to see their keyids the command --list-sigs can be used.
For each signature listed, there are several flags in between the signature status flag and keyid.  These flags give additional information about each key signature.  From left to right, they are the numbers 1-3 for certificate check level (see --ask-cert- level), "L" for a local or non-exportable signature (see --lsign- key), "R" for a nonRevocable signature (see the --edit-key command "nrsign"), "P" for a signature that contains a policy URL (see --cert-policy-url), "N" for a signature that contains a notation (see --cert-notation), "X" for an eXpired signature (see --ask- cert-expire), and the numbers 1-9 or "T" for 10 and above to indicate trust signature levels (see the --edit-key command "tsign").
--locate-keys --locate-external-keys Locate the keys given as arguments.  This command basically uses the same algorithm as used when locating keys for encryption and may thus be used to see what keys gpg might use.  In particular external methods as defined by --auto-key-locate are used to locate a key if the arguments comain valid mail addresses.  Only public keys are listed.
The variant --locate-external-keys does not consider a locally existing key and can thus be used to force the refresh of a key via the defined external methods.  If a fingerprint is given and and the methods defined by --auto-key-locate define LDAP servers, the key is fetched from these resources; defined non-LDAP keyservers are skipped.
--show-keys This commands takes OpenPGP keys as input and prints information about them in the same way the command --list-keys does for locally stored key.  In addition the list options show-unusable- uids, show-unusable-subkeys, show-notations and show-policy-urls are also enabled.  As usual for automated processing, this command should be combined with the option --with-colons.
--fingerprint List all keys (or the specified ones) along with their fingerprints. This is the same output as --list-keys but with the additional output of a line with the fingerprint. May also be combined with --check-signatures.  If this command is given twice, the fingerprints of all secondary keys are listed too.  This command also forces pretty printing of fingerprints if the keyid format has been set to "none".
--list-packets List only the sequence of packets.  This command is only useful for debugging.  When used with option --verbose the actual MPI values are dumped and not only their lengths.  Note that the output of this command may change with new releases.
--edit-card --card-edit Present a menu to work with a smartcard. The subcommand "help" provides an overview on available commands. For a detailed description, please see the Card HOWTO at https://gnupg.org/documentation/howtos.html#GnuPG-cardHOWTO .
--card-status Show the content of the smart card.
--change-pin Present a menu to allow changing the PIN of a smartcard. This functionality is also available as the subcommand "passwd" with the --edit-card command.
--delete-keys name Remove key from the public keyring. In batch mode either --yes is required or the key must be specified by fingerprint. This is a safeguard against accidental deletion of multiple keys.  If the exclamation mark syntax is used with the fingerprint of a subkey only that subkey is deleted; if the exclamation mark is used with the fingerprint of the primary key the entire public key is deleted.
--delete-secret-keys name Remove key from the secret keyring. In batch mode the key must be specified by fingerprint.  The option --yes can be used to advise gpg-agent not to request a confirmation.  This extra pre-caution is done because gpg can't be sure that the secret key (as controlled by gpg-agent) is only used for the given OpenPGP public key.  If the exclamation mark syntax is used with the fingerprint of a subkey only the secret part of that subkey is deleted; if the exclamation mark is used with the fingerprint of the primary key only the secret part of the primary key is deleted.
--delete-secret-and-public-key name Same as --delete-key, but if a secret key exists, it will be removed first. In batch mode the key must be specified by fingerprint.  The option --yes can be used to advise gpg-agent not to request a confirmation.
--export Either export all keys from all keyrings (default keyring and those registered via option --keyring), or if at least one name is given, those of the given name. The exported keys are written to STDOUT or to the file given with option --output.  Use together with --armor to mail those keys.
--send-keys keyIDs Similar to --export but sends the keys to a keyserver. Fingerprints may be used instead of key IDs.  Don't send your complete keyring to a keyserver --- select only those keys which are new or changed by you.  If no keyIDs are given, gpg does nothing.
Take care: Keyservers are by design write only systems and thus it is not possible to ever delete keys once they have been send to a keyserver.
--export-secret-keys --export-secret-subkeys Same as --export, but exports the secret keys instead.  The exported keys are written to STDOUT or to the file given with option --output.  This command is often used along with the option --armor to allow for easy printing of the key for paper backup; however the external tool paperkey does a better job of creating backups on paper.  Note that exporting a secret key can be a security risk if the exported keys are sent over an insecure channel.
The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successfully import such a key.  Its intended use is in generating a full key with an additional signing subkey on a dedicated machine.  This command then exports the key without the primary key to the main machine.
GnuPG may ask you to enter the passphrase for the key.  This is required, because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol.
--export-ssh-key This command is used to export a key in the OpenSSH public key format.  It requires the specification of one key by the usual means and exports the latest valid subkey which has an authentication capability to STDOUT or to the file given with option --output.  That output can directly be added to ssh's ‘authorized_key’ file.
By specifying the key to export using a key ID or a fingerprint suffixed with an exclamation mark (!), a specific subkey or the primary key can be exported.  This does not even require that the key has the authentication capability flag set.
--import --fast-import Import/merge keys. This adds the given keys to the keyring. The fast version is currently just a synonym.
There are a few other options which control how this command works.  Most notable here is the --import-options merge-only option which does not insert new keys but does only the merging of new signatures, user-IDs and subkeys.
--receive-keys keyIDs --recv-keys keyIDs Import the keys with the given keyIDs from a keyserver.
--refresh-keys Request updates from a keyserver for keys that already exist on the local keyring. This is useful for updating a key with the latest signatures, user IDs, etc. Calling this with no arguments will refresh the entire keyring.
--search-keys names Search the keyserver for the given names. Multiple names given here will be joined together to create the search string for the keyserver.  Note that keyservers search for names in a different and simpler way than gpg does.  The best choice is to use a mail address.  Due to data privacy reasons keyservers may even not even allow searching by user id or mail address and thus may only return results when being used with the --recv-key command to search by key fingerprint or keyid.
--fetch-keys URIs Retrieve keys located at the specified URIs. Note that different installations of GnuPG may support different protocols (HTTP, FTP, LDAP, etc.).  When using HTTPS the system provided root certificates are used by this command.
--update-trustdb Do trust database maintenance. This command iterates over all keys and builds the Web of Trust. This is an interactive command because it may have to ask for the "ownertrust" values for keys. The user has to give an estimation of how far she trusts the owner of the displayed key to correctly certify (sign) other keys. GnuPG only asks for the ownertrust value if it has not yet been assigned to a key. Using the --edit-key menu, the assigned value can be changed at any time.
--check-trustdb Do trust database maintenance without user interaction. From time to time the trust database must be updated so that expired keys or signatures and the resulting changes in the Web of Trust can be tracked. Normally, GnuPG will calculate when this is required and do it automatically unless --no-auto-check-trustdb is set. This command can be used to force a trust database check at any time. The processing is identical to that of --update-trustdb but it skips keys with a not yet defined "ownertrust".
For use with cron jobs, this command can be used together with --batch in which case the trust database check is done only if a check is needed. To force a run even in batch mode add the option --yes.
--export-ownertrust Send the ownertrust values to STDOUT. This is useful for backup purposes as these values are the only ones which can't be re- created from a corrupted trustdb.  Example: gpg --export-ownertrust > otrust.txt
--import-ownertrust Update the trustdb with the ownertrust values stored in files (or STDIN if not given); existing values will be overwritten.  In case of a severely damaged trustdb and if you have a recent backup of the ownertrust values (e.g. in the file ‘otrust.txt’), you may re- create the trustdb using these commands: cd ~/.gnupg rm trustdb.gpg gpg --import-ownertrust < otrust.txt
--rebuild-keydb-caches When updating from version 1.0.6 to 1.0.7 this command should be used to create signature caches in the keyring. It might be handy in other situations too.
--print-md algo --print-mds Print message digest of algorithm algo for all given files or STDIN.  With the second form (or a deprecated "*" for algo) digests for all available algorithms are printed.
--gen-random 0|1|2 count Emit count random bytes of the given quality level 0, 1 or 2. If count is not given or zero, an endless sequence of random bytes will be emitted.  If used with --armor the output will be base64 encoded.  PLEASE, don't use this command unless you know what you are doing; it may remove precious entropy from the system!
--gen-prime mode bits Use the source, Luke :-). The output format is subject to change with ant release.
--enarmor --dearmor Pack or unpack an arbitrary input into/from an OpenPGP ASCII armor.  This is a GnuPG extension to OpenPGP and in general not very useful.
--tofu-policy {auto|good|unknown|bad|ask} keys Set the TOFU policy for all the bindings associated with the specified keys.  For more information about the meaning of the policies, see: [trust-model-tofu].  The keys may be specified either by their fingerprint (preferred) or their keyid.
How to manage your keys
This section explains the main commands for key management.
--quick-generate-key user-id [algo [usage [expire]]] --quick-gen-key This is a simple command to generate a standard key with one user id.  In contrast to --generate-key the key is generated directly without the need to answer a bunch of prompts.  Unless the option --yes is given, the key creation will be canceled if the given user id already exists in the keyring.
If invoked directly on the console without any special options an answer to a ``Continue?'' style confirmation prompt is required. In case the user id already exists in the keyring a second prompt to force the creation of the key will show up.
If algo or usage are given, only the primary key is created and no prompts are shown.  To specify an expiration date but still create a primary and subkey use ``default'' or ``future-default'' for algo and ``default'' for usage.  For a description of these optional arguments see the command --quick-add-key.  The usage accepts also the value ``cert'' which can be used to create a certification only primary key; the default is to a create certification and signing key.
The expire argument can be used to specify an expiration date for the key.  Several formats are supported; commonly the ISO formats ``YYYY-MM-DD'' or ``YYYYMMDDThhmmss'' are used.  To make the key expire in N seconds, N days, N weeks, N months, or N years use ``seconds=N'', ``Nd'', ``Nw'', ``Nm'', or ``Ny'' respectively. Not specifying a value, or using ``-'' results in a key expiring in a reasonable default interval.  The values ``never'', ``none'' can be used for no expiration date.
If this command is used with --batch, --pinentry-mode has been set to loopback, and one of the passphrase options (--passphrase, --passphrase-fd, or --passphrase-file) is used, the supplied passphrase is used for the new key and the agent does not ask for it.  To create a key without any protection --passphrase '' may be used.
To create an OpenPGP key from the keys available on the currently inserted smartcard, the special string ``card'' can be used for algo.  If the card features an encryption and a signing key, gpg will figure them out and creates an OpenPGP key consisting of the usual primary key and one subkey.  This works only with certain smartcards.  Note that the interactive --full-gen-key command allows to do the same but with greater flexibility in the selection of the smartcard keys.
Note that it is possible to create a primary key and a subkey using non-default algorithms by using ``default'' and changing the default parameters using the option --default-new-key-algo.
--quick-set-expire fpr expire [*|subfprs] With two arguments given, directly set the expiration time of the primary key identified by fpr to expire.  To remove the expiration time 0 can be used.  With three arguments and the third given as an asterisk, the expiration time of all non-revoked and not yet expired subkeys are set to expire.  With more than two arguments and a list of fingerprints given for subfprs, all non-revoked subkeys matching these fingerprints are set to expire.
--quick-add-key fpr [algo [usage [expire]]] Directly add a subkey to the key identified by the fingerprint fpr.  Without the optional arguments an encryption subkey is added.  If any of the arguments are given a more specific subkey is added.
algo may be any of the supported algorithms or curve names given in the format as used by key listings.  To use the default algorithm the string ``default'' or ``-'' can be used.  Supported algorithms are ``rsa'', ``dsa'', ``elg'', ``ed25519'', ``cv25519'', and other ECC curves.  For example the string ``rsa'' adds an RSA key with the default key length; a string ``rsa4096'' requests that the key length is 4096 bits.  The string ``future- default'' is an alias for the algorithm which will likely be used as default algorithm in future versions of gpg.  To list the supported ECC curves the command gpg --with-colons --list-config curve can be used.