neulab/tldr huggingface dataset:
tls_key_file file Send a client certificate to the server (use this together with tls_cert_file}).  The file must contain the private key of a certificate in PEM format. An empty argument disables this feature.
tls_cert_file file Send a client certificate to the server (use this together with tls_key_file).  The file must contain a certificate in PEM format. An empty argument disables this feature.
tls_certcheck [(on|off)] Enable or disable checks of the server certificate. They are enabled by default.  Disabling them will override tls_trust_file and tls_fingerprint.  WARNING: When the checks are disabled, TLS sessions will not be secure!
tls_priorities [priorities] Set priorities for TLS session parameters. The default is set by the TLS library and can be selected by using an empty argument to this command. The interpretation of the priorities string depends on the TLS library. Use --version to find out which TLS library you use. For GnuTLS, see the section on Priority Strings in the manual. For libtls, the priorites string is a space-separated list of parameter strings prefixed with either PROTOCOLS=, CIPHERS=, or ECDHECURVES=. These parameter strings will be passed to the functions tls_config_parse_protocols, tls_config_set_ciphers, and tls_config_set_ecdhecurves. Unrecognized parts of the priorities string will be ignored. Example: "PROTOCOLS=TLSv1.3 CIPHERS=ECDHE- RSA-AES128-SHA256 ECDHECURVES=P-384".
tls_host_override [host] By default, TLS host verification uses the host name given by the host command.  This command allows one to use a different host name for verification. This is only useful in special cases.
tls_min_dh_prime_bits [bits] Deprecated, use tls_priorities instead.  Set or unset the minimum number of Diffie-Hellman (DH) prime bits accepted for TLS sessions. The default is set by the TLS library and can be selected by using an empty argument to this command. Only lower the default (for example to 512 bits) if there is no other way to make TLS work with the remote server.
from envelope_from Set the envelope-from address. The following substitution patterns are supported: %U will be replaced by $USER, or if that fails by $LOGNAME, or if that fails by the login name of the user running msmtp. %H will be replaced by $HOSTNAME, or if that fails by the host name of the system. %C will be replaced by the canonical name of %H. %M will be replaced by the contents of /etc/mailname (potentially a different directory is used depending on the build configuration; see the output of msmtp --version and look for the location of the system configuration file). Note that the obsolete auto_from command replaces this envelope- from address. Furthermore, the envelope-from address may be a wildcard pattern as used for file name matching in the shell. This is the case if it contains one of the characters ?, * or [.  This allows a variety of envelope-from addresses given with the --from option to match a single account.
dsn_notify (off|condition) This command sets the condition(s) under which the mail system should send DSN (Delivery Status Notification) messages. The argument off disables explicit DSN requests, which means the mail system decides when to send DSN messages. This is the default. The condition must be never, to never request notification, or a comma separated list (no spaces!) of one or more of the following: failure, to request notification on transmission failure, delay, to be notified of message delays, success, to be notified of successful transmission. The SMTP server must support the DSN extension.
dsn_return (off|amount) This command controls how much of a mail should be returned in DSN (Delivery Status Notification) messages. The argument off disables explicit DSN requests, which means the mail system decides how much of a mail it returns in DSN messages. This is the default. The amount must be headers, to just return the message headers, or full, to return the full mail.  The SMTP server must support the DSN extension.
set_from_header [(auto|on|off)] When to set a From header: auto adds a From header if the mail does not have one (this is the default), on always sets a From header and overrides any existing one, and off never sets a From header. If the mail server rejects the mail because its From header does not match the envelope from address (a common anti-spam measure), then you might want to set this option to on. For compatibility with older versions, add_missing_from_header [(on|off)] is still supported and corresponds to the auto and off settings.
set_date_header [(on|off)] When to set a Date header: auto adds a Date header if the mail does not have one (this is the default), and off never sets a Date header. For compatibility with older versions, add_missing_date_header [(on|off)] is still supported and corresponds to the auto and off settings.
remove_bcc_headers [(on|off)] This command controls whether to remove Bcc headers. The default is to remove them.
undisclosed_recipients [(on|off)] When set, the original To, Cc, and Bcc headers of the mail are removed and a single new header line "To: undisclosed- recipients:;" is added. The default setting is off.
logfile [file] An empty argument disables logging (this is the default). When logging is enabled by choosing a log file, msmtp will append one line to the log file for each mail it tries to send via the account that this log file was chosen for. The line will include the following information: date and time in the format specified by logfile_time_format, host name of the SMTP server, whether TLS was used, whether authentication was used, authentication user name (only if authentication is used), envelope-from address, recipient addresses, size of the mail as transferred to the server (only if the delivery succeeded), SMTP status code and SMTP error message (only in case of failure and only if available), error message (only in case of failure and only if available), exit code (from sysexits.h; EX_OK indicates success). If the filename is a dash (-), msmtp prints the log line to the standard output.
logfile_time_format [fmt] Set or unset the log file time format. This will be used as the format string for the strftime() function. An empty argument chooses the default ("%b %d %H:%M:%S").
syslog [(on|off|facility)] Enable or disable syslog logging. The facility can be one of LOG_USER, LOG_MAIL, LOG_LOCAL0, ..., LOG_LOCAL7. The default is LOG_USER. Each time msmtp tries to send a mail via the account that contains this syslog command, it will log one entry to the syslog service with the chosen facility. The line will include the following information: host name of the SMTP server, whether TLS was used, whether authentication was used, envelope-from address, recipient addresses, size of the mail as transferred to the server (only if the delivery succeeded), SMTP status code and SMTP error message (only in case of failure and only if available), error message (only in case of failure and only if available), exit code (from sysexits.h; EX_OK indicates success).
aliases [file] Replace local recipients with addresses in the aliases file.  The aliases file is a cleartext file containing mappings between a local address and a list of replacement addresses. The mappings are of the form: local: someone@example.com, person@domain.example Multiple replacement addresses are separated with commas. Comments start with `#' and continue to the end of the line. The local address default has special significance and is matched if the local address is not found in the aliases file.  If no default alias is found, then the local address is left as is. An empty argument to the aliases command disables the replacement of local addresses.  This is the default.
auto_from [(on|off)] Obsolete; you can achieve the same and more using the substitution patterns of the from command. Enable or disable automatic envelope-from addresses. The default is off.  When enabled, an envelope-from address of the form user@domain will be generated.  The local part will be set to USER or, if that fails, to LOGNAME or, if that fails, to the login name of the current user.  The domain part can be set with the maildomain command.  If the maildomain is empty, the envelope-from address will only consist of the user name and not have a domain part. When auto_from is disabled, the envelope-from address must be set explicitly.
maildomain [domain] Obsolete; you can achieve the same and more using the substitution patterns of the from command. Set a domain part for the generation of an envelope-from address. This is only used when auto_from is on. The domain may be empty.
# Example for a user configuration file ~/.msmtprc # # This file focusses on TLS and authentication. Features not used here include # logging, timeouts, SOCKS proxies, TLS parameters, Delivery Status Notification # (DSN) settings, and more.
# Set default values for all following accounts. defaults
# Use the mail submission port 587 instead of the SMTP port 25. port 587
# Always use TLS. tls on
# Set a list of trusted CAs for TLS. The default is to use system settings, but # you can select your own file. #tls_trust_file /etc/ssl/certs/ca-certificates.crt
# A freemail service account freemail
# Host name of the SMTP server host smtp.freemail.example
# As an alternative to tls_trust_file, you can use tls_fingerprint # to pin a single certificate. You have to update the fingerprint when the # server certificate changes, but an attacker cannot trick you into accepting # a fraudulent certificate. Get the fingerprint with # $ msmtp --serverinfo --tls --tls-certcheck=off --host=smtp.freemail.example #tls_fingerprint 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22 :33
# Envelope-from address from joe_smith@freemail.example
# Authentication. The password is given using one of five methods, see below. auth on user joe.smith
# Password method 1: Add the password to the system keyring, and let msmtp get # it automatically. To set the keyring password using Gnome's libsecret: # $ secret-tool store --label=msmtp \ #   host smtp.freemail.example \ #   service smtp \ #   user joe.smith
# Password method 2: Store the password in an encrypted file, and tell msmtp # which command to use to decrypt it. This is usually used with GnuPG, as in # this example. Usually gpg-agent will ask once for the decryption password. passwordeval gpg2 --no-tty -q -d ~/.msmtp-password.gpg
# Password method 3: Store the password directly in this file. Usually it is not # a good idea to store passwords in cleartext files. If you do it anyway, at # least make sure that this file can only be read by yourself. #password secret123
# Password method 4: Store the password in ~/.netrc. This method is probably not # relevant anymore.
# Password method 5: Do not specify a password. Msmtp will then prompt you for # it. This means you need to be able to type into a terminal when msmtp runs.
# A second mail address at the same freemail service account freemail2 : freemail from joey@freemail.example
# The SMTP server of your ISP account isp host mail.isp.example from smithjoe@isp.example auth on user 12345
# Set a default account account default : freemail
Using msmtp with Mutt
Create a configuration file for msmtp and add the following lines to your Mutt configuration file: set sendmail="/path/to/msmtp" set use_from=yes set realname="Your Name" set from=you@example.com set envelope_from=yes The envelope_from=yes option lets Mutt use the -f option of msmtp. Therefore msmtp chooses the first account that matches the from address you@example.com. Alternatively, you can use the -a option: set sendmail="/path/to/msmtp -a my-account" Or set everything from the command line (but note that you cannot set a password this way): set sendmail="/path/to/msmtp --host=mailhub -f me@example.com --tls --tls-trust-file=trust.crt"
If you have multiple mail accounts in your msmtp configuration file and let Mutt use the -f option to choose the right one, you can easily switch accounts in Mutt with the following Mutt configuration lines: macro generic "<esc>1" ":set from=you@example.com" macro generic "<esc>2" ":set from=you@your-employer.example" macro generic "<esc>3" ":set from=you@some-other-provider.example"
Using msmtp with mail
Define a default account, and put the following in your ~/.mailrc: set sendmail="/path/to/msmtp"
Using msmtp with Tor
Use the following settings: proxy_host 127.0.0.1 proxy_port 9050 tls on Use an IP address as proxy host name, so that msmtp does not leak a DNS query when resolving it. TLS is required to prevent exit hosts from reading your SMTP session. Do not set domain to something that you do not want to reveal (do not set it at all if possible).
# Example aliases file
# Send root to Joe and Jane root: joe_smith@example.com, jane_chang@example.com
# Send cron to Mark cron: mark_jones@example.com
# Send everything else to admin default: admin@domain.example
SYSCONFDIR/msmtprc System configuration file. Use --version to find out what SYSCONFDIR is on your platform.
~/.msmtprc or $XDG_CONFIG_HOME/msmtp/config User configuration file.
~/.netrc and SYSCONFDIR/netrc The netrc file contains login information. Before prompting for a password, msmtp will search it in ~/.netrc and SYSCONFDIR/netrc.
USER, LOGNAME These variables override the user's login name when constructing an envelope-from address. LOGNAME is only used if USER is unset.
TMPDIR Directory to create temporary files in. If this is unset, a system specific default directory is used. A temporary file is only created when the -t/--read-recipients or --read-envelope-from option is used. The file is then used to buffer the headers of the mail (but not the body, so the file won't get very large).
EMAIL, SMTPSERVER These environment variables are used only if neither --host nor --account is used and there is no default account defined in the configuration files. In this case, the host name is taken from SMTPSERVER, and the envelope from address is taken from EMAIL, unless overridden by --from or --read-envelope-from. Currently SMTPSERVER must contain a plain host name (no URL), and EMAIL must contain a plain address (no names or additional information).
msmtp was written by Martin Lambers <marlam@marlam.de>. Other authors are listed in the AUTHORS file in the source distribution.
sendmail(8), netrc(5) or ftp(1)
tput(1)                      General Commands Manual                     tput(1)
tput, reset - initialize a terminal or query terminfo database
tput [-Ttype] capname [parameters] tput [-Ttype] [-x] clear tput [-Ttype] init tput [-Ttype] reset tput [-Ttype] longname tput -S  << tput -V
The tput utility uses the terminfo database to make the values of terminal-dependent capabilities and information available to the shell (see sh(1)), to initialize or reset the terminal, or return the long name of the requested terminal type.  The result depends upon the capability's type:
string tput writes the string to the standard output.  No trailing newline is supplied.
integer tput writes the decimal value to the standard output, with a trailing newline.
boolean tput simply sets the exit code (0 for TRUE if the terminal has the capability, 1 for FALSE if it does not), and writes nothing to the standard output.
Before using a value returned on the standard output, the application should test the exit code (e.g., $?, see sh(1)) to be sure it is 0.  (See the EXIT CODES and DIAGNOSTICS sections.)  For a complete list of capabilities and the capname associated with each, see terminfo(5).
Options -S     allows more than one capability per invocation of tput.  The capabilities must be passed to tput from the standard input instead of from the command line (see example).  Only one capname is allowed per line.  The -S option changes the meaning of the 0 and 1 boolean and string exit codes (see the EXIT CODES section).
Because some capabilities may use string parameters rather than numbers, tput uses a table and the presence of parameters in its input to decide whether to use tparm(3X), and how to interpret the parameters.
-Ttype indicates the type of terminal.  Normally this option is unnecessary, because the default is taken from the environment variable TERM.  If -T is specified, then the shell variables LINES and COLUMNS will also be ignored.
-V     reports the version of ncurses which was used in this program, and exits.
-x     do not attempt to clear the terminal's scrollback buffer using the extended “E3” capability.
Commands A few commands (init, reset and longname) are special; they are defined by the tput program.  The others are the names of capabilities from the terminal database (see terminfo(5) for a list).  Although init and reset resemble capability names, tput uses several capabilities to perform these special functions.
capname indicates the capability from the terminal database.
If the capability is a string that takes parameters, the arguments following the capability will be used as parameters for the string.
Most parameters are numbers.  Only a few terminal capabilities require string parameters; tput uses a table to decide which to pass as strings.  Normally tput uses tparm(3X) to perform the substitution.  If no parameters are given for the capability, tput writes the string without performing the substitution.
init   If the terminal database is present and an entry for the user's terminal exists (see -Ttype, above), the following will occur:
(1)  first, tput retrieves the current terminal mode settings for your terminal.  It does this by successively testing
•   the standard error,
•   standard output,
•   standard input and
•   ultimately “/dev/tty”
to obtain terminal settings.  Having retrieved these settings, tput remembers which file descriptor to use when updating settings.
(2)  if the window size cannot be obtained from the operating system, but the terminal description (or environment, e.g., LINES and COLUMNS variables specify this), update the operating system's notion of the window size.
(3)  the terminal modes will be updated:
•   any delays (e.g., newline) specified in the entry will be set in the tty driver,
•   tabs expansion will be turned on or off according to the specification in the entry, and
•   if tabs are not expanded, standard tabs will be set (every 8 spaces).
(4)  if present, the terminal's initialization strings will be output as detailed in the terminfo(5) section on Tabs and Initialization,
(5)  output is flushed.
If an entry does not contain the information needed for any of these activities, that activity will silently be skipped.
reset  This is similar to init, with two differences:
(1)  before any other initialization, the terminal modes will be reset to a “sane” state:
•   set cooked and echo modes,
•   turn off cbreak and raw modes,
•   turn on newline translation and
•   reset any unset special characters to their default values
(2)  Instead of putting out initialization strings, the terminal's reset strings will be output if present (rs1, rs2, rs3, rf). If the reset strings are not present, but initialization strings are, the initialization strings will be output.
Otherwise, reset acts identically to init.
longname If the terminal database is present and an entry for the user's terminal exists (see -Ttype above), then the long name of the terminal will be put out.  The long name is the last name in the first line of the terminal's description in the terminfo database [see term(5)].
Aliases tput handles the clear, init and reset commands specially: it allows for the possibility that it is invoked by a link with those names.
If tput is invoked by a link named reset, this has the same effect as tput reset.  The tset(1) utility also treats a link named reset specially.
Before ncurses 6.1, the two utilities were different from each other:
•   tset utility reset the terminal modes and special characters (not done with tput).
•   On the other hand, tset's repertoire of terminal capabilities for resetting the terminal was more limited, i.e., only reset_1string, reset_2string and reset_file in contrast to the tab-stops and margins which are set by this utility.
•   The reset program is usually an alias for tset, because of this difference with resetting terminal modes and special characters.
With the changes made for ncurses 6.1, the reset feature of the two programs is (mostly) the same.  A few differences remain:
•   The tset program waits one second when resetting, in case it happens to be a hardware terminal.
•   The two programs write the terminal initialization strings to different streams (i.e., the standard error for tset and the standard output for tput).
Note: although these programs write to different streams, redirecting their output to a file will capture only part of their actions.  The changes to the terminal modes are not affected by redirecting the output.
If tput is invoked by a link named init, this has the same effect as tput init.  Again, you are less likely to use that link because another program named init has a more well-established use.
Terminal Size Besides the special commands (e.g., clear), tput treats certain terminfo capabilities specially: lines and cols.  tput calls setupterm(3X) to obtain the terminal size:
•   first, it gets the size from the terminal database (which generally is not provided for terminal emulators which do not have a fixed window size)
•   then it asks the operating system for the terminal's size (which generally works, unless connecting via a serial line which does not support NAWS: negotiations about window size).
•   finally, it inspects the environment variables LINES and COLUMNS which may override the terminal size.
If the -T option is given tput ignores the environment variables by calling use_tioctl(TRUE), relying upon the operating system (or finally, the terminal database).
tput init Initialize the terminal according to the type of terminal in the environmental variable TERM.  This command should be included in everyone's .profile after the environmental variable TERM has been exported, as illustrated on the profile(5) manual page.
tput -T5620 reset Reset an AT&T 5620 terminal, overriding the type of terminal in the environmental variable TERM.
tput cup 0 0 Send the sequence to move the cursor to row 0, column 0 (the upper left corner of the screen, usually known as the “home” cursor position).
tput clear Echo the clear-screen sequence for the current terminal.
tput cols Print the number of columns for the current terminal.
tput -T450 cols Print the number of columns for the 450 terminal.
bold=`tput smso` offbold=`tput rmso` Set the shell variables bold, to begin stand-out mode sequence, and offbold, to end standout mode sequence, for the current terminal. This might be followed by a prompt: echo "${bold}Please type in your name: ${offbold}\c"
tput hc Set exit code to indicate if the current terminal is a hard copy terminal.
tput cup 23 4 Send the sequence to move the cursor to row 23, column 4.
tput cup Send the terminfo string for cursor-movement, with no parameters substituted.
tput longname Print the long name from the terminfo database for the type of terminal specified in the environmental variable TERM.
tput -S <<! > clear > cup 10 10 > bold > !
This example shows tput processing several capabilities in one invocation.  It clears the screen, moves the cursor to position 10, 10 and turns on bold (extra bright) mode.  The list is terminated by an exclamation mark (!) on a line by itself.
/usr/share/terminfo compiled terminal description database
/usr/share/tabset/* tab settings for some terminals, in a format appropriate to be output to the terminal (escape sequences that set margins and tabs); for more information, see the Tabs and Initialization, section of terminfo(5)
If the -S option is used, tput checks for errors from each line, and if any errors are found, will set the exit code to 4 plus the number of lines with errors.  If no errors are found, the exit code is 0.  No indication of which line failed can be given so exit code 1 will never appear.  Exit codes 2, 3, and 4 retain their usual interpretation.  If the -S option is not used, the exit code depends on the type of capname:
boolean a value of 0 is set for TRUE and 1 for FALSE.
string a value of 0 is set if the capname is defined for this terminal type (the value of capname is returned on standard output); a value of 1 is set if capname is not defined for this terminal type (nothing is written to standard output).
integer a value of 0 is always set, whether or not capname is defined for this terminal type.  To determine if capname is defined for this terminal type, the user must test the value written to standard output.  A value of -1 means that capname is not defined for this terminal type.
other  reset or init may fail to find their respective files.  In that case, the exit code is set to 4 + errno.
Any other exit code indicates an error; see the DIAGNOSTICS section.
tput prints the following error messages and sets the corresponding exit codes.
exit code   error message ───────────────────────────────────────────────────────────────────── 0           (capname is a numeric variable that is not specified in the terminfo(5) database for this terminal type, e.g. tput -T450 lines and tput -Thp2621 xmc) 1           no error message is printed, see the EXIT CODES section. 2           usage error 3           unknown terminal type or no terminfo database 4           unknown terminfo capability capname >4          error occurred in -S ─────────────────────────────────────────────────────────────────────
The tput command was begun by Bill Joy in 1980.  The initial version only cleared the screen.
AT&T System V provided a different tput command:
•   SVr2 provided a rudimentary tput which checked the parameter against each predefined capability and returned the corresponding value. This version of tput did not use tparm(3X) for the capabilities which are parameterized.
•   SVr3 replaced that, a year later, by a more extensive program whose init and reset subcommands (more than half the program) were incorporated from the reset feature of BSD tset written by Eric Allman.
•   SVr4 added color initialization using the orig_colors and orig_pairs capabilities in the init subcommand.
Keith Bostic replaced the BSD tput command in 1989 with a new implementation based on the AT&T System V program tput.  Like the AT&T program, Bostic's version accepted some parameters named for terminfo capabilities (clear, init, longname and reset).  However (because he had only termcap available), it accepted termcap names for other capabilities.  Also, Bostic's BSD tput did not modify the terminal I/O modes as the earlier BSD tset had done.
At the same time, Bostic added a shell script named “clear”, which used tput to clear the screen.
Both of these appeared in 4.4BSD, becoming the “modern” BSD implementation of tput.
This implementation of tput began from a different source than AT&T or BSD: Ross Ridge's mytinfo package, published on comp.sources.unix in December 1992.  Ridge's program made more sophisticated use of the terminal capabilities than the BSD program.  Eric Raymond used that tput program (and other parts of mytinfo) in ncurses in June 1995.  Using the portions dealing with terminal capabilities almost without change, Raymond made improvements to the way the command-line parameters were handled.
This implementation of tput differs from AT&T tput in two important areas:
•   tput capname writes to the standard output.  That need not be a regular terminal.  However, the subcommands which manipulate terminal modes may not use the standard output.
The AT&T implementation's init and reset commands use the BSD (4.1c) tset source, which manipulates terminal modes.  It successively tries standard output, standard error, standard input before falling back to “/dev/tty” and finally just assumes a 1200Bd terminal.  When updating terminal modes, it ignores errors.
Until changes made after ncurses 6.0, tput did not modify terminal modes.  tput now uses a similar scheme, using functions shared with tset (and ultimately based on the 4.4BSD tset).  If it is not able to open a terminal, e.g., when running in cron, tput will return an error.
•   AT&T tput guesses the type of its capname operands by seeing if all of the characters are numeric, or not.
Most implementations which provide support for capname operands use the tparm function to expand parameters in it.  That function expects a mixture of numeric and string parameters, requiring tput to know which type to use.
This implementation uses a table to determine the parameter types for the standard capname operands, and an internal library function to analyze nonstandard capname operands.
Besides providing more reliable operation than AT&T's utility, a portability problem is introduced by this analysis: An OpenBSD developer adapted the internal library function from ncurses to port NetBSD's termcap-based tput to terminfo.  That had been modified to interpret multiple commands on a line.  Portable applications should not rely upon this feature; ncurses provides it to support applications written specifically for OpenBSD.
This implementation (unlike others) can accept both termcap and terminfo names for the capname feature, if termcap support is compiled in. However, the predefined termcap and terminfo names have two ambiguities in this case (and the terminfo name is assumed):
•   The termcap name dl corresponds to the terminfo name dl1 (delete one line). The terminfo name dl corresponds to the termcap name DL (delete a given number of lines).
•   The termcap name ed corresponds to the terminfo name rmdc (end delete mode). The terminfo name ed corresponds to the termcap name cd (clear to end of screen).
The longname and -S options, and the parameter-substitution features used in the cup example, were not supported in BSD curses before 4.3reno (1989) or in AT&T/USL curses before SVr4 (1988).
IEEE Std 1003.1/The Open Group  Base Specifications Issue 7 (POSIX.1-2008) documents only the operands for clear, init and reset. There are a few interesting observations to make regarding that:
•   In this implementation, clear is part of the capname support.  The others (init and longname) do not correspond to terminal capabilities.
•   Other implementations of tput on SVr4-based systems such as Solaris, IRIX64 and HPUX as well as others such as AIX and Tru64 provide support for capname operands.
•   A few platforms such as FreeBSD recognize termcap names rather than terminfo capability names in their respective tput commands.  Since 2010, NetBSD's tput uses terminfo names.  Before that, it (like FreeBSD) recognized termcap names.
Beginning in 2021, FreeBSD uses the ncurses tput, configured for both terminfo (tested first) and termcap (as a fallback).
Because (apparently) all of the certified Unix systems support the full set of capability names, the reasoning for documenting only a few may not be apparent.
•   X/Open Curses Issue 7 documents tput differently, with capname and the other features used in this implementation.
•   That is, there are two standards for tput: POSIX (a subset) and X/Open Curses (the full implementation).  POSIX documents a subset to avoid the complication of including X/Open Curses and the terminal capabilities database.
•   While it is certainly possible to write a tput program without using curses, none of the systems which have a curses implementation provide a tput utility which does not provide the capname feature.
X/Open Curses Issue 7 (2009) is the first version to document utilities. However that part of X/Open Curses does not follow existing practice (i.e., Unix features documented in SVID 3):
•   It assigns exit code 4 to “invalid operand”, which may be the same as unknown capability.  For instance, the source code for Solaris' xcurses uses the term “invalid” in this case.
•   It assigns exit code 255 to a numeric variable that is not specified in the terminfo database.  That likely is a documentation error, confusing the -1 written to the standard output for an absent or cancelled numeric value versus an (unsigned) exit code.
The various Unix systems (AIX, HPUX, Solaris) use the same exit-codes as ncurses.
NetBSD curses documents different exit codes which do not correspond to either ncurses or X/Open.
clear(1), stty(1), tabs(1), tset(1), curs_termcap(3X), terminfo(5).
This describes ncurses version 6.3 (patch 20211021).
GIT-COMMIT-TREE(1)                 Git Manual                 GIT-COMMIT-TREE(1)
git-commit-tree - Create a new commit object
git commit-tree <tree> [(-p <parent>)...] git commit-tree [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...] [(-F <file>)...] <tree>
This is usually not what an end user wants to run directly. See git- commit(1) instead.
Creates a new commit object based on the provided tree object and emits the new commit object id on stdout. The log message is read from the standard input, unless -m or -F options are given.
The -m and -F options can be given any number of times, in any order. The commit log message will be composed in the order in which the options are given.
A commit object may have any number of parents. With exactly one parent, it is an ordinary commit. Having more than one parent makes the commit a merge between several lines of history. Initial (root) commits have no parents.
While a tree represents a particular directory state of a working directory, a commit represents that state in "time", and explains how to get there.
Normally a commit would identify a new "HEAD" state, and while Git doesn’t care where you save the note about that state, in practice we tend to just write the result to the file that is pointed at by .git/HEAD, so that we can always see what the last committed state was.
<tree> An existing tree object.
-p <parent> Each -p indicates the id of a parent commit object.
-m <message> A paragraph in the commit log message. This can be given more than once and each <message> becomes its own paragraph.
-F <file> Read the commit log message from the given file. Use - to read from the standard input. This can be given more than once and the content of each file becomes its own paragraph.
-S[<keyid>], --gpg-sign[=<keyid>], --no-gpg-sign GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.  --no-gpg-sign is useful to countermand a --gpg-sign option given earlier on the command line.
A commit encapsulates:
•   all parent object ids
•   author name, email and date
•   committer name and email and the commit time.
A commit comment is read from stdin. If a changelog entry is not provided via "<" redirection, git commit-tree will just wait for one to be entered and terminated with ^D.
The GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables support the following date formats:
Git internal format It is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch.  <time zone offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.
RFC 2822 The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.
ISO 8601 Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well. Fractional parts of a second will be ignored, for example 2005-04-07T22:13:13.019 will be treated as 2005-04-07T22:13:13.
Note In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY.
Git is to some extent character encoding agnostic.
•   The contents of the blob objects are uninterpreted sequences of bytes. There is no encoding translation at the core level.
•   Path names are encoded in UTF-8 normalization form C. This applies to tree objects, the index file, ref names, as well as path names in command line arguments, environment variables and config files (.git/config (see git-config(1)), gitignore(5), gitattributes(5) and gitmodules(5)).
Note that Git at the core level treats path names simply as sequences of non-NUL bytes, there are no path name encoding conversions (except on Mac and Windows). Therefore, using non-ASCII path names will mostly work even on platforms and file systems that use legacy extended ASCII encodings. However, repositories created on such systems will not work properly on UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa. Additionally, many Git-based tools simply assume path names to be UTF-8 and will fail to display other encodings correctly.
•   Commit log messages are typically encoded in UTF-8, but other extended ASCII encodings are also supported. This includes ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
Although we encourage that the commit log messages are encoded in UTF-8, both the core and Git Porcelain are designed not to force UTF-8 on projects. If all participants of a particular project find it more convenient to use legacy encodings, Git does not forbid it. However, there are a few things to keep in mind.
1. git commit and git commit-tree issues a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to have i18n.commitEncoding in .git/config file, like this:
[i18n] commitEncoding = ISO-8859-1
Commit objects created with the above setting record the value of i18n.commitEncoding in its encoding header. This is to help other people who look at them later. Lack of this header implies that the commit log message is encoded in UTF-8.
2. git log, git show, git blame and friends look at the encoding header of a commit object, and try to re-code the log message into UTF-8 unless otherwise specified. You can specify the desired output encoding with i18n.logOutputEncoding in .git/config file, like this:
[i18n] logOutputEncoding = ISO-8859-1
If you do not have this configuration variable, the value of i18n.commitEncoding is used instead.
Note that we deliberately chose not to re-code the commit log message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation.
/etc/mailname
git-write-tree(1) git-commit(1)
Part of the git(1) suite
socat(1)                                                                socat(1)
socat - Multipurpose relay (SOcket CAT)
socat [options] <address> <address> socat -V socat -h[h[h]] | -?[?[?]] filan procan
Socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them. Because the streams can be constructed from a large set of different types of data sinks and sources (see address types), and because lots of address options may be applied to the streams, socat can be used for many different purposes.
Filan is a utility that prints information about its active file descriptors to stdout. It has been written for debugging socat, but might be useful for other purposes too. Use the -h option to find more infos.
Procan is a utility that prints information about process parameters to stdout. It has been written to better understand some UNIX process properties and for debugging socat, but might be useful for other purposes too.
The life cycle of a socat instance typically consists of four phases.
In the init phase, the command line options are parsed and logging is initialized.
During the open phase, socat opens the first address and afterwards the second address. These steps are usually blocking; thus, especially for complex address types like socks, connection requests or authentication dialogs must be completed before the next step is started.
In the transfer phase, socat watches both streams’ read and write file descriptors via select() , and, when data is available on one side and can be written to the other side, socat reads it, performs newline character conversions if required, and writes the data to the write file descriptor of the other stream, then continues waiting for more data in both directions.
When one of the streams effectively reaches EOF, the closing phase begins. Socat transfers the EOF condition to the other stream, i.e. tries to shutdown only its write stream, giving it a chance to terminate gracefully. For a defined time socat continues to transfer data in the other direction, but then closes all remaining channels and terminates.
Socat provides some command line options that modify the behaviour of the program. They have nothing to do with so called address options that are used as parts of address specifications.
-V     Print version and available feature information to stdout, and exit.
-h | -? Print a help text to stdout describing command line options and available address types, and exit.
-hh | -?? Like -h, plus a list of the short names of all available address options. Some options are platform dependend, so this output is helpful for checking the particular implementation.
-hhh | -??? Like -hh, plus a list of all available address option names.
-d     Without this option, only fatal and error messages are generated; applying this option also prints warning messages. See DIAGNOSTICS for more information.
-d -d  Prints fatal, error, warning, and notice messages.
-d -d -d Prints fatal, error, warning, notice, and info messages.
-d -d -d -d Prints fatal, error, warning, notice, info, and debug messages.
-D     Logs information about file descriptors before starting the transfer phase.
-ly[<facility>] Writes messages to syslog instead of stderr; severity as defined with -d option. With optional <facility>, the syslog type can be selected, default is "daemon". Third party libraries might not obey this option.
-lf <logfile> Writes messages to <logfile> [filename] instead of stderr. Some third party libraries, in particular libwrap, might not obey this option.
-ls    Writes messages to stderr (this is the default). Some third party libraries might not obey this option, in particular libwrap appears to only log to syslog.
-lp<progname> Overrides the program name printed in error messages and used for constructing environment variable names.
-lu    Extends the timestamp of error messages to microsecond resolution. Does not work when logging to syslog.
-lm[<facility>] Mixed log mode. During startup messages are printed to stderr; when socat starts the transfer phase loop or daemon mode (i.e. after opening all streams and before starting data transfer, or, with listening sockets with fork option, before the first accept call), it switches logging to syslog.  With optional <facility>, the syslog type can be selected, default is "daemon".
-lh    Adds hostname to log messages. Uses the value from environment variable HOSTNAME or the value retrieved with uname() if HOSTNAME is not set.
-v     Writes the transferred data not only to their target streams, but also to stderr. The output format is text with some conversions for readability, and prefixed with "> " or "< " indicating flow directions.
-x     Writes the transferred data not only to their target streams, but also to stderr. The output format is hexadecimal, prefixed with "> " or "< " indicating flow directions. Can be combined with -v .
-r <file> Dumps the raw (binary) data flowing from left to right address to the given file.
-R <file> Dumps the raw (binary) data flowing from right to left address to the given file.
-b<size> Sets the data transfer block <size> [size_t].  At most <size> bytes are transferred per step. Default is 8192 bytes.
-s     By default, socat terminates when an error occurred to prevent the process from running when some option could not be applied. With this option, socat is sloppy with errors and tries to continue. Even with this option, socat will exit on fatals, and will abort connection attempts when security checks failed.
-t<timeout> When one channel has reached EOF, the write part of the other channel is shut down. Then, socat waits <timeout> [timeval] seconds before terminating. Default is 0.5 seconds. This timeout only applies to addresses where write and read part can be closed independently. When during the timeout interval the read part gives EOF, socat terminates without awaiting the timeout.
-T<timeout> Total inactivity timeout: when socat is already in the transfer loop and nothing has happened for <timeout> [timeval] seconds (no data arrived, no interrupt occurred...) then it terminates. Useful with protocols like UDP that cannot transfer EOF.
-u     Uses unidirectional mode. The first address is only used for reading, and the second address is only used for writing (example).
-U     Uses unidirectional mode in reverse direction. The first address is only used for writing, and the second address is only used for reading.
-g     During address option parsing, don’t check if the option is considered useful in the given address environment. Use it if you want to force, e.g., appliance of a socket option to a serial device.
-L<lockfile> If lockfile exists, exits with error. If lockfile does not exist, creates it and continues, unlinks lockfile on exit.
-W<lockfile> If lockfile exists, waits until it disappears. When lockfile does not exist, creates it and continues, unlinks lockfile on exit.
-4     Use IP version 4 in case that the addresses do not implicitly or explicitly specify a version; this is the default.
-6     Use IP version 6 in case that the addresses do not implicitly or explicitly specify a version.
With the address command line arguments, the user gives socat instructions and the necessary information for establishing the byte streams.
An address specification usually consists of an address type keyword, zero or more required address parameters separated by ’:’ from the keyword and from each other, and zero or more address options separated by ’,’.
The keyword specifies the address type (e.g., TCP4, OPEN, EXEC). For some keywords there exist synonyms (’-’ for STDIO, TCP for TCP4). Keywords are case insensitive.  For a few special address types, the keyword may be omitted: Address specifications starting with a number are assumed to be FD (raw file descriptor) addresses; if a ’/’ is found before the first ’:’ or ’,’, GOPEN (generic file open) is assumed.
The required number and type of address parameters depend on the address type. E.g., TCP4 requires a server specification (name or address), and a port specification (number or service name).
Zero or more address options may be given with each address. They influence the address in some ways.  Options consist of an option keyword or an option keyword and a value, separated by ’=’. Option keywords are case insensitive.  For filtering the options that are useful with an address type, each option is member of one option group. For each address type there is a set of option groups allowed. Only options belonging to one of these address groups may be used (except with option -g).
Address specifications following the above schema are also called single address specifications.  Two single addresses can be combined with "!!" to form a dual type address for one channel. Here, the first address is used by socat for reading data, and the second address for writing data. There is no way to specify an option only once for being applied to both single addresses.
Usually, addresses are opened in read/write mode. When an address is part of a dual address specification, or when option -u or -U is used, an address might be used only for reading or for writing. Considering this is important with some address types.
With socat version 1.5.0 and higher, the lexical analysis tries to handle quotes and parenthesis meaningfully and allows escaping of special characters.  If one of the characters ( { [ ’ is found, the corresponding closing character - ) } ] ’ - is looked for; they may also be nested. Within these constructs, socats special characters and strings : , !! are not handled specially. All those characters and strings can be escaped with \ or within ""
This section describes the available address types with their keywords, parameters, and semantics.
CREATE:<filename> Opens <filename> with creat() and uses the file descriptor for writing.  This address type requires write-only context, because a file opened with creat cannot be read from. Flags like O_LARGEFILE cannot be applied. If you need them use OPEN with options create,create. <filename> must be a valid existing or not existing path.  If <filename> is a named pipe, creat() might block; if <filename> refers to a socket, this is an error. Option groups: FD,REG,NAMED Useful options: mode, user, group, unlink-early, unlink-late, append See also: OPEN, GOPEN