neulab/tldr huggingface dataset:
-o option This option is supported if the system supports the User Portability Utilities option. It shall set various options, many of which shall be equivalent to the single option letters. The following values of option shall be supported:
allexport Equivalent to -a.
errexit   Equivalent to -e.
ignoreeof Prevent an interactive shell from exiting on end-of-file. This setting prevents accidental logouts when <control>‐D is entered. A user shall explicitly exit to leave the interactive shell.
monitor   Equivalent to -m.  This option is supported if the system supports the User Portability Utilities option.
noclobber Equivalent to -C (uppercase C).
noglob    Equivalent to -f.
noexec    Equivalent to -n.
nolog     Prevent the entry of function definitions into the command history; see Command History List.
notify    Equivalent to -b.
nounset   Equivalent to -u.
verbose   Equivalent to -v.
vi        Allow shell command line editing using the built-in vi editor. Enabling vi mode shall disable any other command line editing mode provided as an implementation extension.
It need not be possible to set vi mode on for certain block-mode terminals.
xtrace    Equivalent to -x.
-u    When the shell tries to expand an unset parameter other than the '@' and '*' special parameters, it shall write a message to standard error and the expansion shall fail with the consequences specified in Section 2.8.1, Consequences of Shell Errors.
-v    The shell shall write its input to standard error as it is read.
-x    The shell shall write to standard error a trace for each command after it expands the command and before it executes it. It is unspecified whether the command that turns tracing off is traced.
The default for all these options shall be off (unset) unless stated otherwise in the description of the option or unless the shell was invoked with them on; see sh.
The remaining arguments shall be assigned in order to the positional parameters. The special parameter '#' shall be set to reflect the number of positional parameters. All positional parameters shall be unset before any new values are assigned.
The special argument "--" immediately following the set command name can be used to delimit the arguments if the first argument begins with '+' or '-', or to prevent inadvertent listing of all shell variables when there are no arguments. The command set -- without argument shall unset all positional parameters and set the special parameter '#' to zero.
>0    An invalid option was specified, or an error occurred.
Application writers should avoid relying on set -e within functions. For example, in the following script:
set -e start() { some_server echo some_server started successfully } start || echo >&2 some_server failed
the -e setting is ignored within the function body (because the function is a command in an AND-OR list other than the last). Therefore, if some_server fails, the function carries on to echo "some_serverstartedsuccessfully", and the exit status of the function is zero (which means "some_serverfailed" is not output).
Write out all variables and their values:
Set $1, $2, and $3 and set "$#" to 3:
set c a b
Turn on the -x and -v options:
set -xv
Unset all positional parameters:
set --
Set $1 to the value of x, even if it begins with '-' or '+':
set -- "$x"
Set the positional parameters to the expansion of x, even if x expands with a leading '-' or '+':
set -- $x
The set -- form is listed specifically in the SYNOPSIS even though this usage is implied by the Utility Syntax Guidelines. The explanation of this feature removes any ambiguity about whether the set -- form might be misinterpreted as being equivalent to set without any options or arguments. The functionality of this form has been adopted from the KornShell. In System V, set -- only unsets parameters if there is at least one argument; the only way to unset all parameters is to use shift. Using the KornShell version should not affect System V scripts because there should be no reason to issue it without arguments deliberately; if it were issued as, for example:
set -- "$@"
and there were in fact no arguments resulting from "$@", unsetting the parameters would have no result.
The set + form in early proposals was omitted as being an unnecessary duplication of set alone and not widespread historical practice.
The noclobber option was changed to allow set -C as well as the set -o noclobber option. The single-letter version was added so that the historical "$-" paradigm would not be broken; see Section 2.5.2, Special Parameters.
The description of the -e option is intended to match the behavior of the 1988 version of the KornShell.
The -h flag is related to command name hashing. See hash.
The following set flags were omitted intentionally with the following rationale:
-k    The -k flag was originally added by the author of the Bourne shell to make it easier for users of pre-release versions of the shell. In early versions of the Bourne shell the construct set name=value had to be used to assign values to shell variables. The problem with -k is that the behavior affects parsing, virtually precluding writing any compilers. To explain the behavior of -k, it is necessary to describe the parsing algorithm, which is implementation-defined. For example:
set -k; echo name=value
set -k echo name=value
behave differently. The interaction with functions is even more complex. What is more, the -k flag is never needed, since the command line could have been reordered.
-t    The -t flag is hard to specify and almost never used. The only known use could be done with here-documents. Moreover, the behavior with ksh and sh differs. The reference page says that it exits after reading and executing one command. What is one command? If the input is date;date, sh executes both date commands while ksh does only the first.
Consideration was given to rewriting set to simplify its confusing syntax. A specific suggestion was that the unset utility should be used to unset options instead of using the non-getopt()-able +option syntax. However, the conclusion was reached that the historical practice of using +option was satisfactory and that there was no compelling reason to modify such widespread historical practice.
The -o option was adopted from the KornShell to address user needs. In addition to its generally friendly interface, -o is needed to provide the vi command line editing mode, for which historical practice yields no single-letter option name. (Although it might have been possible to invent such a letter, it was recognized that other editing modes would be developed and -o provides ample name space for describing such extensions.)
Historical implementations are inconsistent in the format used for -o option status reporting. The +o format without an option-argument was added to allow portable access to the options that can be saved and then later restored using, for instance, a dot script.
Historically, sh did trace the command set +x, but ksh did not.
The ignoreeof setting prevents accidental logouts when the end-of-file character (typically <control>‐D) is entered. A user shall explicitly exit to leave the interactive shell.
The set -m option was added to apply only to the UPE because it applies primarily to interactive use, not shell script applications.
The ability to do asynchronous notification became available in the 1988 version of the KornShell. To have it occur, the user had to issue the command:
trap "jobs -n" CLD
The C shell provides two different levels of an asynchronous notification capability. The environment variable notify is analogous to what is done in set -b or set -o notify.  When set, it notifies the user immediately of background job completions. When unset, this capability is turned off.
The other notification ability comes through the built-in utility notify. The syntax is:
notify [%job ... ]
By issuing notify with no operands, it causes the C shell to notify the user asynchronously when the state of the current job changes. If given operands, notify asynchronously informs the user of changes in the states of the specified jobs.
To add asynchronous notification to the POSIX shell, neither the KornShell extensions to trap, nor the C shell notify environment variable seemed appropriate (notify is not a proper POSIX environment variable name).
The set -b option was selected as a compromise.
The notify built-in was considered to have more functionality than was required for simple asynchronous notification.
Historically, some shells applied the -u option to all parameters including $@ and $*.  The standard developers felt that this was a misfeature since it is normal and common for $@ and $* to be used in shell scripts regardless of whether they were passed any arguments. Treating these uses as an error when no arguments are passed reduces the value of -u for its intended purpose of finding spelling mistakes in variable names and uses of unset positional parameters.
Section 2.14, Special Built-In Utilities, hash
The Base Definitions volume of POSIX.1‐2017, Section 4.23, Variable Assignment, Section 12.2, Utility Syntax Guidelines
CSVFORMAT(1)                         csvkit                         CSVFORMAT(1)
csvformat - csvformat Documentation
Convert a CSV file to a custom output format.:
usage: csvformat [-h] [-d DELIMITER] [-t] [-q QUOTECHAR] [-u {0,1,2,3}] [-b] [-p ESCAPECHAR] [-z FIELD_SIZE_LIMIT] [-e ENCODING] [-S] [--blanks] [-K SKIP_LINES] [-v] [-V] [-D OUT_DELIMITER] [-T] [-Q OUT_QUOTECHAR] [-U {0,1,2,3}] [-B] [-P OUT_ESCAPECHAR] [-M OUT_LINETERMINATOR] [FILE]
Convert a CSV file to a custom output format.
optional arguments: -h, --help            show this help message and exit -D OUT_DELIMITER, --out-delimiter OUT_DELIMITER Delimiting character of the output CSV file. -T, --out-tabs        Specify that the output CSV file is delimited with tabs. Overrides "-D". -Q OUT_QUOTECHAR, --out-quotechar OUT_QUOTECHAR Character used to quote strings in the output CSV file. -U {0,1,2,3}, --out-quoting {0,1,2,3} Quoting style used in the output CSV file. 0 = Quote Minimal, 1 = Quote All, 2 = Quote Non-numeric, 3 = Quote None. -B, --out-no-doublequote Whether or not double quotes are doubled in the output CSV file. -P OUT_ESCAPECHAR, --out-escapechar OUT_ESCAPECHAR Character used to escape the delimiter in the output CSV file if --quoting 3 ("Quote None") is specified and to escape the QUOTECHAR if --no-doublequote is specified. -M OUT_LINETERMINATOR, --out-lineterminator OUT_LINETERMINATOR Character used to terminate lines in the output CSV file.
Convert a comma-separated file to a pipe-delimited file:
csvformat -D "|" examples/dummy.csv
Convert to carriage return line-endings:
csvformat -M $'\r' examples/dummy.csv
To avoid escaping quote characters when using --quoting 3, add --out-quotechar "":
csvformat -u 3 -U 3 -Q "" examples/optional_quote_characters.csv
gh-issue-create - Create a new issue
gh issue create [flags]
Create a new issue
-a, --assignee=[]      Assign people by their login. Use "@me" to self- assign.
-b, --body=""      Supply a body. Will prompt for one otherwise.
-l, --label=[]      Add labels by name
-m, --milestone=""      Add the issue to a milestone by name
-p, --project=[]      Add the issue to projects by name
--recover=""      Recover input from a failed run of create
-t, --title=""      Supply a title. Will prompt for one otherwise.
-w, --web[=false]      Open the browser to create an issue
$ gh issue create --title "I found a bug" --body "Nothing works" $ gh issue create --label "bug,help wanted" $ gh issue create --label bug --label "help wanted" $ gh issue create --assignee monalisa,hubot $ gh issue create --assignee "@me" $ gh issue create --project "Roadmap"
gh-issue(1)
READLINK(1)                       User Commands                      READLINK(1)
readlink - print resolved symbolic links or canonical file names
readlink [OPTION]... FILE...
Note realpath(1) is the preferred command to use for canonicalization functionality.
Print value of a symbolic link or canonical file name
-f, --canonicalize canonicalize by following every symlink in every component of the given name recursively; all but the last component must exist
-e, --canonicalize-existing canonicalize by following every symlink in every component of the given name recursively, all components must exist
-m, --canonicalize-missing canonicalize by following every symlink in every component of the given name recursively, without requirements on components existence
-n, --no-newline do not output the trailing delimiter
-q, --quiet
-s, --silent suppress most error messages (on by default)
-v, --verbose report error messages
Written by Dmitry V. Levin.
readlink(2), realpath(1), realpath(3)
Full documentation <https://www.gnu.org/software/coreutils/readlink> or available locally via: info '(coreutils) readlink invocation'
LLVM-BCANALYZER(1)                    LLVM                    LLVM-BCANALYZER(1)
llvm-bcanalyzer - LLVM bitcode analyzer
llvm-bcanalyzer [options] [filename]
The llvm-bcanalyzer command is a small utility for analyzing bitcode files.  The tool reads a bitcode file (such as generated with the llvm-as tool) and produces a statistical report on the contents of the bitcode file.  The tool can also dump a low level but human readable version of the bitcode file.  This tool is probably not of much interest or utility except for those working directly with the bitcode file format.  Most LLVM users can just ignore this tool.
If filename is omitted or is -, then llvm-bcanalyzer reads its input from standard input.  This is useful for combining the tool into a pipeline. Output is written to the standard output.
-nodetails Causes llvm-bcanalyzer to abbreviate its output by writing out only a module level summary.  The details for individual functions are not displayed.
-dump  Causes llvm-bcanalyzer to dump the bitcode in a human readable format.  This format is significantly different from LLVM assembly and provides details about the encoding of the bitcode file.
-verify Causes llvm-bcanalyzer to verify the module produced by reading the bitcode.  This ensures that the statistics generated are based on a consistent module.
If llvm-bcanalyzer succeeds, it will exit with 0.  Otherwise, if an error occurs, it will exit with a non-zero value, usually 1.
The following items are always printed by llvm-bcanalyzer.  They comprize the summary output.
Bitcode Analysis Of Module This just provides the name of the module for which bitcode analysis is being generated.
Bitcode Version Number The bitcode version (not LLVM version) of the file read by the analyzer.
File Size The size, in bytes, of the entire bitcode file.
Module Bytes The size, in bytes, of the module block.  Percentage is relative to File Size.
Function Bytes The size, in bytes, of all the function blocks.  Percentage is relative to File Size.
Global Types Bytes The size, in bytes, of the Global Types Pool.  Percentage is relative to File Size.  This is the size of the definitions of all types in the bitcode file.
Constant Pool Bytes The size, in bytes, of the Constant Pool Blocks Percentage is relative to File Size.
Module Globals Bytes Ths size, in bytes, of the Global Variable Definitions and their initializers.  Percentage is relative to File Size.
Instruction List Bytes The size, in bytes, of all the instruction lists in all the functions. Percentage is relative to File Size.  Note that this value is also included in the Function Bytes.
Compaction Table Bytes The size, in bytes, of all the compaction tables in all the functions. Percentage is relative to File Size.  Note that this value is also included in the Function Bytes.
Symbol Table Bytes The size, in bytes, of all the symbol tables in all the functions. Percentage is relative to File Size.  Note that this value is also included in the Function Bytes.
Dependent Libraries Bytes The size, in bytes, of the list of dependent libraries in the module. Percentage is relative to File Size.  Note that this value is also included in the Module Global Bytes.
Number Of Bitcode Blocks The total number of blocks of any kind in the bitcode file.
Number Of Functions The total number of function definitions in the bitcode file.
Number Of Types The total number of types defined in the Global Types Pool.
Number Of Constants The total number of constants (of any type) defined in the Constant Pool.
Number Of Basic Blocks The total number of basic blocks defined in all functions in the bitcode file.
Number Of Instructions The total number of instructions defined in all functions in the bitcode file.
Number Of Long Instructions The total number of long instructions defined in all functions in the bitcode file.  Long instructions are those taking greater than 4 bytes.  Typically long instructions are GetElementPtr with several indices, PHI nodes, and calls to functions with large numbers of arguments.
Number Of Operands The total number of operands used in all instructions in the bitcode file.
Number Of Compaction Tables The total number of compaction tables in all functions in the bitcode file.
Number Of Symbol Tables The total number of symbol tables in all functions in the bitcode file.
Number Of Dependent Libs The total number of dependent libraries found in the bitcode file.
Total Instruction Size The total size of the instructions in all functions in the bitcode file.
Average Instruction Size The average number of bytes per instruction across all functions in the bitcode file.  This value is computed by dividing Total Instruction Size by Number Of Instructions.
Maximum Type Slot Number The maximum value used for a type's slot number.  Larger slot number values take more bytes to encode.
Maximum Value Slot Number The maximum value used for a value's slot number.  Larger slot number values take more bytes to encode.
Bytes Per Value The average size of a Value definition (of any type).  This is computed by dividing File Size by the total number of values of any type.
Bytes Per Global The average size of a global definition (constants and global variables).
Bytes Per Function The average number of bytes per function definition.  This is computed by dividing Function Bytes by Number Of Functions.
# of VBR 32-bit Integers The total number of 32-bit integers encoded using the Variable Bit Rate encoding scheme.
# of VBR 64-bit Integers The total number of 64-bit integers encoded using the Variable Bit Rate encoding scheme.
# of VBR Compressed Bytes The total number of bytes consumed by the 32-bit and 64-bit integers that use the Variable Bit Rate encoding scheme.
# of VBR Expanded Bytes The total number of bytes that would have been consumed by the 32-bit and 64-bit integers had they not been compressed with the Variable Bit Rage encoding scheme.
Bytes Saved With VBR The total number of bytes saved by using the Variable Bit Rate encoding scheme.  The percentage is relative to # of VBR Expanded Bytes.
The following definitions occur only if the -nodetails option was not given.  The detailed output provides additional information on a per-function basis.
Type The type signature of the function.
Byte Size The total number of bytes in the function's block.
Basic Blocks The number of basic blocks defined by the function.
Instructions The number of instructions defined by the function.
Long Instructions The number of instructions using the long instruction format in the function.
Operands The number of operands used by all instructions in the function.
Instruction Size The number of bytes consumed by instructions in the function.
Average Instruction Size The average number of bytes consumed by the instructions in the function.  This value is computed by dividing Instruction Size by Instructions.
Bytes Per Instruction The average number of bytes used by the function per instruction. This value is computed by dividing Byte Size by Instructions.  Note that this is not the same as Average Instruction Size.  It computes a number relative to the total function size not just the size of the instruction list.
Number of VBR 32-bit Integers The total number of 32-bit integers found in this function (for any use).
Number of VBR 64-bit Integers The total number of 64-bit integers found in this function (for any use).
Number of VBR Compressed Bytes The total number of bytes in this function consumed by the 32-bit and 64-bit integers that use the Variable Bit Rate encoding scheme.
Number of VBR Expanded Bytes The total number of bytes in this function that would have been consumed by the 32-bit and 64-bit integers had they not been compressed with the Variable Bit Rate encoding scheme.
Bytes Saved With VBR The total number of bytes saved in this function by using the Variable Bit Rate encoding scheme.  The percentage is relative to # of VBR Expanded Bytes.
llvm-dis(1), /BitCodeFormat
XDG-USER-DIRS-UPD(1)              User Commands             XDG-USER-DIRS-UPD(1)
xdg-user-dirs-update - Update XDG user dir configuration
xdg-user-dirs-update [OPTION...] [--set NAME PATH...]
xdg-user-dirs-update updates the current state of the users user-dirs.dir. If none existed before then one is created based on the system default values, or falling back to the old non-translated filenames if such directories exists. The list of old directories used are: ~/Desktop, ~/Templates and ~/Public.
If an old configuration exists it is updated with any new default directories. Additionally, any configured directories that point to non-existing locations are reset by pointing then to the users home directory. This typically happens when the users removed the directory, so they likely don't want to use it anymore.
On the first run a user-dirs.locale file is created containing the locale that was used for the translation. This is used later by GUI tools like xdg-user-dirs-gtk-update to detect if the locale was changed, letting you to migrate from the old names.
xdg-user-dirs-update is normally run automatically at the start of a user session to update the XDG user dirs according to the users locale.
--help Print help output and exit.
--force Update existing user-dirs.dir, but force a full reset. This means: Don't reset nonexisting directories to HOME, rather recreate the directory. Never use backwards compatible non-translated names. Always recreate user-dirs.locale.
--dummy-output PATH Write the configuration to PATH instead of the default configuration file. Also, no directories are created.
--set NAME PATH Sets the XDG user dir with the given name.
NAME should be one of the following: DESKTOP DOWNLOAD TEMPLATES PUBLICSHARE DOCUMENTS MUSIC PICTURES VIDEOS
PATH must be an absolute path, e.g.  $HOME/Some/Directory.
The XDG user dirs configuration is stored in the user-dirs.dir file in the location pointed to by the XDG_CONFIG_HOME environment variable.
The XDG_CONFIG_HOME environment variable determines where the user-dirs.dirs file is located.
xdg-user-dir(1), user-dirs.dirs(5), user-dirs.defaults(5), user- dirs.conf(5).
PUPPET-APPLY(8)                   Puppet manual                  PUPPET-APPLY(8)
puppet-apply - Apply Puppet manifests locally
Applies a standalone Puppet manifest to the local system.
puppet apply [-h|--help] [-V|--version] [-d|--debug] [-v|--verbose] [-e|--execute] [--detailed-exitcodes] [-L|--loadclasses] [-l|--logdest syslog|eventlog|ABS FILEPATH|console] [--noop] [--catalog catalog] [--write-catalog-summary] file
This is the standalone puppet execution tool; use it to apply individual manifests.
When provided with a modulepath, via command line or config file, puppet apply can effectively mimic the catalog that would be served by puppet master with access to the same modules, although there are some subtle differences. When combined with scheduling and an automated system for pushing manifests, this can be used to implement a serverless Puppet site.
Most users should use ´puppet agent´ and ´puppet master´ for site-wide manifests.
Any setting that´s valid in the configuration file is a valid long argument for puppet apply. For example, ´tags´ is a valid setting, so you can specify ´--tags class,tag´ as an argument.
See the configuration file documentation at https://puppet.com/docs/puppet/latest/configuration.html for the full list of acceptable parameters. You can generate a commented list of all configuration options by running puppet with ´--genconfig´.
•   --debug: Enable full debugging.
•   --detailed-exitcodes: Provide extra information about the run via exit codes. If enabled, ´puppet apply´ will use the following exit codes:
0: The run succeeded with no changes or failures; the system was already in the desired state.
1: The run failed.
2: The run succeeded, and some resources were changed.
4: The run succeeded, and some resources failed.
6: The run succeeded, and included both changes and failures.
•   --help: Print this help message
•   --loadclasses: Load any stored classes. ´puppet agent´ caches configured classes (usually at /etc/puppetlabs/puppet/classes.txt), and setting this option causes all of those classes to be set in your puppet manifest.
•   --logdest: Where to send log messages. Choose between ´syslog´ (the POSIX syslog service), ´eventlog´ (the Windows Event Log), ´console´, or the path to a log file. Defaults to ´console´. Multiple destinations can be set using a comma separated list (eg: /path/file1,console,/path/file2)"
A path ending with ´.json´ will receive structured output in JSON format. The log file will not have an ending ´]´ automatically written to it due to the appending nature of logging. It must be appended manually to make the content valid JSON.
A path ending with ´.jsonl´ will receive structured output in JSON Lines format.
•   --noop: Use ´noop´ mode where Puppet runs in a no-op or dry-run mode. This is useful for seeing what changes Puppet will make without actually executing the changes.
•   --execute: Execute a specific piece of Puppet code
•   --test: Enable the most common options used for testing. These are ´verbose´, ´detailed-exitcodes´ and ´show_diff´.
•   --verbose: Print extra information.
•   --catalog: Apply a JSON catalog (such as one generated with ´puppet master --compile´). You can either specify a JSON file or pipe in JSON from standard input.
•   --write-catalog-summary After compiling the catalog saves the resource list and classes list to the node in the state directory named classes.txt and resources.txt
$ puppet apply -l /tmp/manifest.log manifest.pp $ puppet apply --modulepath=/root/dev/modules -e "include ntpd::server" $ puppet apply --catalog catalog.json
Luke Kanies
Copyright (c) 2011 Puppet Inc., LLC Licensed under the Apache 2.0 License
QPDF(1)                           User Commands                          QPDF(1)
qpdf - PDF transformation software
qpdf [ options ] infilename [ outfilename ]
The qpdf program is used to convert one PDF file to another equivalent PDF file.  It is capable of performing a variety of transformations such as linearization (also known as web optimization or fast web viewing), encryption, and decryption of PDF files.  It also has many options for inspecting or checking PDF files, some of which are useful primarily to PDF developers.
For a summary of qpdf's options, please run qpdf --help.  A complete manual can be found in /usr/share/doc/qpdf/qpdf-manual.html or /usr/share/doc/qpdf/qpdf-manual.pdf.
GO-TEST(1)                   General Commands Manual                  GO-TEST(1)
go-test - test packages
go test [build/test flags] [packages] [build/test flags & test binary flags]
"Go test" automates testing the packages named by the import paths.  It prints a summary of the test results in the format:
ok   archive/tar   0.011s FAIL archive/zip   0.022s ok   compress/gzip 0.033s ...
followed by detailed output for each failed package.
"Go test" recompiles each package along with any files with names matching the file pattern "*_test.go".  These additional files can contain test functions, benchmark functions, and example functions. See 'go help testfunc' for more. Each listed package causes the execution of a separate test binary. Files whose names begin with "_" (including "_test.go") or "." are ignored.
Test files that declare a package with the suffix "_test" will be compiled as a separate package, and then linked and run with the main test binary.
The go tool will ignore a directory named "testdata", making it available to hold ancillary data needed by the tests.
As part of building a test binary, go test runs go vet on the package and its test source files to identify significant problems. If go vet finds any problems, go test reports those and does not run the test binary. Only a high-confidence subset of the default go vet checks are used. That subset is: 'atomic', 'bool', 'buildtags', 'errorsas', 'ifaceassert', 'nilfunc', 'printf', and 'stringintconv'. You can see the documentation for these and other vet tests via "go doc cmd/vet".  To disable the running of go vet, use the -vet=off flag.
All test output and summary lines are printed to the go command's standard output, even if the test printed them to its own standard error. (The go command's standard error is reserved for printing errors building the tests.)
Go test runs in two different modes:
The first, called local directory mode, occurs when go test is invoked with no package arguments (for example, 'go test' or 'go test -v'). In this mode, go test compiles the package sources and tests found in the current directory and then runs the resulting test binary. In this mode, caching (discussed below) is disabled.  After the package test finishes, go test prints a summary line showing the test status ('ok' or 'FAIL'), package name, and elapsed time.
The second, called package list mode, occurs when go test is invoked with explicit package arguments (for example 'go test math', 'go test ./...', and even 'go test .'). In this mode, go test compiles and tests each of the packages listed on the command line. If a package test passes, go test prints only the final 'ok' summary line. If a package test fails, go test prints the full test output.  If invoked with the -bench or -v flag, go test prints the full output even for passing package tests, in order to display the requested benchmark results or verbose logging. After the package tests for all of the listed packages finish, and their output is printed, go test prints a final 'FAIL' status if any package test has failed.
In package list mode only, go test caches successful package test results to avoid unnecessary repeated running of tests. When the result of a test can be recovered from the cache, go test will redisplay the previous output instead of running the test binary again. When this happens, go test prints '(cached)' in place of the elapsed time in the summary line.
The rule for a match in the cache is that the run involves the same test binary and the flags on the command line come entirely from a restricted set of ‘cacheable’ test flags, defined as -benchtime, -cpu, -list, -parallel, -run, -short, and -v. If a run of go test has any test or non- test flags outside this set, the result is not cached. To disable test caching, use any test flag or argument other than the cacheable flags. The idiomatic way to disable test caching explicitly is to use -count=1. Tests that open files within the package's source root (usually $GOPATH) or that consult environment variables only match future runs in which the files and environment variables are unchanged.  A cached test result is treated as executing in no time at all, so a successful package test result will be cached and reused regardless of -timeout setting.
In addition to the build flags, the flags handled by 'go test' itself are:
-args  Pass the remainder of the command line (everything after -args) to the test binary, uninterpreted and unchanged.  Because this flag consumes the remainder of the command line, the package list (if present) must appear before this flag.
-c     Compile the test binary to pkg.test but do not run it (where pkg is the last element of the package's import path).  The file name can be changed with the -o flag.
-exec xprog Run the test binary using xprog. The behavior is the same as in 'go run'. See 'go help run' for details.
-i     Install packages that are dependencies of the test.  Do not run the test.
-json  Convert test output to JSON suitable for automated processing. See 'go doc test2json' for the encoding details.
-o file Compile the test binary to the named file.  The test still runs (unless -c or -i is specified).
The test binary also accepts flags that control execution of the test; these flags are also accessible by 'go test'.  See go-testflag(7) for details.
For more about build flags, see go-build(1).
go-build(1), go-vet(1).
This manual page was written by Michael Stapelberg <stapelberg@debian.org> and is maintained by the Debian Go Compiler Team <team+go-compiler@tracker.debian.org> based on the output of 'go help test' for the Debian project (and may be used by others).
PGREP(1)                          User Commands                         PGREP(1)
pgrep, pkill, pwait - look up, signal, or wait for processes based on name and other attributes
pgrep [options] pattern pkill [options] pattern pwait [options] pattern
pgrep looks through the currently running processes and lists the process IDs which match the selection criteria to stdout.  All the criteria have to match.  For example,
$ pgrep -u root sshd
will only list the processes called sshd AND owned by root.  On the other hand,
$ pgrep -u root,daemon
will list the processes owned by root OR daemon.
pkill will send the specified signal (by default SIGTERM) to each process instead of listing them on stdout.
pwait will wait for each process instead of listing them on stdout.
-signal --signal signal Defines the signal to send to each matched process.  Either the numeric or the symbolic signal name can be used.  (pkill only.)
-c, --count Suppress normal output; instead print a count of matching processes.  When count does not match anything, e.g. returns zero, the command will return non-zero value. Note that for pkill and pwait, the count is the number of matching processes, not the processes that were successfully signaled or waited for.
-d, --delimiter delimiter Sets the string used to delimit each process ID in the output (by default a newline).  (pgrep only.)
-e, --echo Display name and PID of the process being killed.  (pkill only.)
-f, --full The pattern is normally only matched against the process name. When -f is set, the full command line is used.
-g, --pgroup pgrp,... Only match processes in the process group IDs listed.  Process group 0 is translated into pgrep's, pkill's, or pwait's own process group.
-G, --group gid,... Only match processes whose real group ID is listed.  Either the numerical or symbolical value may be used.
-i, --ignore-case Match processes case-insensitively.
-l, --list-name List the process name as well as the process ID.  (pgrep only.)
-a, --list-full List the full command line as well as the process ID.  (pgrep only.)
-n, --newest Select only the newest (most recently started) of the matching processes.
-o, --oldest Select only the oldest (least recently started) of the matching processes.
-O, --older secs Select processes older than secs.
-P, --parent ppid,... Only match processes whose parent process ID is listed.
-s, --session sid,... Only match processes whose process session ID is listed.  Session ID 0 is translated into pgrep's, pkill's, or pwait's own session ID.
-t, --terminal term,... Only match processes whose controlling terminal is listed.  The terminal name should be specified without the "/dev/" prefix.
-u, --euid euid,... Only match processes whose effective user ID is listed.  Either the numerical or symbolical value may be used.
-U, --uid uid,... Only match processes whose real user ID is listed.  Either the numerical or symbolical value may be used.
-v, --inverse Negates the matching.  This option is usually used in pgrep's or pwait's context.  In pkill's context the short option is disabled to avoid accidental usage of the option.
-w, --lightweight Shows all thread ids instead of pids in pgrep's or pwait's context.  In pkill's context this option is disabled.
-x, --exact Only match processes whose names (or command lines if -f is specified) exactly match the pattern.
-F, --pidfile file Read PIDs from file.  This option is more useful for pkillorpwait than pgrep.
-L, --logpidfile Fail if pidfile (see -F) not locked.
-r, --runstates D,R,S,Z,... Match only processes which match the process state.
--ns pid Match processes that belong to the same namespaces. Required to run as root to match processes from other users. See --nslist for how to limit which namespaces to match.
--nslist name,... Match only the provided namespaces. Available namespaces: ipc, mnt, net, pid, user,uts.
-q, --queue value Use sigqueue(3) rather than kill(2) and the value argument is used to specify an integer to be sent with the signal. If the receiving process has installed a handler for this signal using the SA_SIGINFO flag to sigaction(2) , then it can obtain this data via the si_value field of the siginfo_t structure.
pattern Specifies an Extended Regular Expression for matching against the process names or command lines.
Example 1: Find the process ID of the named daemon:
$ pgrep -u root named
Example 2: Make syslog reread its configuration file:
$ pkill -HUP syslogd
Example 3: Give detailed information on all xterm processes:
$ ps -fp $(pgrep -d, -x xterm)
Example 4: Make all chrome processes run nicer:
$ renice +4 $(pgrep chrome)
0      One or more processes matched the criteria. For pkill and pwait, one or more processes must also have been successfully signalled or waited for. 1      No processes matched or none of them could be signalled. 2      Syntax error in the command line. 3      Fatal error: out of memory etc.
The process name used for matching is limited to the 15 characters present in the output of /proc/pid/stat.  Use the -f option to match against the complete command line, /proc/pid/cmdline.
The running pgrep, pkill, or pwait process will never report itself as a match.
The options -n and -o and -v can not be combined.  Let me know if you need to do this.
Defunct processes are reported.
ps(1), regex(7), signal(7), sigqueue(3), killall(1), skill(1), kill(1), kill(2)
Kjetil Torgrim Homme ⟨kjetilho@ifi.uio.no⟩
APG(1)                             User Manual                            APG(1)
apg - generates several random passwords
apg [-a algorithm] [-M mode] [-E char_string] [-n num_of_pass] [-m min_pass_len] [-x max_pass_len] [-r dictfile] [-b filter_file] [-p min_substr_len] [-s] [-c cl_seed] [-d] [-y] [-l] [-t] [-q] [-h] [-v]
apg generates several random passwords. It uses several password generation algorithms (currently two) and a built-in pseudo random number generator.
Default algorithm is pronounceable password generation algorithm designed by Morrie Gasser and described in A Random Word Generator For Pronounceable Passwords National Technical Information Service (NTIS) AD- A-017676.  The original paper is very old and had never been put online, so I have to use NIST implementation described in FIPS-181.
Another algorithm is simple random character generation algorithm, but it uses four user-defined symbol sets to produce random password. It means that user can choose type of symbols that should appear in password. Symbol sets are: numeric symbol set (0,...,9) , capital letters symbol set (A,...,Z) , small letters symbol set (a,...,z) and special symbols symbol set (#,@,!,...).
Built-in pseudo random number generator is an implementation of algorithm described in Appendix C of ANSI X9.17 or RFC1750 with exception that it uses CAST or SHA-1 instead of Triple DES.  It uses local time with precision of microseconds (see gettimeofday(2)) and /dev/random (if available) to produce initial random seed.
apg also have the ability to check generated password quality using dictionary. You can use this ability if you specify command-line options -r dictfile or -b filtername where dictfile is the dictionary file name and filtername is the name of Bloom filter file. In that dictionary you may place words (one per line) that should not appear as generated passwords. For example: user names, common words, etc. You even can use one of the dictionaries that come with dictionary password crackers. Bloom filter file should be created with apgbfm(1) utility included in apg distribution. In future releases I plan to implement some other techniques to check passwords (like pattern check) just to make life easier.
Password generation modes options -a algorithm use algorithm for password generation. 0 - (default) pronounceable password generation 1 - random character password generation
-n num_of_pass generate num_of_pass number of passwords. Default is 6.
-m min_pass_len generate password with minimum length min_pass_len.  If min_pass_len > max_pass_len then max_pass_len = min_pass_len. Default minimum password length is 8.
-x max_pass_len generate password with maximum length max_pass_len.  If min_pass_len > max_pass_len then max_pass_len = min_pass_len. Default maximum password length is 10.
-M mode Use symbolsets specified with mode for password generation.  mode is a text string consisting of characters S, s, N, n, C, c, L, l. Where:
S      generator must use special symbol set for every generated password.
s      generator should use special symbol set for password generation.
N      generator must use numeral symbol set for every generated password.
n      generator should use numeral symbol set for password generation.
C      generator must use capital symbol set for every generated password.
c      generator should use capital symbol set for password generation.
L      generator must use small letters symbol set for every generated password (always present if pronounceable password generation algorithm is used).
l      generator should use small letters symbol set for password generation.
R,r    not supported any more. Use -E char_string option instead. mode can not be more than 4 characters in length.
Note: Usage of L, M, N, C will slow down password generation process.
Examples: -M sncl or -M SNCL or -M Cn
-E char_string exclude characters in char_string from password generation process (in pronounceable password generation mode you can not exclude small letters). To include special symbols that can be recognized by shell (apostrophe, quotes, dollar sign, etc.) in char_string use the backslashed versions.
Command apg -a 1 -M n -n 3 -m 8 -E 23456789 will generate a set of passwords that will look like this 10100110 01111000 11011101
Command apg -a 1 -M nc -n 3 -m 26 -E GHIJKLMNOPQRSTUVWXYZ will generate a set of passwords that will look like this 16A1653CD4DE5E7BD9584A3476 C8F78E06944AFD57FB9CB882BC 8C8DF37CD792D36D056BBD5002
Password quality control options -r dictfile check generated passwords for their appearance in dictfile
-b filter_file check generated passwords for their appearance in filter_file. filter_file should be created with apgbfm(1) utility.
-p min_substr_len this option tells apg(1) to check every substring of the generated password for appearance in filter_file. If any of such substrings would be found in the filter_file then generated password would be rejected and apg(1) will generate another one.  min_substr_len specifies minimum substring length to check.  This option is active only if -b option is defined.
Pseudo random number generator options -s     ask user for random sequence for password generation
-c cl_seed use cl_seed as a random seed for password generation. I use it when i have to generate passwords in a shell script.
Password output options -d     do NOT use any delimiters between generated passwords. I use it when i have to generate passwords in a shell script.
-y     print generated passwords and crypted passwords (see man crypt(3))
-q     quiet mode (do not print warnings)
-l     spell genetated passwords. Useful when you want to read generated password by telephone. WARNING: Think twice before read your password by phone.
-t     print pronunciation for generated pronounceable password
-h     print help information and exit
-v     print version information and exit
apg -a 0 -M sncl -n 6 -x 10 -m 8 (new style)
If you want to generate really secure passwords, you should use option -s. To simplify apg usage, you can write a small shell script. For example: [begin]----> pwgen.sh #!/bin/sh /usr/local/bin/apg -m 8 -x 12 -s [ end ]----> pwgen.sh
On successful completion of its task, apg will complete with exit code 0. An exit code of -1 indicates an error occurred.  Textual errors are written to the standard error stream.
If /dev/random is not available, apg will display a message about it.
None.  If you've found one, please send bug description to the author.
apgd(8), apgbfm(1)
Adel I. Mirzazhanov, <a-del@iname.com> Project home page: http://www.adel.nursat.kz/apg/
PW-CAT(1)                    General Commands Manual                   PW-CAT(1)
pw-cat - Play and record media with PipeWire
pw-cat [options] [FILE] pw-play [options] [FILE] pw-record [options] [FILE] pw-midiplay [options] [FILE] pw-midirecord [options] [FILE]
pw-cat is a simple tool for playing back or capturing raw or encoded media files on a PipeWire server. It understands all audio file formats supported by libsndfile.
-v | --verbose Verbose operation.
-R | --remote=NAME The name the remote instance to connect to. If left unspecified, a connection is made to the default PipeWire instance.
-p | --playback Playback mode. Read data from the specified file, and play it back. If the tool is called under the name pw-play or pw-midiplay this is the default.
-r | --record Recording mode. Capture data and write it to the specified file. If the tool is called under the name pw-record or pw-midirecord this is the default.
-m | --midi MIDI mode. FILE is a MIDI file. If the tool is called under the name pw-midiplay or pw-midirecord this is the default.
--media-type=VALUE Set the media type property (default Audio/Midi depending on mode).  The media type is used by the session manager to select a suitable target to link to.
--media-category=VALUE Set the media category property (default Playback/Capture depending on mode).  The media type is used by the session manager to select a suitable target to link to.
--media-role=VALUE Set the media role property (default Music).  The media type is used by the session manager to select a suitable target to link to.
--target=VALUE Set a node target (default auto). The value can be:
auto   Automatically select (Default)
0      Don't try to link this node
<id>   The id of a target node
--latency=VALUE[units] Set the node latency (default 100ms)
The latency determines the minimum amount of time it takes for a sample to travel from application to device (playback) and from device to application (capture).
The latency determines the size of the buffers that the application will be able to fill. Lower latency means smaller buffers but higher overhead. Higher latency means larger buffers and lower overhead.
Units can be s for seconds, ms for milliseconds, us for microseconds, ns for nanoseconds.  If no units are given, the latency value is samples with the samplerate of the file.
--list-targets List the available targets for --target
-q | --quality=VALUE Resampler quality. When the samplerate of the source or destination file does not match the samplerate of the server, the data will be resampled. Higher quality uses more CPU. Values between 0 and 15 are allowed, the default quality is 4.
--rate=VALUE The sample rate, default 48000.
--channels=VALUE The number of channels, default 2.
--channel-map=VALUE The channelmap. Possible values include: mono, stereo, surround-21, quad, surround-22, surround-40, surround-31, surround-41, surround-50, surround-51, surround-51r, surround-70, surround-71 or a comma separated list of channel names: FL, FR, FC, LFE, SL, SR, FLC, FRC, RC, RL, RR, TC, TFL, TFC, TFR, TRL, TRC, TRR, RLC, RRC, FLW, FRW, LFE2, FLH, FCH, FRH, TFLC, TFRC, TSL, TSR, LLFR, RLFE, BC, BLC, BRC
--format=VALUE The sample format to use. One of: s8, s16 (default), s24, s32, f32, f64.
--volume=VALUE The stream volume, default 1.000.
The PipeWire Developers <‐ https://gitlab.freedesktop.org/pipewire/pipewire/issues>; PipeWire is available from https://pipewire.org
PipeWire(1), pw-mon(1),
VGSCAN(8)                    System Manager's Manual                   VGSCAN(8)
vgscan â€” Search for all volume groups
vgscan [ option_args ]
vgscan scans all supported LVM block devices in the system for VGs.
vgscan [    --ignorelockingfailure ] [    --mknodes ] [    --notifydbus ] [    --reportformat basic|json ] [ COMMON_OPTIONS ]