neulab/tldr huggingface dataset:
ca  Certificate Authority (CA) Management.
ciphers Cipher Suite Description Determination.
cms CMS (Cryptographic Message Syntax) utility.
crl Certificate Revocation List (CRL) Management.
crl2pkcs7 CRL to PKCS#7 Conversion.
dgst Message Digest Calculation.
dh  Diffie-Hellman Parameter Management.  Obsoleted by dhparam(1).
dhparam Generation and Management of Diffie-Hellman Parameters. Superseded by genpkey(1) and pkeyparam(1).
dsa DSA Data Management.
dsaparam DSA Parameter Generation and Management. Superseded by genpkey(1) and pkeyparam(1).
ec  EC (Elliptic curve) key processing.
ecparam EC parameter manipulation and generation.
enc Encoding with Ciphers.
engine Engine (loadable module) information and manipulation.
errstr Error Number to Error String Conversion.
gendh Generation of Diffie-Hellman Parameters.  Obsoleted by dhparam(1).
gendsa Generation of DSA Private Key from Parameters. Superseded by genpkey(1) and pkey(1).
genpkey Generation of Private Key or Parameters.
genrsa Generation of RSA Private Key. Superseded by genpkey(1).
nseq Create or examine a Netscape certificate sequence.
ocsp Online Certificate Status Protocol utility.
passwd Generation of hashed passwords.
pkcs12 PKCS#12 Data Management.
pkcs7 PKCS#7 Data Management.
pkcs8 PKCS#8 format private key conversion tool.
pkey Public and private key management.
pkeyparam Public key algorithm parameter management.
pkeyutl Public key algorithm cryptographic operation utility.
prime Compute prime numbers.
rand Generate pseudo-random bytes.
rehash Create symbolic links to certificate and CRL files named by the hash values.
req PKCS#10 X.509 Certificate Signing Request (CSR) Management.
rsa RSA key management.
rsautl RSA utility for signing, verification, encryption, and decryption. Superseded by  pkeyutl(1).
s_client This implements a generic SSL/TLS client which can establish a transparent connection to a remote server speaking SSL/TLS. It's intended for testing purposes only and provides only rudimentary interface functionality but internally uses mostly all functionality of the OpenSSL ssl library.
s_server This implements a generic SSL/TLS server which accepts connections from remote clients speaking SSL/TLS. It's intended for testing purposes only and provides only rudimentary interface functionality but internally uses mostly all functionality of the OpenSSL ssl library.  It provides both an own command line oriented protocol for testing SSL functions and a simple HTTP response facility to emulate an SSL/TLS-aware webserver.
s_time SSL Connection Timer.
sess_id SSL Session Data Management.
smime S/MIME mail processing.
speed Algorithm Speed Measurement.
spkac SPKAC printing and generating utility.
srp Maintain SRP password file.
storeutl Utility to list and display certificates, keys, CRLs, etc.
ts  Time Stamping Authority tool (client/server).
verify X.509 Certificate Verification.
version OpenSSL Version Information.
x509 X.509 Certificate Data Management.
Message Digest Commands blake2b512 BLAKE2b-512 Digest
blake2s256 BLAKE2s-256 Digest
md2 MD2 Digest
md4 MD4 Digest
md5 MD5 Digest
mdc2 MDC2 Digest
rmd160 RMD-160 Digest
sha1 SHA-1 Digest
sha224 SHA-2 224 Digest
sha256 SHA-2 256 Digest
sha384 SHA-2 384 Digest
sha512 SHA-2 512 Digest
sha3-224 SHA-3 224 Digest
sha3-256 SHA-3 256 Digest
sha3-384 SHA-3 384 Digest
sha3-512 SHA-3 512 Digest
shake128 SHA-3 SHAKE128 Digest
shake256 SHA-3 SHAKE256 Digest
sm3 SM3 Digest
Encoding and Cipher Commands The following aliases provide convenient access to the most used encodings and ciphers.
Depending on how OpenSSL was configured and built, not all ciphers listed here may be present. See enc(1) for more information and command usage.
aes128, aes-128-cbc, aes-128-cfb, aes-128-ctr, aes-128-ecb, aes-128-ofb AES-128 Cipher
aes192, aes-192-cbc, aes-192-cfb, aes-192-ctr, aes-192-ecb, aes-192-ofb AES-192 Cipher
aes256, aes-256-cbc, aes-256-cfb, aes-256-ctr, aes-256-ecb, aes-256-ofb AES-256 Cipher
aria128, aria-128-cbc, aria-128-cfb, aria-128-ctr, aria-128-ecb, aria-128-ofb Aria-128 Cipher
aria192, aria-192-cbc, aria-192-cfb, aria-192-ctr, aria-192-ecb, aria-192-ofb Aria-192 Cipher
aria256, aria-256-cbc, aria-256-cfb, aria-256-ctr, aria-256-ecb, aria-256-ofb Aria-256 Cipher
base64 Base64 Encoding
bf, bf-cbc, bf-cfb, bf-ecb, bf-ofb Blowfish Cipher
camellia128, camellia-128-cbc, camellia-128-cfb, camellia-128-ctr, camellia-128-ecb, camellia-128-ofb Camellia-128 Cipher
camellia192, camellia-192-cbc, camellia-192-cfb, camellia-192-ctr, camellia-192-ecb, camellia-192-ofb Camellia-192 Cipher
camellia256, camellia-256-cbc, camellia-256-cfb, camellia-256-ctr, camellia-256-ecb, camellia-256-ofb Camellia-256 Cipher
cast, cast-cbc CAST Cipher
cast5-cbc, cast5-cfb, cast5-ecb, cast5-ofb CAST5 Cipher
chacha20 Chacha20 Cipher
des, des-cbc, des-cfb, des-ecb, des-ede, des-ede-cbc, des-ede-cfb, des- ede-ofb, des-ofb DES Cipher
des3, desx, des-ede3, des-ede3-cbc, des-ede3-cfb, des-ede3-ofb Triple-DES Cipher
idea, idea-cbc, idea-cfb, idea-ecb, idea-ofb IDEA Cipher
rc2, rc2-cbc, rc2-cfb, rc2-ecb, rc2-ofb RC2 Cipher
rc4 RC4 Cipher
rc5, rc5-cbc, rc5-cfb, rc5-ecb, rc5-ofb RC5 Cipher
seed, seed-cbc, seed-cfb, seed-ecb, seed-ofb SEED Cipher
sm4, sm4-cbc, sm4-cfb, sm4-ctr, sm4-ecb, sm4-ofb SM4 Cipher
Details of which options are available depend on the specific command. This section describes some common options with common behavior.
Common Options -help Provides a terse summary of all options.
Pass Phrase Options Several commands accept password arguments, typically using -passin and -passout for input and output passwords respectively. These allow the password to be obtained from a variety of sources. Both of these options take a single argument whose format is described below. If no password argument is given and a password is required then the user is prompted to enter one: this will typically be read from the current terminal with echoing turned off.
Note that character encoding may be relevant, please see passphrase-encoding(7).
pass:password The actual password is password. Since the password is visible to utilities (like 'ps' under Unix) this form should only be used where security is not important.
env:var Obtain the password from the environment variable var. Since the environment of other processes is visible on certain platforms (e.g. ps under certain Unix OSes) this option should be used with caution.
file:pathname The first line of pathname is the password. If the same pathname argument is supplied to -passin and -passout arguments then the first line will be used for the input password and the next line for the output password. pathname need not refer to a regular file: it could for example refer to a device or named pipe.
fd:number Read the password from the file descriptor number. This can be used to send the data via a pipe for example.
stdin Read the password from standard input.
asn1parse(1), ca(1), ciphers(1), cms(1), config(5), crl(1), crl2pkcs7(1), dgst(1), dhparam(1), dsa(1), dsaparam(1), ec(1), ecparam(1), enc(1), engine(1), errstr(1), gendsa(1), genpkey(1), genrsa(1), nseq(1), ocsp(1), passwd(1), pkcs12(1), pkcs7(1), pkcs8(1), pkey(1), pkeyparam(1), pkeyutl(1), prime(1), rand(1), rehash(1), req(1), rsa(1), rsautl(1), s_client(1), s_server(1), s_time(1), sess_id(1), smime(1), speed(1), spkac(1), srp(1), storeutl(1), ts(1), verify(1), version(1), x509(1), crypto(7), ssl(7), x509v3_config(5)
The list-XXX-algorithms pseudo-commands were added in OpenSSL 1.0.0; For notes on the availability of other commands, see their individual manual pages.
Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved.
TSC(1)                            User Commands                           TSC(1)
tsc - TypeScript compiler
tsc --outFile file.js file.ts
tsc @args.txt
--allowJs Allow javascript files to be compiled.
--allowSyntheticDefaultImports Allow default imports from modules with no default export. This does not affect code emit, just typechecking.
--allowUnreachableCode Do not report errors on unreachable code.
--allowUnusedLabels Do not report errors on unused labels.
--baseUrl Base directory to resolve non-absolute module names.
-d, --declaration Generates corresponding '.d.ts' file.
--experimentalDecorators Enables experimental support for ES7 decorators.
--forceConsistentCasingInFileNames Disallow inconsistently-cased references to the same file.
--init Initializes a TypeScript project and creates a tsconfig.json file.
--jsx KIND Specify JSX code generation: 'preserve' or 'react'
--lib  Specify library files to be included in the compilation: 'es5' 'es6' 'es2015' 'es7' 'es2016' 'es2017' 'dom' 'webworker' 'scripthost' 'es2015.core' 'es2015.collection' 'es2015.generator' 'es2015.iterable' 'es2015.promise' 'es2015.proxy' 'es2015.reflect' 'es2015.symbol' 'es2015.symbol.wellknown' 'es2016.array.include' 'es2017.object' 'es2017.sharedmemory'
--mapRoot LOCATION Specify the location where debugger should locate map files instead of generated locations.
--maxNodeModuleJsDepth The maximum dependency depth to search under node_modules and load JavaScript files
-m KIND, --module KIND Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'
--moduleResolution Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6).
--newLine NEWLINE Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).
--noEmit Do not emit outputs.
--noEmitOnError Do not emit outputs if any errors were reported.
--noFallthroughCasesInSwitch Report errors for fallthrough cases in switch statement.
--noImplicitAny Raise error on expressions and declarations with an implied 'any' type.
--noImplicitReturns Report error when not all code paths in function return a value.
--noImplicitThis Raise error on 'this' expressions with an implied 'any' type.
--noImplicitUseStrict Do not emit 'use strict' directives in module output.
--noUnusedLocals Report errors on unused locals.
--noUnusedParameters Report errors on unused parameters.
--outDir DIRECTORY Redirect output structure to the directory.
--outFile FILE Concatenate and emit output to single file.
--preserveConstEnums Do not erase const enum declarations in generated code.
--pretty Stylize errors and messages using color and context. (experimental)
-p DIRECTORY, --project DIRECTORY Compile the project in the given directory.
--reactNamespace Specify the object invoked for createElement and __spread when targeting 'react' JSX emit
--removeComments Do not emit comments to output.
--rootDir LOCATION Specify the root directory of input files. Use to control the output directory structure with --outDir.
--skipLibCheck Skip type checking of declaration files.
--sourceMap Generates corresponding '.map' file.
--sourceRoot LOCATION Specify the location where debugger should locate TypeScript files instead of source locations.
--strictNullChecks Enable strict null checks.
--suppressImplicitAnyIndexErrors Suppress noImplicitAny errors for indexing objects lacking index signatures.
-t VERSION, --target VERSION Specify ECMAScript target version: 'ES3' (default), 'ES5', or 'ES2015'
--traceResolution Enable tracing of the name resolution process.
--types Type declaration files to be included in compilation.
-v, --version Print the compiler's version.
-w, --watch Watch input files.
@<file> Insert command line options and files from a file.
docker-exec - Run a command in a running container
docker exec [OPTIONS] CONTAINER COMMAND [ARG...]
Alias for docker container exec.
-d, --detach[=false]      Detached mode: run command in the background
-e, --env=      Set environment variables
--env-file=      Read in a file of environment variables
-h, --help[=false]      help for exec
-i, --interactive[=false]      Keep STDIN open even if not attached
--privileged[=false]      Give extended privileges to the command
-t, --tty[=false]      Allocate a pseudo-TTY
-u, --user=""      Username or UID (format: [:])
-w, --workdir=""      Working directory inside the container
CMatrix(1)                   General Commands Manual                  CMatrix(1)
cmatrix [-abBflohnsmVx] [-u update] [-C color]
Shows a scrolling 'Matrix' like screen in Linux
OPTIONS -a     Asynchronous scroll
-b     Bold characters on
-B     All bold characters (overrides -b)
-f     Force the linux $TERM type to be on
-l     Linux mode (sets "matrix.fnt" font in console)
-o     Use old-style scrolling
-h, -? Print usage and exit
-n     No bold characters (overrides -b and -B)
-s     "Screensaver" mode, exits on first keystroke
-m     "Lambda" mode, every character becomes a lambda
-x     X window mode, use if your xterm is using mtx.pcf
-V     Print version information and exit
-u delay Screen update delay 0 - 9, default 4
-C color Use this color for matrix (default green).  Valid colors are green, red, blue, white, yellow, cyan, magenta and black.
KEYSTROKES The following keystrokes are available during execution (unavailable in -s mode)
a      Toggle asynchronous scroll
b      Random bold characters
B      All bold characters
n      Turn off bold characters
0-9    Adjust update speed
! @ # $ % ^ & ) Change the color of the matrix to the corresponding color: ! - red, @ - green, # - yellow, $ - blue, % - magenta, ^ - cyan, & - white, ) - black.
q      Quit the program
This program is very CPU intensive.  Don't be surprised if it eats up over 40% of your CPU at times.
http://www.github.com/abishekvashok/cmatrix
FLOW(1)                      General Commands Manual                     FLOW(1)
flow - show subroutine dependence of Fortran77 programs
flow  [-hCcFfRSsUVW]  file(s)
flow is a utility which shows the SUBROUTINE dependence of a Fortran77 program. It lists the called routine names and indicates their CALL level by indention.
CALL statements in the case of an IF condition are also reported but not separately marked.
By default no warning is given if a called SUBROUTINE is not found in the input files. This gives the possibility to reduce the output by omitting some file names including further subroutine-calls.
In addition a little statistic with the count of total, comment and source-code lines is presented. Further the number of IF statements is also given as the number of declared SUBROUTINE procedures and CALL sequences.
There is no limitation of the number of given files. By use of an appropriate shell wildcards like * or ?  can be used in the name(s) of the file(s).
-h   Print a usage message on standard output and exit.
-C   Print each CALL statement which is found in input.
-c   Each found CALL of a SUBROUTINE is reported in a file named FLOW.CALL with the name of the file where it was called and the line number. The file FLOW.CALL may be sorted in alphabetically order by the sort command.
-F   Print the FILE name of input which is actually on work.
-f   The output of the dependence is written on a file with the name of the program and the ending .FLOW instead of the screen.
-r <name> Set a new starting point. Instead of starting at the PROGRAM the work is done only for the SUBROUTINE <name>. This option is useful to check all called routines out of this one.
-R   Omit recursive hanging. Each called SUBROUTINE is printed with all subsequent CALL statements only the first time it is invoked. At the later times only the root SUBROUTINE (=starting point) is given.
-S   Print each SUBROUTINE statement which is found in input.
-s   Each found declaration of a SUBROUTINE is reported in a file named FLOW.SUBS with the name of the file where it is declared together with the line number. The file FLOW.SUBS may be sorted in alphabetically order by the sort command.
-U   If a SUBROUTINE is called which is not found in the input, a warning message is given.  Such a case can occur for example by system calls like CALL EXIT
-V   Print version number of flow and name of author. Finally the program ends.
-W   A warning is given if a line exceeds a length of 72 characters. Spaces at the end of the line are thereby not counted. Comment lines are not controlled.
KNOWN BUGS? Recursive hanging is omitted by the option -R which has the effect, that only the first time a called SUBROUTINE is followed up to the last CALL. However if the call starts out of another level of the program, e.g. an deeper lying SUBROUTINE the consecutively following CALLs will not be printed again. This obviously shortens the output and may lead to some confusion. Be cautious!
IF ... THEN ... ELSEIF(...)CALL statements are not considered to appeare in the code. (Is such a construction allowed?)
flow -U *.f | less All files with suffix .f of the current directory are used as input. A warning message will be given if a subroutine is called which is not part of any input file. The output is piped to less(1) so you can browse up and down through it during it grows.
flow -V The number of the actual version is printed.
flow -h You get a little help message.
flow -s *.f ; sort FLOW.SUBS > SUBS.SORT Each found subroutine in all fortran files of the actual directory is written to the file FLOW.SUBS together with the file name and line number where the declaration appears. After this the sort Program is called to sort the names of the subroutines in alphabetically order. The file SUBS.SORT contains the final result.
flow -scFfUW *.f This is maybe the best combination of all Options if the program is spread over several files.
Dirk Geschke <geschke@physik.uni-kassel.de>
A formatted output into special file formats like TeX/LaTeX or Postscript is planned?
bash(1), csh(1), f77(1), ksh(1), less(1), sort(1), tcsh(1)
CALENDAR(1)                BSD General Commands Manual               CALENDAR(1)
calendar — reminder service
calendar [-abw] [-A num] [-B num] [-l num] [-e num] [-f calendarfile] [-t [[[cc]yy]mm]dd]
The calendar utility checks the current directory or the directory specified by the CALENDAR_DIR environment variable for a file named calendar and displays lines that begin with either today's date or tomorrow's.  On Fridays, events on Friday through Monday are displayed.
-A num  Print lines from today and next num days (forward, future). Defaults to one (same as -l).
-a      Process the “calendar” files of all users and mail the results to them.  This requires superuser privileges.
-B num  Print lines from today and previous num days (backward, past).
-b      Enforce special date calculation mode for Cyrillic calendars.
-l num  Print lines from today and next num days (forward, future). Defaults to one (same as -A).
-e num  Print lines from today and next num days, only if today is Friday (forward, future).  Defaults to two, which causes calendar to print entries through the weekend on Fridays.
-f calendarfile Use calendarfile as the default calendar file.  If this file is not accessible, the system-wide default is used.
-t [[[cc]yy]mm]dd Act like the specified value is “today” instead of using the current date.  If yy is specified, but cc is not, a value for yy between 69 and 99 results in a cc value of 19.  Otherwise, a cc value of 20 is used.
-w      Print day of the week name in front of each event.
To handle calendars in your national code table you can specify “LANG=<locale_name>” in the calendar file as early as possible.  To handle national Easter names in the calendars, “Easter=<national_name>” (for Catholic Easter) or “Paskha=<national_name>” (for Orthodox Easter) can be used.
A special locale name exists: ‘utf-8’.  Specifying “LANG=utf-8” indicates that the dates will be read using the C locale, and the descriptions will be encoded in UTF-8.  This is usually used for the distributed calendar files.  The “CALENDAR” variable can be used to specify the style.  Only ‘Julian’ and ‘Gregorian’ styles are currently supported.  Use “CALENDAR=” to return to the default (Gregorian).
To enforce special date calculation mode for Cyrillic calendars you should specify “LANG=<local_name>” and “BODUN=<bodun_prefix>” where <local_name> can be ru_RU.UTF-8, uk_UA.UTF-8 or by_BY.UTF-8.
Note that the locale is reset to the user's default for each new file that is read.  This is so that locales from one file do not accidentally carry over into another file.
Other lines should begin with a month and day.  They may be entered in almost any format, either numeric or as character strings.  If proper locale is set, national months and weekdays names can be used.  A single asterisk (‘*’) matches every month.  A day without a month matches that day of every week.  A month without a day matches the first of that month.  Two numbers default to the month followed by the day.  Lines with leading tabs default to the last entered date, allowing multiple line specifications for a single date.  “Easter” (may be followed by a positive or negative integer) is Easter for this year.  “Paskha” (may be followed by a positive or negative integer) is Orthodox Easter for this year.  Weekdays may be followed by “-4” ... “+5” (aliases last, first, second, third, fourth) for moving events like “the last Monday in April”.
By convention, dates followed by an asterisk (‘*’) are not fixed, i.e., change from year to year.
Day descriptions start after the first <tab> character in the line; if the line does not contain a <tab> character, it isn't printed out.  If the first character in the line is a <tab> character, it is treated as the continuation of the previous description.
The calendar file is preprocessed by cpp(1), allowing the inclusion of shared files such as company holidays or meetings.  If the shared file is not referenced by a full pathname, cpp(1) searches in the current (or home) directory first, and then in the directory /etc/calendar, and finally in /usr/share/calendar.  Empty lines and lines protected by the C commenting syntax (/* ... */) are ignored.
Some possible calendar entries (a \t sequence denotes a <tab> character):
LANG=C Easter=Ostern
#include <calendar.usholiday> #include <calendar.birthday>
6/15\tJune 15 (if ambiguous, will default to month/day). Jun. 15\tJune 15. 15 June\tJune 15. Thursday\tEvery Thursday. June\tEvery June 1st. 15 *\t15th of every month.
May Sun+2\tsecond Sunday in May (Muttertag) 04/SunLast\tlast Sunday in April, \tsummer time in Europe Easter\tEaster Ostern-2\tGood Friday (2 days before Easter) Paskha\tOrthodox Easter
calendar              File in current directory. ~/.calendar           Directory in the user's home directory (which calendar changes into, if it exists). ~/.calendar/calendar  File to use if no calendar file exists in the current directory. ~/.calendar/nomail    calendar will not send mail if this file exists. calendar.all          International and national calendar files. calendar.birthday     Births and deaths of famous (and not-so-famous) people. calendar.canada       Canadian holidays. calendar.christian    Christian holidays (should be updated yearly by the local system administrator so that roving holidays are set correctly for the current year). calendar.computer     Days of special significance to computer people. calendar.croatian     Croatian calendar. calendar.discord      Discordian calendar (all rites reversed). calendar.fictional    Fantasy and fiction dates (mostly LOTR). calendar.french       French calendar. calendar.german       German calendar. calendar.history      Miscellaneous history. calendar.holiday      Other holidays (including the not-well-known, obscure, and really obscure). calendar.judaic       Jewish holidays (should be updated yearly by the local system administrator so that roving holidays are set correctly for the current year). calendar.music        Musical events, births, and deaths (strongly oriented toward rock 'n' roll). calendar.nz           New Zealand calendar. calendar.openbsd      OpenBSD related events. calendar.pagan        Pagan holidays, celebrations and festivals. calendar.russian      Russian calendar. calendar.space        Cosmic history. calendar.uk           UK calendar. calendar.ushistory    U.S. history. calendar.usholiday    U.S. holidays. calendar.world        World wide calendar.
at(1), cal(1), cpp(1), mail(1), cron(8)
The calendar program previously selected lines which had the correct date anywhere in the line.  This is no longer true: the date is only recognized when it occurs at the beginning of a line.
The calendar command will only display lines that use a <tab> character to separate the date and description, or that begin with a <tab>.  This is different than in previous releases.
The Fl t flag argument syntax is from the original FreeBSD calendar program.
The -l and -e flags are Debian-specific enhancements.  Option -e used to be called -w in Debian, but this option is now used differently by upstream. Also, the original calendar program did not accept 0 as an argument to the -A flag.
Using ‘utf-8’ as a locale name is a Debian-specific enhancement.
A calendar command appeared in Version 7 AT&T UNIX.
calendar doesn't handle all Jewish holidays or moon phases.
kubectl get - Display one or many resources
kubectl get [OPTIONS]
Display one or many resources.
Prints a table of the most important information about the specified resources. You can filter the list using a label selector and the --selector flag. If the desired resource type is namespaced you will only see results in your current namespace unless you pass --all-namespaces.
Uninitialized objects are not shown unless --include-uninitialized is passed.
By specifying the output as 'template' and providing a Go template as the value of the --template flag, you can filter the attributes of the fetched resources.
--field-selector=""      Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector key1=value1,key2=value2). The server only supports a limited number of field queries per type.
-f, --filename=[]      Filename, directory, or URL to files identifying the resource to get from a server.
--ignore-not-found=false      If the requested object does not exist the command will return exit code 0.
-L, --label-columns=[]      Accepts a comma separated list of labels that are going to be presented as columns. Names are case-sensitive. You can also use multiple flag options like -L label1 -L label2...
--no-headers=false      When using the default or custom-column output format, don't print headers (default print headers).
-o, --output=""      Output format. One of: json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file|custom-columns-file|custom-columns|wide See custom columns [https://kubernetes.io/docs/reference/kubectl/overview/#custom-columns], golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [https://kubernetes.io/docs/reference/kubectl/jsonpath/].
--output-watch-events=false      Output watch event objects when --watch or --watch-only is used. Existing objects are output as initial ADDED events.
--raw=""      Raw URI to request from the server.  Uses the transport specified by the kubeconfig file.
--server-print=true      If true, have the server return the appropriate table output. Supports extension APIs and CRDs.
--show-kind=false      If present, list the resource type for the requested object(s).
--show-labels=false      When printing, show all labels as the last column (default hide labels column)
--sort-by=""      If non-empty, sort list types using this field specification.  The field specification is expressed as a JSONPath expression (e.g. '{.metadata.name}'). The field in the API resource specified by this JSONPath expression must be an integer or a string.
--use-openapi-print-columns=false      If true, use x-kubernetes-print-column metadata (if present) from the OpenAPI schema for displaying a resource.
-w, --watch=false      After listing/getting the requested object, watch for changes. Uninitialized objects are excluded if no object name is provided.
--watch-only=false      Watch for changes to the requested object(s), without listing/getting first.
# List all pods in ps output format kubectl get pods
# List all pods in ps output format with more information (such as node name) kubectl get pods -o wide
# List a single replication controller with specified NAME in ps output format kubectl get replicationcontroller web
# List deployments in JSON output format, in the "v1" version of the "apps" API group kubectl get deployments.v1.apps -o json
# List a single pod in JSON output format kubectl get -o json pod web-pod-13je7
# List a pod identified by type and name specified in "pod.yaml" in JSON output format kubectl get -f pod.yaml -o json
# List resources from a directory with kustomization.yaml - e.g. dir/kustomization.yaml kubectl get -k dir/
# Return only the phase value of the specified pod kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}
# List resource information in custom columns kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image
# List all replication controllers and services together in ps output format kubectl get rc,services
# List one or more resources by their type and names kubectl get rc/web service/frontend pods/web-pod-13je7
SYSTEMD-ANALYZE(1)               systemd-analyze              SYSTEMD-ANALYZE(1)
systemd-analyze - Analyze and debug system manager
systemd-analyze [OPTIONS...] [time]
systemd-analyze [OPTIONS...] blame
systemd-analyze [OPTIONS...] critical-chain [UNIT...]
systemd-analyze [OPTIONS...] dump
systemd-analyze [OPTIONS...] plot [>file.svg]
systemd-analyze [OPTIONS...] dot [PATTERN...] [>file.dot]
systemd-analyze [OPTIONS...] unit-paths
systemd-analyze [OPTIONS...] exit-status [STATUS...]
systemd-analyze [OPTIONS...] capability [CAPABILITY...]
systemd-analyze [OPTIONS...] condition CONDITION...
systemd-analyze [OPTIONS...] syscall-filter [SET...]
systemd-analyze [OPTIONS...] calendar SPEC...
systemd-analyze [OPTIONS...] timestamp TIMESTAMP...
systemd-analyze [OPTIONS...] timespan SPAN...
systemd-analyze [OPTIONS...] cat-config NAME|PATH...
systemd-analyze [OPTIONS...] verify [FILE...]
systemd-analyze [OPTIONS...] security UNIT...
systemd-analyze may be used to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager, and to verify the correctness of unit files. It is also used to access special functions useful for advanced system manager debugging.
If no command is passed, systemd-analyze time is implied.
systemd-analyze time This command prints the time spent in the kernel before userspace has been reached, the time spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time normal system userspace took to initialize. Note that these measurements simply measure the time passed up to the point where all system services have been spawned, but not necessarily until they fully finished initialization or the disk is idle.
Example 1. Show how long the boot took
# in a container $ systemd-analyze time Startup finished in 296ms (userspace) multi-user.target reached after 275ms in userspace
# on a real machine $ systemd-analyze time Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s multi-user.target reached after 47.820s in userspace
systemd-analyze blame This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. Note that the output might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame doesn't display results for services with Type=simple, because systemd considers such services to be started immediately, hence no measurement of the initialization delays can be done. Also note that this command only shows the time units took for starting up, it does not show how long unit jobs spent in the execution queue. In particular it shows the time units spent in "activating" state, which is not defined for units such as device units that transition directly from "inactive" to "active". This command hence gives an impression of the performance of program code, but cannot accurately reflect latency introduced by waiting for hardware and similar events.
Example 2. Show which units took the most time during boot
$ systemd-analyze blame 32.875s pmlogger.service 20.905s systemd-networkd-wait-online.service 13.299s dev-vda1.device ... 23ms sysroot.mount 11ms initrd-udevadm-cleanup-db.service 3ms sys-kernel-config.mount
systemd-analyze critical-chain [UNIT...] This command prints a tree of the time-critical chain of units (for each of the specified UNITs or for the default target otherwise). The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. Note that the output might be misleading as the initialization of services might depend on socket activation and because of the parallel execution of units. Also, similar to the blame command, this only takes into account the time units spent in "activating" state, and hence does not cover units that never went through an "activating" state (such as device units that transition directly from "inactive" to "active"). Moreover it does not show information on jobs (and in particular not jobs that timed out).
Example 3. systemd-analyze critical-chain
$ systemd-analyze critical-chain multi-user.target @47.820s â””â”€pmie.service @35.968s +548ms â””â”€pmcd.service @33.715s +2.247s â””â”€network-online.target @33.712s â””â”€systemd-networkd-wait-online.service @12.804s +20.905s â””â”€systemd-networkd.service @11.109s +1.690s â””â”€systemd-udevd.service @9.201s +1.904s â””â”€systemd-tmpfiles-setup-dev.service @7.306s +1.776s â””â”€kmod-static-nodes.service @6.976s +177ms â””â”€systemd-journald.socket â””â”€system.slice â””â”€-.slice
systemd-analyze dump This command outputs a (usually very long) human-readable serialization of the complete server state. Its format is subject to change without notice and should not be parsed by applications.
Example 4. Show the internal state of user manager
$ systemd-analyze --user dump Timestamp userspace: Thu 2019-03-14 23:28:07 CET Timestamp finish: Thu 2019-03-14 23:28:07 CET Timestamp generators-start: Thu 2019-03-14 23:28:07 CET Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET -> Unit proc-timer_list.mount: Description: /proc/timer_list ... -> Unit default.target: Description: Main user target ...
systemd-analyze plot This command prints an SVG graphic detailing which system services have been started at what time, highlighting the time they spent on initialization.
Example 5. Plot a bootchart
$ systemd-analyze plot >bootup.svg $ eog bootup.svg&
systemd-analyze dot [pattern...] This command generates textual dependency graph description in dot format for further processing with the GraphViz dot(1) tool. Use a command line like systemd-analyze dot | dot -Tsvg >systemd.svg to generate a graphical dependency tree. Unless --order or --require is passed, the generated graph will show both ordering and requirement dependencies. Optional pattern globbing style specifications (e.g.  *.target) may be given at the end. A unit dependency is included in the graph if any of these patterns match either the origin or destination node.
Example 6. Plot all dependencies of any unit whose name starts with "avahi-daemon"
$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg $ eog avahi.svg
Example 7. Plot the dependencies between all known target units
$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \ | dot -Tsvg >targets.svg $ eog targets.svg
systemd-analyze unit-paths This command outputs a list of all directories from which unit files, .d overrides, and .wants, .requires symlinks may be loaded. Combine with --user to retrieve the list for the user manager instance, and --global for the global configuration of user manager instances.
Example 8. Show all paths for generated units
$ systemd-analyze unit-paths | grep '^/run' /run/systemd/system.control /run/systemd/transient /run/systemd/generator.early /run/systemd/system /run/systemd/system.attached /run/systemd/generator /run/systemd/generator.late
Note that this verb prints the list that is compiled into systemd-analyze itself, and does not communicate with the running manager. Use
systemctl [--user] [--global] show -p UnitPath --value
to retrieve the actual list that the manager uses, with any empty directories omitted.
systemd-analyze exit-status [STATUS...] This command prints a list of exit statuses along with their "class", i.e. the source of the definition (one of "glibc", "systemd", "LSB", or "BSD"), see the Process Exit Codes section in systemd.exec(5). If no additional arguments are specified, all known statuses are shown. Otherwise, only the definitions for the specified codes are shown.
Example 9. Show some example exit status names
$ systemd-analyze exit-status 0 1 {63..65} NAME    STATUS CLASS SUCCESS 0      glibc FAILURE 1      glibc -       63     - USAGE   64     BSD DATAERR 65     BSD
systemd-analyze capability [CAPABILITY...] This command prints a list of Linux capabilities along with their numeric IDs. See capabilities(7) for details. If no argument is specified the full list of capabilities known to the service manager and the kernel is shown. Capabilities defined by the kernel but not known to the service manager are shown as "cap_???". Optionally, if arguments are specified they may refer to specific cabilities by name or numeric ID, in which case only the indicated capabilities are shown in the table.
Example 10. Show some example capability names
$ systemd-analyze capability 0 1 {30..32} NAME              NUMBER cap_chown              0 cap_dac_override       1 cap_audit_control     30 cap_setfcap           31 cap_mac_override      32
systemd-analyze condition CONDITION... This command will evaluate Condition*=...  and Assert*=...  assignments, and print their values, and the resulting value of the combined condition set. See systemd.unit(5) for a list of available conditions and asserts.
Example 11. Evaluate conditions that check kernel versions
$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \ 'ConditionKernelVersion = >=5.1' \ 'ConditionACPower=|false' \ 'ConditionArchitecture=|!arm' \ 'AssertPathExists=/etc/os-release' test.service: AssertPathExists=/etc/os-release succeeded. Asserts succeeded. test.service: ConditionArchitecture=|!arm succeeded. test.service: ConditionACPower=|false failed. test.service: ConditionKernelVersion=>=5.1 succeeded. test.service: ConditionKernelVersion=!<4.0 succeeded. Conditions succeeded.
systemd-analyze syscall-filter [SET...] This command will list system calls contained in the specified system call set SET, or all known sets if no sets are specified. Argument SET must include the "@" prefix.
systemd-analyze calendar EXPRESSION... This command will parse and normalize repetitive calendar time events, and will calculate when they elapse next. This takes the same input as the OnCalendar= setting in systemd.timer(5), following the syntax described in systemd.time(7). By default, only the next time the calendar expression will elapse is shown; use --iterations= to show the specified number of next times the expression elapses. Each time the expression elapses forms a timestamp, see the timestamp verb below.
Example 12. Show leap days in the near future
$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0' Original form: *-2-29 0:0:0 Normalized form: *-02-29 00:00:00 Next elapse: Sat 2020-02-29 00:00:00 UTC From now: 11 months 15 days left Iter. #2: Thu 2024-02-29 00:00:00 UTC From now: 4 years 11 months left Iter. #3: Tue 2028-02-29 00:00:00 UTC From now: 8 years 11 months left Iter. #4: Sun 2032-02-29 00:00:00 UTC From now: 12 years 11 months left Iter. #5: Fri 2036-02-29 00:00:00 UTC From now: 16 years 11 months left
systemd-analyze timestamp TIMESTAMP... This command parses a timestamp (i.e. a single point in time) and outputs the normalized form and the difference between this timestamp and now. The timestamp should adhere to the syntax documented in systemd.time(7), section "PARSING TIMESTAMPS".
Example 13. Show parsing of timestamps
$ systemd-analyze timestamp yesterday now tomorrow Original form: yesterday Normalized form: Mon 2019-05-20 00:00:00 CEST (in UTC): Sun 2019-05-19 22:00:00 UTC UNIX seconds: @15583032000 From now: 1 day 9h ago
Original form: now Normalized form: Tue 2019-05-21 09:48:39 CEST (in UTC): Tue 2019-05-21 07:48:39 UTC UNIX seconds: @1558424919.659757 From now: 43us ago
Original form: tomorrow Normalized form: Wed 2019-05-22 00:00:00 CEST (in UTC): Tue 2019-05-21 22:00:00 UTC UNIX seconds: @15584760000 From now: 14h left
systemd-analyze timespan EXPRESSION... This command parses a time span (i.e. a difference between two timestamps) and outputs the normalized form and the equivalent value in microseconds. The time span should adhere to the syntax documented in systemd.time(7), section "PARSING TIME SPANS". Values without units are parsed as seconds.
Example 14. Show parsing of timespans
$ systemd-analyze timespan 1s 300s '1year 0.000001s' Original: 1s Î¼s: 1000000 Human: 1s
Original: 300s Î¼s: 300000000 Human: 5min
Original: 1year 0.000001s Î¼s: 31557600000001 Human: 1y 1us
systemd-analyze cat-config NAME|PATH... This command is similar to systemctl cat, but operates on config files. It will copy the contents of a config file and any drop-ins to standard output, using the usual systemd set of directories and rules for precedence. Each argument must be either an absolute path including the prefix (such as /etc/systemd/logind.conf or /usr/lib/systemd/logind.conf), or a name relative to the prefix (such as systemd/logind.conf).
Example 15. Showing logind configuration
$ systemd-analyze cat-config systemd/logind.conf # /etc/systemd/logind.conf ... [Login] NAutoVTs=8 ...
# /usr/lib/systemd/logind.conf.d/20-test.conf ... some override from another package
# /etc/systemd/logind.conf.d/50-override.conf ... some administrator override
systemd-analyze verify FILE... This command will load unit files and print warnings if any errors are detected. Files specified on the command line will be loaded, but also any other units referenced by them. The full unit search path is formed by combining the directories for all command line arguments, and the usual unit load paths. The variable $SYSTEMD_UNIT_PATH is supported, and may be used to replace or augment the compiled in set of unit load paths; see systemd.unit(5). All units files present in the directories containing the command line arguments will be used in preference to the other paths.
The following errors are currently detected:
â€¢   unknown sections and directives,
â€¢   missing dependencies which are required to start the given unit,
â€¢   man pages listed in Documentation= which are not found in the system,
â€¢   commands listed in ExecStart= and similar which are not found in the system or not executable.
Example 16. Misspelt directives
$ cat ./user.slice [Unit] WhatIsThis=11 Documentation=man:nosuchfile(1) Requires=different.service
[Service] Description=x
$ systemd-analyze verify ./user.slice [./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit' [./user.slice:13] Unknown section 'Service'. Ignoring. Error: org.freedesktop.systemd1.LoadFailed: Unit different.service failed to load: No such file or directory. Failed to create user.slice/start: Invalid argument user.slice: man nosuchfile(1) command failed with code 16
Example 17. Missing service units
$ tail ./a.socket ./b.socket ==> ./a.socket <== [Socket] ListenStream=100
==> ./b.socket <== [Socket] ListenStream=100 Accept=yes
$ systemd-analyze verify ./a.socket ./b.socket Service a.service not loaded, a.socket cannot be started. Service b@0.service not loaded, b.socket cannot be started.
systemd-analyze security [UNIT...] This command analyzes the security and sandboxing settings of one or more specified service units. If at least one unit name is specified the security settings of the specified service units are inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded, long-running service units are inspected and a terse table with results shown. The command checks for various security-related service settings, assigning each a numeric "exposure level" value, depending on how important a setting is. It then calculates an overall exposure level for the whole unit, which is an estimation in the range 0.0...10.0 indicating how exposed a service is security-wise. High exposure levels indicate very little applied sandboxing. Low exposure levels indicate tight sandboxing and strongest security restrictions. Note that this only analyzes the per-service security features systemd itself implements. This means that any additional security mechanisms applied by the service code itself are not accounted for. The exposure level determined this way should not be misunderstood: a high exposure level neither means that there is no effective sandboxing applied by the service code itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels do indicate however that most likely the service might benefit from additional settings applied to them.
Please note that many of the security and sandboxing settings individually can be circumvented â€” unless combined with others. For example, if a service retains the privilege to establish or undo mount points many of the sandboxing options can be undone by the service code itself. Due to that is essential that each service uses the most comprehensive and strict sandboxing and security settings possible. The tool will take into account some of these combinations and relationships between the settings, but not all. Also note that the security and sandboxing settings analyzed here only apply to the operations executed by the service code itself. If a service has access to an IPC system (such as D-Bus) it might request operations from other services that are not subject to the same restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access policy is not validated too.
Example 18. Analyze systemd-logind.service
$ systemd-analyze security --no-pager systemd-logind.service NAME                DESCRIPTION                              EXPOSURE âœ— PrivateNetwork=     Service has access to the host's network      0.5 âœ— User=/DynamicUser=  Service runs as root user                     0.4 âœ— DeviceAllow=        Service has no device ACL                     0.2 âœ“ IPAddressDeny=      Service blocks all IP address ranges ... â†’ Overall exposure level for systemd-logind.service: 4.1 OK ðŸ™‚
--system Operates on the system systemd instance. This is the implied default.
--user Operates on the user systemd instance.
--global Operates on the system-wide configuration for user systemd instance.
--order, --require When used in conjunction with the dot command (see above), selects which dependencies are shown in the dependency graph. If --order is passed, only dependencies of type After= or Before= are shown. If --require is passed, only dependencies of type Requires=, Requisite=, Wants= and Conflicts= are shown. If neither is passed, this shows dependencies of all these types.
--from-pattern=, --to-pattern= When used in conjunction with the dot command (see above), this selects which relationships are shown in the dependency graph. Both options require a glob(7) pattern as an argument, which will be matched against the left-hand and the right-hand, respectively, nodes of a relationship.
Each of these can be used more than once, in which case the unit name must match one of the values. When tests for both sides of the relation are present, a relation must pass both tests to be shown. When patterns are also specified as positional arguments, they must match at least one side of the relation. In other words, patterns specified with those two options will trim the list of edges matched by the positional arguments, if any are given, and fully determine the list of edges shown otherwise.
--fuzz=timespan When used in conjunction with the critical-chain command (see above), also show units, which finished timespan earlier, than the latest unit in the same level. The unit of timespan is seconds unless specified with a different unit, e.g. "50ms".
--man=no Do not invoke man(1) to verify the existence of man pages listed in Documentation=.