neulab/tldr huggingface dataset:
-data file_to_hash The response or token must be verified against file_to_hash. The file is hashed with the message digest algorithm specified in the token. The -digest and -queryfile options must not be specified with this one.  (Optional)
-digest digest_bytes The response or token must be verified against the message digest specified with this option. The number of bytes must match the message digest algorithm specified in the token. The -data and -queryfile options must not be specified with this one. (Optional)
-queryfile request.tsq The original timestamp request in DER format. The -data and -digest options must not be specified with this one. (Optional)
-in response.tsr The timestamp response that needs to be verified in DER format. (Mandatory)
-CApath trusted_cert_path The name of the directory containing the trusted CA certificates of the client. See the similar option of verify(1) for additional details. Either this option or -CAfile must be specified. (Optional)
-CAfile trusted_certs.pem The name of the file containing a set of trusted self-signed CA certificates in PEM format. See the similar option of verify(1) for additional details. Either this option or -CApath must be specified. (Optional)
-untrusted cert_file.pem Set of additional untrusted certificates in PEM format which may be needed when building the certificate chain for the TSA's signing certificate. This file must contain the TSA signing certificate and all intermediate CA certificates unless the response includes them. (Optional)
verify options The options -attime timestamp, -check_ss_sig, -crl_check, -crl_check_all, -explicit_policy, -extended_crl, -ignore_critical, -inhibit_any, -inhibit_map, -issuer_checks, -no_alt_chains, -no_check_time, -partial_chain, -policy, -policy_check, -policy_print, -purpose, -suiteB_128, -suiteB_128_only, -suiteB_192, -trusted_first, -use_deltas, -auth_level, -verify_depth, -verify_email, -verify_hostname, -verify_ip, -verify_name, and -x509_strict can be used to control timestamp verification.  See verify(1).
The -query and -reply commands make use of a configuration file.  See config(5) for a general description of the syntax of the config file. The -query command uses only the symbolic OID names section and it can work without it. However, the -reply command needs the config file for its operation.
When there is a command line switch equivalent of a variable the switch always overrides the settings in the config file.
tsa section, default_tsa This is the main section and it specifies the name of another section that contains all the options for the -reply command. This default section can be overridden with the -section command line switch. (Optional)
oid_file See ca(1) for description. (Optional)
oid_section See ca(1) for description. (Optional)
RANDFILE See ca(1) for description. (Optional)
serial The name of the file containing the hexadecimal serial number of the last timestamp response created. This number is incremented by 1 for each response. If the file does not exist at the time of response generation a new file is created with serial number 1. (Mandatory)
crypto_device Specifies the OpenSSL engine that will be set as the default for all available algorithms. The default value is builtin, you can specify any other engines supported by OpenSSL (e.g. use chil for the NCipher HSM).  (Optional)
signer_cert TSA signing certificate in PEM format. The same as the -signer command line option. (Optional)
certs A file containing a set of PEM encoded certificates that need to be included in the response. The same as the -chain command line option. (Optional)
signer_key The private key of the TSA in PEM format. The same as the -inkey command line option. (Optional)
signer_digest Signing digest to use. The same as the -digest command line option. (Mandatory unless specified on the command line)
default_policy The default policy to use when the request does not mandate any policy. The same as the -tspolicy command line option. (Optional)
other_policies Comma separated list of policies that are also acceptable by the TSA and used only if the request explicitly specifies one of them. (Optional)
digests The list of message digest algorithms that the TSA accepts. At least one algorithm must be specified. (Mandatory)
accuracy The accuracy of the time source of the TSA in seconds, milliseconds and microseconds. E.g. secs:1, millisecs:500, microsecs:100. If any of the components is missing zero is assumed for that field. (Optional)
clock_precision_digits Specifies the maximum number of digits, which represent the fraction of seconds, that  need to be included in the time field. The trailing zeros must be removed from the time, so there might actually be fewer digits, or no fraction of seconds at all. Supported only on UNIX platforms.  The maximum value is 6, default is 0.  (Optional)
ordering If this option is yes the responses generated by this TSA can always be ordered, even if the time difference between two responses is less than the sum of their accuracies. Default is no. (Optional)
tsa_name Set this option to yes if the subject name of the TSA must be included in the TSA name field of the response. Default is no. (Optional)
ess_cert_id_chain The SignedData objects created by the TSA always contain the certificate identifier of the signing certificate in a signed attribute (see RFC 2634, Enhanced Security Services). If this option is set to yes and either the certs variable or the -chain option is specified then the certificate identifiers of the chain will also be included in the SigningCertificate signed attribute. If this variable is set to no, only the signing certificate identifier is included. Default is no. (Optional)
ess_cert_id_alg This option specifies the hash function to be used to calculate the TSA's public key certificate identifier. Default is sha1. (Optional)
All the examples below presume that OPENSSL_CONF is set to a proper configuration file, e.g. the example configuration file openssl/apps/openssl.cnf will do.
Time Stamp Request To create a timestamp request for design1.txt with SHA-1 without nonce and policy and no certificate is required in the response:
openssl ts -query -data design1.txt -no_nonce \ -out design1.tsq
To create a similar timestamp request with specifying the message imprint explicitly:
openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \ -no_nonce -out design1.tsq
To print the content of the previous request in human readable format:
openssl ts -query -in design1.tsq -text
To create a timestamp request which includes the MD-5 digest of design2.txt, requests the signer certificate and nonce, specifies a policy id (assuming the tsa_policy1 name is defined in the OID section of the config file):
openssl ts -query -data design2.txt -md5 \ -tspolicy tsa_policy1 -cert -out design2.tsq
Time Stamp Response Before generating a response a signing certificate must be created for the TSA that contains the timeStamping critical extended key usage extension without any other key usage extensions. You can add this line to the user certificate section of the config file to generate a proper certificate;
extendedKeyUsage = critical,timeStamping
See req(1), ca(1), and x509(1) for instructions. The examples below assume that cacert.pem contains the certificate of the CA, tsacert.pem is the signing certificate issued by cacert.pem and tsakey.pem is the private key of the TSA.
To create a timestamp response for a request:
openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \ -signer tsacert.pem -out design1.tsr
If you want to use the settings in the config file you could just write:
openssl ts -reply -queryfile design1.tsq -out design1.tsr
To print a timestamp reply to stdout in human readable format:
openssl ts -reply -in design1.tsr -text
To create a timestamp token instead of timestamp response:
openssl ts -reply -queryfile design1.tsq -out design1_token.der -token_out
To print a timestamp token to stdout in human readable format:
openssl ts -reply -in design1_token.der -token_in -text -token_out
To extract the timestamp token from a response:
openssl ts -reply -in design1.tsr -out design1_token.der -token_out
To add 'granted' status info to a timestamp token thereby creating a valid response:
openssl ts -reply -in design1_token.der -token_in -out design1.tsr
Time Stamp Verification To verify a timestamp reply against a request:
openssl ts -verify -queryfile design1.tsq -in design1.tsr \ -CAfile cacert.pem -untrusted tsacert.pem
To verify a timestamp reply that includes the certificate chain:
openssl ts -verify -queryfile design2.tsq -in design2.tsr \ -CAfile cacert.pem
To verify a timestamp token against the original data file: openssl ts -verify -data design2.txt -in design2.tsr \ -CAfile cacert.pem
To verify a timestamp token against a message imprint: openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \ -in design2.tsr -CAfile cacert.pem
You could also look at the 'test' directory for more examples.
• No support for timestamps over SMTP, though it is quite easy to implement an automatic e-mail based TSA with procmail(1) and perl(1). HTTP server support is provided in the form of a separate apache module. HTTP client support is provided by tsget(1). Pure TCP/IP protocol is not supported.
• The file containing the last serial number of the TSA is not locked when being read or written. This is a problem if more than one instance of openssl(1) is trying to create a timestamp response at the same time. This is not an issue when using the apache server module, it does proper locking.
• Look for the FIXME word in the source files.
• The source code should really be reviewed by somebody else, too.
• More testing is needed, I have done only some basic tests (see test/testtsa).
tsget(1), openssl(1), req(1), x509(1), ca(1), genrsa(1), config(5)
Copyright 2006-2021 The OpenSSL Project Authors. All Rights Reserved.
FAKETIME(1)                          wolfcw                          FAKETIME(1)
faketime - manipulate the system time for a given command
faketime [options] timestamp program [arguments...]
The given command will be tricked into believing that the current system time is the one specified in the timestamp. Filesystem timestamps will also be reported relative to this timestamp. The wall clock will continue to run from this date and time unless specified otherwise (see advanced options).  Actually, faketime is a simple wrapper for libfaketime, which uses the LD_PRELOAD mechanism to load a small library which intercepts system calls to functions such as time(2) and fstat(2). This wrapper exposes only a subset of libfaketime's functionality; please refer to the README file that came with faketime for more details and advanced options, or have a look at http://github.com/wolfcw/libfaketime
--help show usage information and quit.
--version show version information and quit.
-m     use the multi-threading variant of libfaketime.
-f     use the advanced timestamp specification format.
--exclude-monotonic Do not fake time when the program makes a call to clock_gettime with a CLOCK_MONOTONIC clock.
faketime 'last Friday 5 pm' /bin/date faketime '2008-12-24 08:15:42' /bin/date faketime -f '+2,5y x10,0' /bin/bash -c 'date; while true; do echo $SECONDS ; sleep 1 ; done' faketime -f '+2,5y x0,50' /bin/bash -c 'date; while true; do echo $SECONDS ; sleep 1 ; done' faketime -f '+2,5y i2,0' /bin/bash -c 'while true; do date ; sleep 1 ; done' In this single case all spawned processes will use the same global clock without restarting it at the start of each process.
(Please note that it depends on your locale settings whether . or , has to be used for fractional offsets)
The simple timestamp format used by default applies the /bin/date -d command to parse user-friendly specifications such as 'last friday'. When using the faketime option -f, the timestamp specified on the command line is directly passed to libfaketime, which enables a couple of additional features such as speeding the clock up or slowing it down for the target program. It is strongly recommended that you have a look at the libfaketime documentation. Summary:
Freeze clock at absolute timestamp: "YYYY-MM-DD hh:mm:ss" If you want to specify an absolute point in time, exactly this format must be used. Please note that freezing the clock is usually not what you want and may break the application. Only use if you know what you're doing!
Relative time offset: "[+/-]123[m/h/d/y], e.g. "+60m", "+2y" This is the most often used format and specifies the faked time relatively to the current real time. The first character of the format string must be a + or a -. The numeric value by default represents seconds, but the modifiers m, h, d, and y can be used to specify minutes, hours, days, or years, respectively. For example, "-2y" means "two years ago". Fractional time offsets can be used, e.g. "+2,5y", which means "two and a half years in the future". Please note that the fraction delimiter depends on your locale settings, so if "+2,5y" does not work, you might want to try "+2.5y".
Start-at timestamps: "@YYYY-MM-DD hh:mm:ss" The wall clock will start counting at the given timestamp for the program. This can be used for specifying absolute timestamps without freezing the clock.
When using relative time offsets or start-at timestamps (see ADVANCED TIMESTAMP FORMAT above and option -f), the clock speed can be adjusted, i.e. time may run faster or slower for the executed program. For example, "+5y x10" will set the faked time 5 years into the future and make the time pass 10 times as fast (one real second equals 10 seconds measured by the program). Similarly, the flow of time can be slowed, e.g. using "-7d x0,2", which will set the faked time 7 days in the past and set the clock speed to 20 percent, i.e. it takes five real world seconds for one second measured by the program. Again, depending on your locale, either "x2.0" or "x2,0" may be required regarding the delimiter. You can also make faketime to advance the reported time by a preset interval upon each time() call independently from the system's time using "-7d i2,0", where "i" is followed by the increase interval in seconds.
Faking times for multiple programs or even system-wide can be simplified by using ~/.faketimerc files and /etc/faketimerc. Please refer to the README that came with faketime for warnings and details.
Faking of filesystem timestamps may be disabled by setting the NO_FAKE_STAT environment variable to a non-empty value.
Please see the README and NEWS files for contributors.
Due to limitations of the LD_PRELOAD mechanism, faketime will not work with suidroot and statically linked programs.  While timestamps and time offsets will work for child processes, speeding the clock up or slowing it down might not work for child processes spawned by the executed program as expected; a new instance of libfaketime is used for each child process, which means that the libfaketime start time, which is used in speed adjustments, will also be re-initialized. Some programs may dynamically load system libraries, such as librt, at run-time and therefore bypass libfaketime. You may report programs that do not work with libfaketime, but only if they are available as open source.
Please use https://github.com/wolfcw/libfaketime/issues
Copyright Â© 2003-2013 by the libfaketime authors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of faketime under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING.
ld.so(1), time(2), fstat(2)
HOSTAPD(8)                           hostapd                          HOSTAPD(8)
hostapd - IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
hostapd [-hdBKtv] [-P <PID file>] <configuration file(s)>
This manual page documents briefly the hostapd daemon.
hostapd is a user space daemon for access point and authentication servers.  It implements IEEE 802.11 access point management, IEEE 802.1X/WPA/WPA2/EAP Authenticators and RADIUS authentication server.  The current version supports Linux (Host AP, mac80211-based drivers) and FreeBSD (net80211).
hostapd is designed to be a "daemon" program that runs in the background and acts as the backend component controlling authentication.  hostapd supports separate frontend programs and an example text-based frontend, hostapd_cli, is included with hostapd.
A summary of options is included below.  For a complete description, run hostapd from the command line.
-h     Show usage.
-d     Show more debug messages.
-dd    Show even more debug messages.
-B     Run daemon in the background.
-P <PID file> Path to PID file.
-K     Include key data in debug messages.
-t     Include timestamps in some debug messages.
-v     Show hostapd version.
hostapd_cli(1).
hostapd was written by Jouni Malinen <j@w1.fi>.
This manual page was written by Faidon Liambotis <faidon@cube.gr>, for the Debian project (but may be used by others).
OD(1)                             User Commands                            OD(1)
od - dump files in octal and other formats
od [OPTION]... [FILE]... od [-abcdfilosx]... [FILE] [[+]OFFSET[.][b]] od --traditional [OPTION]... [FILE] [[+]OFFSET[.][b] [+][LABEL][.][b]]
Write an unambiguous representation, octal bytes by default, of FILE to standard output.  With more than one FILE argument, concatenate them in the listed order to form the input.
If first and second call formats both apply, the second format is assumed if the last operand begins with + or (if there are 2 operands) a digit. An OFFSET operand means -j OFFSET.  LABEL is the pseudo-address at first byte printed, incremented when dump is progressing.  For OFFSET and LABEL, a 0x or 0X prefix indicates hexadecimal; suffixes may be . for octal and b for multiply by 512.
-A, --address-radix=RADIX output format for file offsets; RADIX is one of [doxn], for Decimal, Octal, Hex or None
--endian={big|little} swap input bytes according the specified order
-j, --skip-bytes=BYTES skip BYTES input bytes first
-N, --read-bytes=BYTES limit dump to BYTES input bytes
-S BYTES, --strings[=BYTES] output strings of at least BYTES graphic chars; 3 is implied when BYTES is not specified
-t, --format=TYPE select output format or formats
-v, --output-duplicates do not use * to mark line suppression
-w[BYTES], --width[=BYTES] output BYTES bytes per output line; 32 is implied when BYTES is not specified
--traditional accept arguments in third form above
Traditional format specifications may be intermixed; they accumulate: -a     same as -t a,  select named characters, ignoring high-order bit
-b     same as -t o1, select octal bytes
-c     same as -t c,  select printable characters or backslash escapes
-d     same as -t u2, select unsigned decimal 2-byte units
-f     same as -t fF, select floats
-i     same as -t dI, select decimal ints
-l     same as -t dL, select decimal longs
-o     same as -t o2, select octal 2-byte units
-s     same as -t d2, select decimal 2-byte units
-x     same as -t x2, select hexadecimal 2-byte units
TYPE is made up of one or more of these specifications: a      named character, ignoring high-order bit
c      printable character or backslash escape
d[SIZE] signed decimal, SIZE bytes per integer
f[SIZE] floating point, SIZE bytes per float
o[SIZE] octal, SIZE bytes per integer
u[SIZE] unsigned decimal, SIZE bytes per integer
x[SIZE] hexadecimal, SIZE bytes per integer
SIZE is a number.  For TYPE in [doux], SIZE may also be C for sizeof(char), S for sizeof(short), I for sizeof(int) or L for sizeof(long).  If TYPE is f, SIZE may also be F for sizeof(float), D for sizeof(double) or L for sizeof(long double).
Adding a z suffix to any type displays printable characters at the end of each output line.
BYTES is hex with 0x or 0X prefix, and may have a multiplier suffix: b      512
KB     1000
K      1024
MB     1000*1000
M      1024*1024
and so on for G, T, P, E, Z, Y.  Binary prefixes can be used, too: KiB=K, MiB=M, and so on.
od -A x -t x1z -v Display hexdump format output
od -A o -t oS -w16 The default output format used by od
Full documentation <https://www.gnu.org/software/coreutils/od> or available locally via: info '(coreutils) od invocation'
FLAMESHOT(1)                 General Commands Manual                FLAMESHOT(1)
flameshot - Powerful yet simple-to-use screenshot software
flameshot [arguments] [flameshot-options] flameshot gui [gui options] flameshot launcher flameshot full [fullscreen capture options] flameshot screen [screen-options] flameshot config [config options]
This manual page documents briefly the flameshot command as provided by flameshot package.
flameshot is a screenshot tool that aims to be powerful yet simple-to- use.  Its notable features include customizable appearance, in-app screenshot editing, D-Bus interface, tray icon support, experimental GNOME/KDE Wayland support, integration with Imgur and support for both GUI and CLI interface.
Besides the brief information about flameshot here, The detailed usage of flameshot is documented in the README.md file distributed alongside this software. Typically you may find this file under /usr/share/doc/flameshot/ directory.
This section lists some of the most common usage of flameshot via command line.
flameshot Start flameshot and have it running in background. If enabled, an icon will appear in the tray area of current desktop environment.
flameshot gui Capture with GUI.
flameshot gui -p /path/to/captures Capture with GUI and custom save path.
flameshot gui -d 2000 Open GUI with a delay of 2 seconds.
flameshot launcher Open a launcher dialog for advanced screenshot, such as custom time delay, etc.
flameshot full --help Shows help for flameshot full subcommand.
flameshot full -p /path/to/captures -d 5000 Fullscreen capture with custom save path (no GUI) and time delay.
flameshot full -c -p /path/to/captures Fullscreen capture with custom savepath copying to clipboard.
flameshot screen --number <screen number> Define the screen to capture. Will capture the screen containing the cursor by default.
flameshot screen --help Shows help for flameshot screen subcommand.
You may use the graphical menu to configure flameshot.  Alternatively, you can also use terminal or scripts to do so.
flameshot config Open the configuration menu (GUI).
flameshot config -h Use the help flag to show more information about the available options.
The program is further documented in the README.md as typically provided under /usr/share/doc/flameshot/ directory.  You may also find more detailed online documentation on upstream project homepage.
Upstream project homepage: <https://flameshot.org/>.
flameshot was initially written by lupoDharkael ⟨izhe@hotmail.es⟩.
This manual page is written by Boyuan Yang ⟨byang@debian.org⟩ for the Debian Project (but may be used by others).
RACO(1)                      General Commands Manual                     RACO(1)
raco - the RAcket COmmand-line tool
raco [ option ...  ] [ argument ...  ]
raco performs various tasks related to the Racket language, such as finding documentation, compiling Racket source to bytecode, packaging executables, and packaging installable archives.
raco help
for a list of subcommands.
raco was implemented by PLT.
racket(1), drracket(1)
WAIT(2)                     Linux Programmer's Manual                    WAIT(2)
wait, waitpid, waitid - wait for process to change state
#include <sys/wait.h>
pid_t wait(int *wstatus); pid_t waitpid(pid_t pid, int *wstatus, int options);
int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options); /* This is the glibc and POSIX interface; see NOTES for information on the raw system call. */
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
waitid(): Since glibc 2.26: _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200809L Glibc 2.25 and earlier: _XOPEN_SOURCE || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L || /* Glibc <= 2.19: */ _BSD_SOURCE
All of these system calls are used to wait for state changes in a child of the calling process, and obtain information about the child whose state has changed.  A state change is considered to be: the child terminated; the child was stopped by a signal; or the child was resumed by a signal.  In the case of a terminated child, performing a wait allows the system to release the resources associated with the child; if a wait is not performed, then the terminated child remains in a "zombie" state (see NOTES below).
If a child has already changed state, then these calls return immediately.  Otherwise, they block until either a child changes state or a signal handler interrupts the call (assuming that system calls are not automatically restarted using the SA_RESTART flag of sigaction(2)).  In the remainder of this page, a child whose state has changed and which has not yet been waited upon by one of these system calls is termed waitable.
wait() and waitpid() The wait() system call suspends execution of the calling thread until one of its children terminates.  The call wait(&wstatus) is equivalent to:
waitpid(-1, &wstatus, 0);
The waitpid() system call suspends execution of the calling thread until a child specified by pid argument has changed state.  By default, waitpid() waits only for terminated children, but this behavior is modifiable via the options argument, as described below.
The value of pid can be:
< -1   meaning wait for any child process whose process group ID is equal to the absolute value of pid.
-1     meaning wait for any child process.
0      meaning wait for any child process whose process group ID is equal to that of the calling process at the time of the call to waitpid().
> 0    meaning wait for the child whose process ID is equal to the value of pid.
The value of options is an OR of zero or more of the following constants:
WNOHANG return immediately if no child has exited.
WUNTRACED also return if a child has stopped (but not traced via ptrace(2)). Status for traced children which have stopped is provided even if this option is not specified.
WCONTINUED (since Linux 2.6.10) also return if a stopped child has been resumed by delivery of SIGCONT.
(For Linux-only options, see below.)
If wstatus is not NULL, wait() and waitpid() store status information in the int to which it points.  This integer can be inspected with the following macros (which take the integer itself as an argument, not a pointer to it, as is done in wait() and waitpid()!):
WIFEXITED(wstatus) returns true if the child terminated normally, that is, by calling exit(3) or _exit(2), or by returning from main().
WEXITSTATUS(wstatus) returns the exit status of the child.  This consists of the least significant 8 bits of the status argument that the child specified in a call to exit(3) or _exit(2) or as the argument for a return statement in main().  This macro should be employed only if WIFEXITED returned true.
WIFSIGNALED(wstatus) returns true if the child process was terminated by a signal.
WTERMSIG(wstatus) returns the number of the signal that caused the child process to terminate.  This macro should be employed only if WIFSIGNALED returned true.
WCOREDUMP(wstatus) returns true if the child produced a core dump (see core(5)). This macro should be employed only if WIFSIGNALED returned true.
This macro is not specified in POSIX.1-2001 and is not available on some UNIX implementations (e.g., AIX, SunOS).  Therefore, enclose its use inside #ifdef WCOREDUMP ... #endif.
WIFSTOPPED(wstatus) returns true if the child process was stopped by delivery of a signal; this is possible only if the call was done using WUNTRACED or when the child is being traced (see ptrace(2)).
WSTOPSIG(wstatus) returns the number of the signal which caused the child to stop. This macro should be employed only if WIFSTOPPED returned true.
WIFCONTINUED(wstatus) (since Linux 2.6.10) returns true if the child process was resumed by delivery of SIGCONT.
waitid() The waitid() system call (available since Linux 2.6.9) provides more precise control over which child state changes to wait for.
The idtype and id arguments select the child(ren) to wait for, as follows:
idtype == P_PID Wait for the child whose process ID matches id.
idtype == P_PIDFD (since Linux 5.4) Wait for the child referred to by the PID file descriptor specified in id.  (See pidfd_open(2) for further information on PID file descriptors.)
idtype == P_PGID Wait for any child whose process group ID matches id.  Since Linux 5.4, if id is zero, then wait for any child that is in the same process group as the caller's process group at the time of the call.
idtype == P_ALL Wait for any child; id is ignored.
The child state changes to wait for are specified by ORing one or more of the following flags in options:
WEXITED Wait for children that have terminated.
WSTOPPED Wait for children that have been stopped by delivery of a signal.
WCONTINUED Wait for (previously stopped) children that have been resumed by delivery of SIGCONT.
The following flags may additionally be ORed in options:
WNOHANG As for waitpid().
WNOWAIT Leave the child in a waitable state; a later wait call can be used to again retrieve the child status information.
Upon successful return, waitid() fills in the following fields of the siginfo_t structure pointed to by infop:
si_pid The process ID of the child.
si_uid The real user ID of the child.  (This field is not set on most other implementations.)
si_signo Always set to SIGCHLD.
si_status Either the exit status of the child, as given to _exit(2) (or exit(3)), or the signal that caused the child to terminate, stop, or continue.  The si_code field can be used to determine how to interpret this field.
si_code Set to one of: CLD_EXITED (child called _exit(2)); CLD_KILLED (child killed by signal); CLD_DUMPED (child killed by signal, and dumped core); CLD_STOPPED (child stopped by signal); CLD_TRAPPED (traced child has trapped); or CLD_CONTINUED (child continued by SIGCONT).
If WNOHANG was specified in options and there were no children in a waitable state, then waitid() returns 0 immediately and the state of the siginfo_t structure pointed to by infop depends on the implementation. To (portably) distinguish this case from that where a child was in a waitable state, zero out the si_pid field before the call and check for a nonzero value in this field after the call returns.
POSIX.1-2008 Technical Corrigendum 1 (2013) adds the requirement that when WNOHANG is specified in options and there were no children in a waitable state, then waitid() should zero out the si_pid and si_signo fields of the structure.  On Linux and other implementations that adhere to this requirement, it is not necessary to zero out the si_pid field before calling waitid().  However, not all implementations follow the POSIX.1 specification on this point.
wait(): on success, returns the process ID of the terminated child; on failure, -1 is returned.
waitpid(): on success, returns the process ID of the child whose state has changed; if WNOHANG was specified and one or more child(ren) specified by pid exist, but have not yet changed state, then 0 is returned.  On failure, -1 is returned.
waitid(): returns 0 on success or if WNOHANG was specified and no child(ren) specified by id has yet changed state; on failure, -1 is returned.
On failure, each of these calls sets errno to indicate the error.
EAGAIN The PID file descriptor specified in id is nonblocking and the process that it refers to has not terminated.
ECHILD (for wait()) The calling process does not have any unwaited-for children.
ECHILD (for waitpid() or waitid()) The process specified by pid (waitpid()) or idtype and id (waitid()) does not exist or is not a child of the calling process.  (This can happen for one's own child if the action for SIGCHLD is set to SIG_IGN.  See also the Linux Notes section about threads.)
EINTR  WNOHANG was not set and an unblocked signal or a SIGCHLD was caught; see signal(7).
EINVAL The options argument was invalid.
ESRCH  (for wait() or waitpid()) pid is equal to INT_MIN.
SVr4, 4.3BSD, POSIX.1-2001.
A child that terminates, but has not been waited for becomes a "zombie". The kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a wait to obtain information about the child.  As long as a zombie is not removed from the system via a wait, it will consume a slot in the kernel process table, and if this table fills, it will not be possible to create further processes.  If a parent process terminates, then its "zombie" children (if any) are adopted by init(1), (or by the nearest "subreaper" process as defined through the use of the prctl(2) PR_SET_CHILD_SUBREAPER operation); init(1) automatically performs a wait to remove the zombies.
POSIX.1-2001 specifies that if the disposition of SIGCHLD is set to SIG_IGN or the SA_NOCLDWAIT flag is set for SIGCHLD (see sigaction(2)), then children that terminate do not become zombies and a call to wait() or waitpid() will block until all children have terminated, and then fail with errno set to ECHILD.  (The original POSIX standard left the behavior of setting SIGCHLD to SIG_IGN unspecified.  Note that even though the default disposition of SIGCHLD is "ignore", explicitly setting the disposition to SIG_IGN results in different treatment of zombie process children.)
Linux 2.6 conforms to the POSIX requirements.  However, Linux 2.4 (and earlier) does not: if a wait() or waitpid() call is made while SIGCHLD is being ignored, the call behaves just as though SIGCHLD were not being ignored, that is, the call blocks until the next child terminates and then returns the process ID and status of that child.
Linux notes In the Linux kernel, a kernel-scheduled thread is not a distinct construct from a process.  Instead, a thread is simply a process that is created using the Linux-unique clone(2) system call; other routines such as the portable pthread_create(3) call are implemented using clone(2). Before Linux 2.4, a thread was just a special case of a process, and as a consequence one thread could not wait on the children of another thread, even when the latter belongs to the same thread group.  However, POSIX prescribes such functionality, and since Linux 2.4 a thread can, and by default will, wait on children of other threads in the same thread group.
The following Linux-specific options are for use with children created using clone(2); they can also, since Linux 4.7, be used with waitid():
__WCLONE Wait for "clone" children only.  If omitted, then wait for "non- clone" children only.  (A "clone" child is one which delivers no signal, or a signal other than SIGCHLD to its parent upon termination.)  This option is ignored if __WALL is also specified.
__WALL (since Linux 2.4) Wait for all children, regardless of type ("clone" or "non- clone").
__WNOTHREAD (since Linux 2.4) Do not wait for children of other threads in the same thread group.  This was the default before Linux 2.4.
Since Linux 4.7, the __WALL flag is automatically implied if the child is being ptraced.
C library/kernel differences wait() is actually a library function that (in glibc) is implemented as a call to wait4(2).
On some architectures, there is no waitpid() system call; instead, this interface is implemented via a C library wrapper function that calls wait4(2).
The raw waitid() system call takes a fifth argument, of type struct rusage *.  If this argument is non-NULL, then it is used to return resource usage information about the child, in the same manner as wait4(2).  See getrusage(2) for details.
According to POSIX.1-2008, an application calling waitid() must ensure that infop points to a siginfo_t structure (i.e., that it is a non-null pointer).  On Linux, if infop is NULL, waitid() succeeds, and returns the process ID of the waited-for child.  Applications should avoid relying on this inconsistent, nonstandard, and unnecessary feature.
The following program demonstrates the use of fork(2) and waitpid().  The program creates a child process.  If no command-line argument is supplied to the program, then the child suspends its execution using pause(2), to allow the user to send signals to the child.  Otherwise, if a command- line argument is supplied, then the child exits immediately, using the integer supplied on the command line as the exit status.  The parent process executes a loop that monitors the child using waitpid(), and uses the W*() macros described above to analyze the wait status value.
The following shell session demonstrates the use of the program:
$ ./a.out & Child PID is 32360 [1] 32359 $ kill -STOP 32360 stopped by signal 19 $ kill -CONT 32360 continued $ kill -TERM 32360 killed by signal 15 [1]+  Done                    ./a.out $
#include <sys/wait.h> #include <stdint.h> #include <stdlib.h> #include <unistd.h> #include <stdio.h>
int main(int argc, char *argv[]) { pid_t cpid, w; int wstatus;
cpid = fork(); if (cpid == -1) { perror("fork"); exit(EXIT_FAILURE); }
if (cpid == 0) {            /* Code executed by child */ printf("Child PID is %jd\n", (intmax_t) getpid()); if (argc == 1) pause();                    /* Wait for signals */ _exit(atoi(argv[1]));
} else {                    /* Code executed by parent */ do { w = waitpid(cpid, &wstatus, WUNTRACED | WCONTINUED); if (w == -1) { perror("waitpid"); exit(EXIT_FAILURE); }
if (WIFEXITED(wstatus)) { printf("exited, status=%d\n", WEXITSTATUS(wstatus)); } else if (WIFSIGNALED(wstatus)) { printf("killed by signal %d\n", WTERMSIG(wstatus)); } else if (WIFSTOPPED(wstatus)) { printf("stopped by signal %d\n", WSTOPSIG(wstatus)); } else if (WIFCONTINUED(wstatus)) { printf("continued\n"); } } while (!WIFEXITED(wstatus) && !WIFSIGNALED(wstatus)); exit(EXIT_SUCCESS); } }
_exit(2), clone(2), fork(2), kill(2), ptrace(2), sigaction(2), signal(2), wait4(2), pthread_create(3), core(5), credentials(7), signal(7)
tlp-stat(8)                     Power Management                     tlp-stat(8)
tlp-stat - view power saving status
tlp-stat [options] [-- CONFIG_PARAM=value ... ]
View configuration, system information, kernel power saving settings and battery data. Invocation without options shows all information categories.
-b, --battery View battery data. Add -v to see battery voltages (if available).
-c, --config View active configuration.
--cdiff View the difference between defaults and user configuration.
-d, --disk View disk device information.
-e, --pcie View PCIe device information. Add -v to see device runtime status.
-g, --graphics View graphics card information.
-p, --processor View processor information. For clarity the standard output shows only cpu0.  Add -v to see all.
-r, --rfkill View radio device states.
-s, --system View system information.
-t, --temp View temperatures and fan speed.
-u, --usb View USB device information. Add -v to see device runtime status.
-v, --verbose Show more information in battery, PCIe, processor and USB categories.
Diagnostics and debugging:
-P, --pev Monitor power supply udev events.
--psup View power supply diagnostics.
-T, --trace View trace output.
--udev Check if udev rules for power source changes and connecting USB devices are active.
-w, --warn View warnings about SATA disks.
-- CONFIG_PARAM=value ... Add configuration parameters to temporarily overwrite the system configuration (for this program invocation only).
/etc/tlp.conf System-wide user configuration file, uncomment parameters here to override default settings and customization files below.
/etc/tlp.d/*.conf System-wide drop-in customization files, overriding defaults below.
/usr/share/tlp/defaults.conf Intrinsic default settings. DO NOT EDIT this file, instead use one of the above alternatives.
/run/tlp/run.conf Effective settings consolidated from all above files. DO NOT CHANGE this file, it is for reference only and regenerated on every invocation of TLP.
/etc/default/tlp Obsolete system-wide configuration file. DO NOT USE this file, it is evaluated as fallback only when /etc/tlp.conf is non-existent.
tlp(8).
(c) 2021 Thomas Koch <linrunner at gmx.net>
TEA(1)                       General Commands Manual                      TEA(1)
tea - text editor with syntax highlighting & UTF support
tea  files
TEA is a modest and easy-to-use Qt-based editor with many useful features for HTML editing.  It features a small footprint, a tabbed layout engine, support for multiple encodings, code snippets, templates, customizable hotkeys, an "open at cursor" function for HTML files and images, miscellaneous HTML tools, preview in external browser, string manipulation functions, SRT subtitles editing, Morse-code tools, bookmarks, syntax highlighting, and drag-and-drop support.
--crapbook - start TEA with the Crapbook already opened.
--charset=charset_name - set the charset for the opening file.  For example, you want to open file1 with CP1251 charset, and file2 with UTF-8.  So you write: tea --charset=cp1251 file1 --charset=utf-8 file2
Please refer to chapter 16 - "command line options" at /usr/share/doc/tea-data/en.html for more info.
TEA was written by Peter Semiletov <peter.semiletov@gmail.com>.
This manual page was written by Lior Kaplan <kaplan@debian.org>, for the Debian project (but may be used by others).
SD(1)                        General Commands Manual                       SD(1)
sd [FLAGS] find replace_with [FILES]
-p, --preview Emit the replacement to STDOUT
-s, --string-mode Treat expressions as non-regex strings.
-f, --flags Treat expressions as non-regex strings.  /** Regex flags. May be combined (like `-f mc`).
c - case-sensitive i - case-insensitive m - multi-line matching w - match full words only
1      Unsuccessful program execution.
101    The program panicked.
String-literal mode $ echo 'lots((([]))) of special chars' | sd -s '((([])))' '' lots of special chars
Regex use. Let's trim some trailing whitespace $ echo 'lorem ipsum 23   ' | sd ' '' lorem ipsum 23
Indexed capture groups $ echo 'cargo +nightly watch' | sd '(96 cmd: cargo, channel: nightly, subcmd: watch
Named capture groups $ echo "123.45" | sd '(?P<dollars>+).(?P<cents>+)' '$dollars dollars and $cents cents' 123 dollars and 45 cents
Find & replace in file $ sd 'window.fetch' 'fetch' http.js
Find & replace from STDIN an emit to STDOUT $ sd 'window.fetch' 'fetch' < http.js
GIT-CHECKOUT(1)                    Git Manual                    GIT-CHECKOUT(1)
git-checkout - Switch branches or restore working tree files
git checkout [-q] [-f] [-m] [<branch>] git checkout [-q] [-f] [-m] --detach [<branch>] git checkout [-q] [-f] [-m] [--detach] <commit> git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>... git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul] git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
Updates files in the working tree to match the version in the index or the specified tree. If no pathspec was given, git checkout will also update HEAD to set the specified branch as the current branch.
git checkout [<branch>] To prepare for working on <branch>, switch to it by updating the index and the files in the working tree, and by pointing HEAD at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the <branch>.
If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name and --no-guess is not specified, treat as equivalent to
$ git checkout -b <branch> --track <remote>/<branch>
You could omit <branch>, in which case the command degenerates to "check out the current branch", which is a glorified no-op with rather expensive side-effects to show only the tracking information, if exists, for the current branch.
git checkout -b|-B <new_branch> [<start point>] Specifying -b causes a new branch to be created as if git-branch(1) were called and then checked out. In this case you can use the --track or --no-track options, which will be passed to git branch. As a convenience, --track without -b implies branch creation; see the description of --track below.
If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of
$ git branch -f <branch> [<start point>] $ git checkout <branch>
that is to say, the branch is not reset/created unless "git checkout" is successful.
git checkout --detach [<branch>], git checkout [--detach] <commit> Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications.
When the <commit> argument is a branch name, the --detach option can be used to detach HEAD at the tip of the branch (git checkout <branch> would check out that branch without detaching HEAD).
Omitting <branch> detaches HEAD at the tip of the current branch.
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>..., git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul] Overwrite the contents of the files that match the pathspec. When the <tree-ish> (most often a commit) is not given, overwrite working tree with the contents in the index. When the <tree-ish> is given, overwrite both the index and the working tree with the contents at the <tree-ish>.
The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result.
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...] This is similar to the previous mode, but lets you use the interactive interface to show the "diff" output and choose which hunks to use in the result. See below for the description of --patch option.
-f, --force When switching branches, proceed even if the index or the working tree differs from HEAD, and even if there are untracked files in the way. This is used to throw away local changes and any untracked files or directories that are in the way.
When checking out paths from the index, do not fail upon unmerged entries; instead, unmerged entries are ignored.
--ours, --theirs When checking out paths from the index, check out stage #2 (ours) or #3 (theirs) for unmerged paths.
Note that during git rebase and git pull --rebase, ours and theirs may appear swapped; --ours gives the version from the branch the changes are rebased onto, while --theirs gives the version from the branch that holds your work that is being rebased.
This is because rebase is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase. As the keeper of the canonical history, you need to view the history from the remote as ours (i.e. "our shared canonical history"), while what you did on your side branch as theirs (i.e. "one contributor’s work on top of it").
-b <new_branch> Create a new branch named <new_branch> and start it at <start_point>; see git-branch(1) for details.
-B <new_branch> Creates the branch <new_branch> and start it at <start_point>; if it already exists, then reset it to <start_point>. This is equivalent to running "git branch" with "-f"; see git-branch(1) for details.
-t, --track When creating a new branch, set up "upstream" configuration. See "--track" in git-branch(1) for details.
If no -b option is given, the name of the new branch will be derived from the remote-tracking branch, by looking at the local part of the refspec configured for the corresponding remote, and then stripping the initial part up to the "*". This would tell us to use hack as the local branch when branching off of origin/hack (or remotes/origin/hack, or even refs/remotes/origin/hack). If the given name has no slash, or the above guessing results in an empty name, the guessing is aborted. You can explicitly give a name with -b in such a case.
-l Create the new branch’s reflog; see git-branch(1) for details.