neulab/tldr huggingface dataset:
Implementations wanting to provide a counterpart to the next command that edited the previous file have used the command prev[ious], which takes no file argument. POSIX.1‐2008 does not require this command.
Open Historically, the open command would fail if the open edit option was not set. POSIX.1‐2008 does not mention the open edit option and does not require this behavior. Some historical implementations do not permit entering open mode from open or visual mode, only from ex mode. For consistency, POSIX.1‐2008 does not permit this behavior.
Historically, entering open mode from the command line (that is, vi +open) resulted in anomalous behaviors; for example, the ex file and set commands, and the vi command <control>‐G did not work. For consistency, POSIX.1‐2008 does not permit this behavior.
Historically, the open command only permitted '/' characters to be used as the search pattern delimiter. For consistency, POSIX.1‐2008 requires that the search delimiters used by the s, global, and v commands be accepted as well.
Preserve The preserve command does not historically cause the file to be considered unmodified for the purposes of future commands that may exit the editor. POSIX.1‐2008 requires conformance to historical practice.
Historical documentation stated that mail was not sent to the user when preserve was executed; however, historical implementations did send mail in this case. POSIX.1‐2008 requires conformance to the historical implementations.
Print The writing of NUL by the print command is not specified as a special case because the standard developers did not want to require ex to support NUL characters. Historically, characters were displayed using the ARPA standard mappings, which are as follows:
1. Printable characters are left alone.
2. Control characters less than \177 are represented as '^' followed by the character offset from the '@' character in the ASCII map; for example, \007 is represented as '^G'.
3. \177 is represented as '^' followed by '?'.
The display of characters having their eighth bit set was less standard. Existing implementations use hex (0x00), octal (\000), and a meta-bit display. (The latter displayed bytes that had their eighth bit set as the two characters "M-" followed by the seven-bit display as described above.) The latter probably has the best claim to historical practice because it was used for the -v option of 4 BSD and 4 BSD-derived versions of the cat utility since 1980.
No specific display format is required by POSIX.1‐2008.
Explicit dependence on the ASCII character set has been avoided where possible, hence the use of the phrase an ``implementation-defined multi- character sequence'' for the display of non-printable characters in preference to the historical usage of, for instance, "^I" for the <tab>. Implementations are encouraged to conform to historical practice in the absence of any strong reason to diverge.
Historically, all ex commands beginning with the letter 'p' could be entered using capitalized versions of the commands; for example, P[rint], Pre[serve], and Pu[t] were all valid command names. POSIX.1‐2008 permits, but does not require, this historical practice because capital forms of the commands are used by some implementations for other purposes.
Put Historically, an ex put command, executed from open or visual mode, was the same as the open or visual mode P command, if the buffer was named and was cut in character mode, and the same as the p command if the buffer was named and cut in line mode. If the unnamed buffer was the source of the text, the entire line from which the text was taken was usually put, and the buffer was handled as if in line mode, but it was possible to get extremely anomalous behavior. In addition, using the Q command to switch into ex mode, and then doing a put often resulted in errors as well, such as appending text that was unrelated to the (supposed) contents of the buffer. For consistency and simplicity of specification, POSIX.1‐2008 does not permit these behaviors. All ex put commands are required to operate in line mode, and the contents of the buffers are not altered by changing the mode of the editor.
Read Historically, an ex read command executed from open or visual mode, executed in an empty file, left an empty line as the first line of the file. For consistency and simplicity of specification, POSIX.1‐2008 does not permit this behavior.  Historically, a read in open or visual mode from a program left the cursor at the last line read in, not the first. For consistency, POSIX.1‐2008 does not permit this behavior.
Historical implementations of ex were unable to undo read commands that read from the output of a program. For consistency, POSIX.1‐2008 does not permit this behavior.
Historically, the ex and vi message after a successful read or write command specified ``characters'', not ``bytes''. POSIX.1‐2008 requires that the number of bytes be displayed, not the number of characters, because it may be difficult in multi-byte implementations to determine the number of characters read. Implementations are encouraged to clarify the message displayed to the user.
Historically, reads were not permitted on files other than type regular, except that FIFO files could be read (probably only because they did not exist when ex and vi were originally written). Because the historical ex evaluated read!  and read !  equivalently, there can be no optional way to force the read. POSIX.1‐2008 permits, but does not require, this behavior.
Recover Some historical implementations of the editor permitted users to recover the edit buffer contents from a previous edit session, and then exit without saving those contents (or explicitly discarding them). The intent of POSIX.1‐2008 in requiring that the edit buffer be treated as already modified is to prevent this user error.
Rewind Historical implementations supported the rewind command when the user was editing the first file in the list; that is, the file that the rewind command would edit. POSIX.1‐2008 requires conformance to historical practice.
Substitute Historically, ex accepted an r option to the s command. The effect of the r option was to use the last regular expression used in any command as the pattern, the same as the ~ command. The r option is not required by POSIX.1‐2008. Historically, the c and g options were toggled; for example, the command :s/abc/def/ was the same as s/abc/def/ccccgggg.  For simplicity of specification, POSIX.1‐2008 does not permit this behavior.
The tilde command is often used to replace the last search RE. For example, in the sequence:
s/red/blue/ /green ~
the ~ command is equivalent to:
s/green/blue/
Historically, ex accepted all of the following forms:
s/abc/def/ s/abc/def s/abc/ s/abc
POSIX.1‐2008 requires conformance to this historical practice.
The s command presumes that the '^' character only occupies a single column in the display. Much of the ex and vi specification presumes that the <space> only occupies a single column in the display. There are no known character sets for which this is not true.
Historically, the final column position for the substitute commands was based on previous column movements; a search for a pattern followed by a substitution would leave the column position unchanged, while a 0 command followed by a substitution would change the column position to the first non-<blank>.  For consistency and simplicity of specification, POSIX.1‐2008 requires that the final column position always be set to the first non-<blank>.
Set Historical implementations redisplayed all of the options for each occurrence of the all keyword. POSIX.1‐2008 permits, but does not require, this behavior.
Tag No requirement is made as to where ex and vi shall look for the file referenced by the tag entry. Historical practice has been to look for the path found in the tags file, based on the current directory. A useful extension found in some implementations is to look based on the directory containing the tags file that held the entry, as well. No requirement is made as to which reference for the tag in the tags file is used. This is deliberate, in order to permit extensions such as multiple entries in a tags file for a tag.
Because users often specify many different tags files, some of which need not be relevant or exist at any particular time, POSIX.1‐2008 requires that error messages about problem tags files be displayed only if the requested tag is not found, and then, only once for each time that the tag edit option is changed.
The requirement that the current edit buffer be unmodified is only necessary if the file indicated by the tag entry is not the same as the current file (as defined by the current pathname). Historically, the file would be reloaded if the filename had changed, as well as if the filename was different from the current pathname. For consistency and simplicity of specification, POSIX.1‐2008 does not permit this behavior, requiring that the name be the only factor in the decision.
Historically, vi only searched for tags in the current file from the current cursor to the end of the file, and therefore, if the wrapscan option was not set, tags occurring before the current cursor were not found. POSIX.1‐2008 considers this a bug, and implementations are required to search for the first occurrence in the file, regardless.
Undo The undo description deliberately uses the word ``modified''. The undo command is not intended to undo commands that replace the contents of the edit buffer, such as edit, next, tag, or recover.
Cursor positioning after the undo command was inconsistent in the historical vi, sometimes attempting to restore the original cursor position (global, undo, and v commands), and sometimes, in the presence of maps, placing the cursor on the last line added or changed instead of the first. POSIX.1‐2008 requires a simplified behavior for consistency and simplicity of specification.
Version The version command cannot be exactly specified since there is no widely- accepted definition of what the version information should contain. Implementations are encouraged to do something reasonably intelligent.
Write Historically, the ex and vi message after a successful read or write command specified ``characters'', not ``bytes''. POSIX.1‐2008 requires that the number of bytes be displayed, not the number of characters because it may be difficult in multi-byte implementations to determine the number of characters written. Implementations are encouraged to clarify the message displayed to the user.
Implementation-defined tests are permitted so that implementations can make additional checks; for example, for locks or file modification times.
Historically, attempting to append to a nonexistent file caused an error. It has been left unspecified in POSIX.1‐2008 to permit implementations to let the write succeed, so that the append semantics are similar to those of the historical csh.
Historical vi permitted empty edit buffers to be written. However, since the way vi got around dealing with ``empty'' files was to always have a line in the edit buffer, no matter what, it wrote them as files of a single, empty line. POSIX.1‐2008 does not permit this behavior.
Historically, ex restored standard output and standard error to their values as of when ex was invoked, before writes to programs were performed. This could disturb the terminal configuration as well as be a security issue for some terminals. POSIX.1‐2008 does not permit this, requiring that the program output be captured and displayed as if by the ex print command.
Adjust Window Historically, the line count was set to the value of the scroll option if the type character was end-of-file. This feature was broken on most historical implementations long ago, however, and is not documented anywhere. For this reason, POSIX.1‐2008 is resolutely silent.
Historically, the z command was <blank>-sensitive and z + and z - did different things than z+ and z- because the type could not be distinguished from a flag. (The commands z .  and z = were historically invalid.) POSIX.1‐2008 requires conformance to this historical practice.
Historically, the z command was further <blank>-sensitive in that the count could not be <blank>-delimited; for example, the commands z= 5 and z- 5 were also invalid. Because the count is not ambiguous with respect to either the type character or the flags, this is not permitted by POSIX.1‐2008.
Escape Historically, ex filter commands only read the standard output of the commands, letting standard error appear on the terminal as usual. The vi utility, however, read both standard output and standard error. POSIX.1‐2008 requires the latter behavior for both ex and vi, for consistency.
Shift Left and Shift Right Historically, it was possible to add shift characters to increase the effect of the command; for example, <<< outdented (or >>> indented) the lines 3 levels of indentation instead of the default 1.  POSIX.1‐2008 requires conformance to historical practice.
<control>‐D Historically, the <control>‐D command erased the prompt, providing the user with an unbroken presentation of lines from the edit buffer. This is not required by POSIX.1‐2008; implementations are encouraged to provide it if possible.  Historically, the <control>‐D command took, and then ignored, a count.  POSIX.1‐2008 does not permit this behavior.
Write Line Number Historically, the ex = command, when executed in ex mode in an empty edit buffer, reported 0, and from open or visual mode, reported 1. For consistency and simplicity of specification, POSIX.1‐2008 does not permit this behavior.
Execute Historically, ex did not correctly handle the inclusion of text input commands (that is, append, insert, and change) in executed buffers. POSIX.1‐2008 does not permit this exclusion for consistency.
Historically, the logical contents of the buffer being executed did not change if the buffer itself were modified by the commands being executed; that is, buffer execution did not support self-modifying code. POSIX.1‐2008 requires conformance to historical practice.
Historically, the @ command took a range of lines, and the @ buffer was executed once per line, with the current line ('.')  set to each specified line. POSIX.1‐2008 requires conformance to historical practice.
Some historical implementations did not notice if errors occurred during buffer execution. This, coupled with the ability to specify a range of lines for the ex @ command, makes it trivial to cause them to drop core. POSIX.1‐2008 requires that implementations stop buffer execution if any error occurs, if the specified line doesn't exist, or if the contents of the edit buffer itself are replaced (for example, the buffer executes the ex :edit command).
Regular Expressions in ex Historical practice is that the characters in the replacement part of the last s command—that is, those matched by entering a '~' in the regular expression—were not further expanded by the regular expression engine. So, if the characters contained the string "a.," they would match 'a' followed by ".," and not 'a' followed by any character. POSIX.1‐2008 requires conformance to historical practice.
Edit Options in ex The following paragraphs describe the historical behavior of some edit options that were not, for whatever reason, included in POSIX.1‐2008. Implementations are strongly encouraged to only use these names if the functionality described here is fully supported.
extended  The extended edit option has been used in some implementations of vi to provide extended regular expressions instead of basic regular expressions This option was omitted from POSIX.1‐2008 because it is not widespread historical practice.
flash     The flash edit option historically caused the screen to flash instead of beeping on error. This option was omitted from POSIX.1‐2008 because it is not found in some historical implementations.
hardtabs  The hardtabs edit option historically defined the number of columns between hardware tab settings. This option was omitted from POSIX.1‐2008 because it was believed to no longer be generally useful.
modeline  The modeline (sometimes named modelines) edit option historically caused ex or vi to read the five first and last lines of the file for editor commands.  This option is a security problem, and vendors are strongly encouraged to delete it from historical implementations.
open      The open edit option historically disallowed the ex open and visual commands. This edit option was omitted because these commands are required by POSIX.1‐2008.
optimize  The optimize edit option historically expedited text throughput by setting the terminal to not do automatic <carriage-return> characters when printing more than one logical line of output. This option was omitted from POSIX.1‐2008 because it was intended for terminals without addressable cursors, which are rarely, if ever, still used.
ruler     The ruler edit option has been used in some implementations of vi to present a current row/column ruler for the user. This option was omitted from POSIX.1‐2008 because it is not widespread historical practice.
sourceany The sourceany edit option historically caused ex or vi to source start-up files that were owned by users other than the user running the editor. This option is a security problem, and vendors are strongly encouraged to remove it from their implementations.
timeout   The timeout edit option historically enabled the (now standard) feature of only waiting for a short period before returning keys that could be part of a macro. This feature was omitted from POSIX.1‐2008 because its behavior is now standard, it is not widely useful, and it was rarely documented.
verbose   The verbose edit option has been used in some implementations of vi to cause vi to output error messages for common errors; for example, attempting to move the cursor past the beginning or end of the line instead of only alerting the screen. (The historical vi only alerted the terminal and presented no message for such errors. The historical editor option terse did not select when to present error messages, it only made existing error messages more or less verbose.) This option was omitted from POSIX.1‐2008 because it is not widespread historical practice; however, implementors are encouraged to use it if they wish to provide error messages for naive users.
wraplen   The wraplen edit option has been used in some implementations of vi to specify an automatic margin measured from the left margin instead of from the right margin. This is useful when multiple screen sizes are being used to edit a single file. This option was omitted from POSIX.1‐2008 because it is not widespread historical practice; however, implementors are encouraged to use it if they add this functionality.
autoindent, ai Historically, the command 0a did not do any autoindentation, regardless of the current indentation of line 1. POSIX.1‐2008 requires that any indentation present in line 1 be used.
autoprint, ap Historically, the autoprint edit option was not completely consistent or based solely on modifications to the edit buffer. Exceptions were the read command (when reading from a file, but not from a filter), the append, change, insert, global, and v commands, all of which were not affected by autoprint, and the tag command, which was affected by autoprint.  POSIX.1‐2008 requires conformance to historical practice.
Historically, the autoprint option only applied to the last of multiple commands entered using <vertical-line> delimiters; for example, delete <newline> was affected by autoprint, but delete|version <newline> was not. POSIX.1‐2008 requires conformance to historical practice.
autowrite, aw Appending the '!'  character to the ex next command to avoid performing an automatic write was not supported in historical implementations. POSIX.1‐2008 requires that the behavior match the other ex commands for consistency.
ignorecase, ic Historical implementations of case-insensitive matching (the ignorecase edit option) lead to counter-intuitive situations when uppercase characters were used in range expressions. Historically, the process was as follows:
1. Take a line of text from the edit buffer.
2. Convert uppercase to lowercase in text line.
3. Convert uppercase to lowercase in regular expressions, except in character class specifications.
4. Match regular expressions against text.
This would mean that, with ignorecase in effect, the text:
The cat sat on the mat
would be matched by
/^the/
but not by:
/^[A-Z]he/
For consistency with other commands implementing regular expressions, POSIX.1‐2008 does not permit this behavior.
paragraphs, para The ISO POSIX‐2:1993 standard made the default paragraphs and sections edit options implementation-defined, arguing they were historically oriented to the UNIX system troff text formatter, and a ``portable user'' could use the {, }, [[, ]], (, and ) commands in open or visual mode and have the cursor stop in unexpected places. POSIX.1‐2008 specifies their values in the POSIX locale because the unusual grouping (they only work when grouped into two characters at a time) means that they cannot be used for general-purpose movement, regardless.
readonly Implementations are encouraged to provide the best possible information to the user as to the read-only status of the file, with the exception that they should not consider the current special privileges of the process. This provides users with a safety net because they must force the overwrite of read-only files, even when running with additional privileges.
The readonly edit option specification largely conforms to historical practice. The only difference is that historical implementations did not notice that the user had set the readonly edit option in cases where the file was already marked read-only for some reason, and would therefore reinitialize the readonly edit option the next time the contents of the edit buffer were replaced. This behavior is disallowed by POSIX.1‐2008.
report The requirement that lines copied to a buffer interact differently than deleted lines is historical practice. For example, if the report edit option is set to 3, deleting 3 lines will cause a report to be written, but 4 lines must be copied before a report is written.
The requirement that the ex global, v, open, undo, and visual commands present reports based on the total number of lines added or deleted during the command execution, and that commands executed by the global and v commands not present reports, is historical practice. POSIX.1‐2008 extends historical practice by requiring that buffer execution be treated similarly. The reasons for this are two-fold. Historically, only the report by the last command executed from the buffer would be seen by the user, as each new report would overwrite the last. In addition, the standard developers believed that buffer execution had more in common with global and v commands than it did with other ex commands, and should behave similarly, for consistency and simplicity of specification.
showmatch, sm The length of time the cursor spends on the matching character is unspecified because the timing capabilities of systems are often inexact and variable. The time should be long enough for the user to notice, but not long enough for the user to become annoyed. Some implementations of vi have added a matchtime option that permits users to set the number of 0,1 second intervals the cursor pauses on the matching character.
showmode The showmode option has been used in some historical implementations of ex and vi to display the current editing mode when in open or visual mode. The editing modes have generally included ``command'' and ``input'', and sometimes other modes such as ``replace'' and ``change''. The string was usually displayed on the bottom line of the screen at the far right-hand corner. In addition, a preceding '*' character often denoted whether the contents of the edit buffer had been modified. The latter display has sometimes been part of the showmode option, and sometimes based on another option. This option was not available in the 4 BSD historical implementation of vi, but was viewed as generally useful, particularly to novice users, and is required by POSIX.1‐2008.
The smd shorthand for the showmode option was not present in all historical implementations of the editor.  POSIX.1‐2008 requires it, for consistency.
Not all historical implementations of the editor displayed a mode string for command mode, differentiating command mode from text input mode by the absence of a mode string. POSIX.1‐2008 permits this behavior for consistency with historical practice, but implementations are encouraged to provide a display string for both modes.
slowopen Historically, the slowopen option was automatically set if the terminal baud rate was less than 1200 baud, or if the baud rate was 1200 baud and the redraw option was not set. The slowopen option had two effects. First, when inserting characters in the middle of a line, characters after the cursor would not be pushed ahead, but would appear to be overwritten. Second, when creating a new line of text, lines after the current line would not be scrolled down, but would appear to be overwritten. In both cases, ending text input mode would cause the screen to be refreshed to match the actual contents of the edit buffer. Finally, terminals that were sufficiently intelligent caused the editor to ignore the slowopen option. POSIX.1‐2008 permits most historical behavior, extending historical practice to require slowopen behaviors if the edit option is set by the user.
tags The default path for tags files is left unspecified as implementations may have their own tags implementations that do not correspond to the historical ones. The default tags option value should probably at least include the file ./tags.
term Historical implementations of ex and vi ignored changes to the term edit option after the initial terminal information was loaded. This is permitted by POSIX.1‐2008; however, implementations are encouraged to permit the user to modify their terminal type at any time.
terse Historically, the terse edit option optionally provided a shorter, less descriptive error message, for some error messages. This is permitted, but not required, by POSIX.1‐2008. Historically, most common visual mode errors (for example, trying to move the cursor past the end of a line) did not result in an error message, but simply alerted the terminal. Implementations wishing to provide messages for novice users are urged to do so based on the edit option verbose, and not terse.
window In historical implementations, the default for the window edit option was based on the baud rate as follows:
1. If the baud rate was less than 1200, the edit option w300 set the window value; for example, the line:
set w300=12
would set the window option to 12 if the baud rate was less than 1200.
2. If the baud rate was equal to 1200, the edit option w1200 set the window value.
3. If the baud rate was greater than 1200, the edit option w9600 set the window value.
The w300, w1200, and w9600 options do not appear in POSIX.1‐2008 because of their dependence on specific baud rates.
In historical implementations, the size of the window displayed by various commands was related to, but not necessarily the same as, the window edit option. For example, the size of the window was set by the ex command visual 10, but it did not change the value of the window edit option. However, changing the value of the window edit option did change the number of lines that were displayed when the screen was repainted. POSIX.1‐2008 does not permit this behavior in the interests of consistency and simplicity of specification, and requires that all commands that change the number of lines that are displayed do it by setting the value of the window edit option.
wrapmargin, wm Historically, the wrapmargin option did not affect maps inserting characters that also had associated counts; for example :map K 5aABC DEF. Unfortunately, there are widely used maps that depend on this behavior. For consistency and simplicity of specification, POSIX.1‐2008 does not permit this behavior.
Historically, wrapmargin was calculated using the column display width of all characters on the screen. For example, an implementation using "^I" to represent <tab> characters when the list edit option was set, where '^' and 'I' each took up a single column on the screen, would calculate the wrapmargin based on a value of 2 for each <tab>.  The number edit option similarly changed the effective length of the line as well. POSIX.1‐2008 requires conformance to historical practice.
Earlier versions of this standard allowed for implementations with bytes other than eight bits, but this has been modified in this version.
Section 2.9.1.1, Command Search and Execution, ctags, ed, sed, sh, stty, vi
The Base Definitions volume of POSIX.1‐2017, Table 5-1, Escape Sequences and Associated Actions, Chapter 8, Environment Variables, Section 9.3, Basic Regular Expressions, Section 12.2, Utility Syntax Guidelines
The System Interfaces volume of POSIX.1‐2017, access()
WPA_CLI(8)                                                            WPA_CLI(8)
wpa_cli - WPA command line client
wpa_cli [ -p path to ctrl sockets ] [ -g path to global ctrl_interface socket ] [ -i ifname ] [ -hvB ] [ -a action file ] [ -P pid file ] [ -G ping interval ] [ command ... ]
wpa_cli is a text-based frontend program for interacting with wpa_supplicant. It is used to query current status, change configuration, trigger events, and request interactive user input.
wpa_cli can show the current authentication status, selected security mode, dot11 and dot1x MIBs, etc. In addition, it can configure some variables like EAPOL state machine parameters and trigger events like reassociation and IEEE 802.1X logoff/logon. wpa_cli provides a user interface to request authentication information, like username and password, if these are not included in the configuration. This can be used to implement, e.g., one-time-passwords or generic token card authentication where the authentication is based on a challenge-response that uses an external device for generating the response.
The control interface of wpa_supplicant can be configured to allow non- root user access (ctrl_interface GROUP= parameter in the configuration file). This makes it possible to run wpa_cli with a normal user account.
wpa_cli supports two modes: interactive and command line. Both modes share the same command set and the main difference is in interactive mode providing access to unsolicited messages (event messages, username/password requests).
Interactive mode is started when wpa_cli is executed without including the command as a command line parameter. Commands are then entered on the wpa_cli prompt. In command line mode, the same commands are entered as command line arguments for wpa_cli.
When wpa_supplicant need authentication parameters, like username and password, which are not present in the configuration file, it sends a request message to all attached frontend programs, e.g., wpa_cli in interactive mode. wpa_cli shows these requests with "CTRL- REQ-<type>-<id>:<text>" prefix. <type> is IDENTITY, PASSWORD, or OTP (one-time-password). <id> is a unique identifier for the current network. <text> is description of the request. In case of OTP request, it includes the challenge from the authentication server.
The reply to these requests can be given with identity, password, and otp commands. <id> needs to be copied from the matching request. password and otp commands can be used regardless of whether the request was for PASSWORD or OTP. The main difference between these two commands is that values given with password are remembered as long as wpa_supplicant is running whereas values given with otp are used only once and then forgotten, i.e., wpa_supplicant will ask frontend for a new value for every use.  This can be used to implement one-time-password lists and generic token card -based authentication.
Example request for password and a matching reply:
CTRL-REQ-PASSWORD-1:Password needed for SSID foobar > password 1 mysecretpassword
Example request for generic token card challenge-response:
CTRL-REQ-OTP-2:Challenge 1235663 needed for SSID foobar > otp 2 9876
-p path Change the path where control sockets should be found.
-g control socket path Connect to the global control socket at the indicated path rather than an interface-specific control socket.
-i ifname Specify the interface that is being configured.  By default, choose the first interface found with a control socket in the socket path.
-h     Help.  Show a usage message.
-v     Show version information.
-B     Run as a daemon in the background.
-a file Run in daemon mode executing the action file based on events from wpa_supplicant.  The specified file will be executed with the first argument set to interface name and second to "CONNECTED" or "DISCONNECTED" depending on the event.  This can be used to execute networking tools required to configure the interface.
Additionally, three environmental variables are available to the file: WPA_CTRL_DIR, WPA_ID, and WPA_ID_STR. WPA_CTRL_DIR contains the absolute path to the ctrl_interface socket. WPA_ID contains the unique network_id identifier assigned to the active network, and WPA_ID_STR contains the content of the id_str option.
-P file Set the location of the PID file.
-G ping interval Set the interval (in seconds) at which wpa_cli pings the supplicant.
command Run a command.  The available commands are listed in the next section.
The following commands are available:
status get current WPA/EAPOL/EAP status
mib    get MIB variables (dot1x, dot11)
help   show this usage help
interface [ifname] show interfaces/select interface
level <debug level> change debug level
license show full wpa_cli license
logoff IEEE 802.1X EAPOL state machine logoff
logon  IEEE 802.1X EAPOL state machine logon
set    set variables (shows list of variables when run without arguments)
pmksa  show PMKSA cache
reassociate force reassociation
reconfigure force wpa_supplicant to re-read its configuration file
preauthenticate <BSSID> force preauthentication
identity <network id> <identity> configure identity for an SSID
password <network id> <password> configure password for an SSID
pin <network id> <pin> configure pin for an SSID
otp <network id> <password> configure one-time-password for an SSID
bssid <network id> <BSSID> set preferred BSSID for an SSID
list_networks list configured networks
terminate terminate wpa_supplicant
quit   exit wpa_cli
wpa_supplicant(8)
wpa_supplicant is copyright (c) 2003-2019, Jouni Malinen <j@w1.fi> and contributors.  All Rights Reserved.
This program is licensed under the BSD license (the one with advertisement clause removed).
VIRSH(1)                     Virtualization Support                     VIRSH(1)
virsh - management user interface
virsh [OPTION]... [COMMAND_STRING]
virsh [OPTION]... COMMAND [ARG]...
The virsh program is the main interface for managing virsh guest domains. The program can be used to create, pause, and shutdown domains. It can also be used to list current domains. Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). It is free software available under the GNU Lesser General Public License. Virtualization of the Linux Operating System means the ability to run multiple instances of Operating Systems concurrently on a single hardware system where the basic resources are driven by a Linux instance. The library aims at providing a long term stable C API.  It currently supports Xen, QEMU, KVM, LXC, OpenVZ, VirtualBox and VMware ESX.
The basic structure of most virsh usage is:
virsh [OPTION]... <command> <domain> [ARG]...
Where command is one of the commands listed below; domain is the numeric domain id, or the domain name, or the domain UUID; and ARGS are command specific options.  There are a few exceptions to this rule in the cases where the command in question acts on all domains, the entire machine, or directly on the xen hypervisor.  Those exceptions will be clear for each of those commands.  Note: it is permissible to give numeric names to domains, however, doing so will result in a domain that can only be identified by domain id. In other words, if a numeric value is supplied it will be interpreted as a domain id, not as a name. Any command starting with # is treated as a comment and silently ignored, all other unrecognized commands are diagnosed.
The virsh program can be used either to run one COMMAND by giving the command and its arguments on the shell command line, or a COMMAND_STRING which is a single shell argument consisting of multiple COMMAND actions and their arguments joined with whitespace and separated by semicolons or newlines between commands, where unquoted backslash-newline pairs are elided.  Within COMMAND_STRING, virsh understands the same single, double, and backslash escapes as the shell, although you must add another layer of shell escaping in creating the single shell argument, and any word starting with unquoted # begins a comment that ends at newline.  If no command is given in the command line, virsh will then start a minimal interpreter waiting for your commands, and the quit command will then exit the program.
The virsh program understands the following OPTIONS.
-c, --connect URI
Connect to the specified URI, as if by the connect command, instead of the default connection.
-d, --debug LEVEL
Enable debug messages at integer LEVEL and above.  LEVEL can range from 0 to 4 (default).  See the documentation of VIRSH_DEBUG environment variable below for the description of each LEVEL.
• -e, --escape string
Set alternative escape sequence for console command. By default, telnet's ^] is used. Allowed characters when using hat notation are: alphabetic character, @, [, ], , ^, _.
• -h, --help
Ignore all other arguments, and behave as if the help command were given instead.
• -k, --keepalive-interval INTERVAL
Set an INTERVAL (in seconds) for sending keepalive messages to check whether connection to the server is still alive.  Setting the interval to 0 disables client keepalive mechanism.
• -K, --keepalive-count COUNT
Set a number of times keepalive message can be sent without getting an answer from the server without marking the connection dead.  There is no effect to this setting in case the INTERVAL is set to 0.
• -l, --log FILE
Output logging details to FILE.
• -q, --quiet
Avoid extra informational messages.
• -r, --readonly
Make the initial connection read-only, as if by the --readonly option of the connect command.
• -t, --timing
Output elapsed time information for each command.
• -v, --version[=short]
Ignore all other arguments, and prints the version of the libvirt library virsh is coming from
• -V, --version=long
Ignore all other arguments, and prints the version of the libvirt library virsh is coming from and which options and driver are compiled in.
Most virsh operations rely upon the libvirt library being able to connect to an already running libvirtd service.  This can usually be done using the command service libvirtd start.
Most virsh commands require root privileges to run due to the communications channels used to talk to the hypervisor.  Running as non root will return an error.
Most virsh commands act synchronously, except maybe shutdown, setvcpus and setmem. In those cases the fact that the virsh program returned, may not mean the action is complete and you must poll periodically to detect that the guest completed the operation.
virsh strives for backward compatibility.  Although the help command only lists the preferred usage of a command, if an older version of virsh supported an alternate spelling of a command or option (such as --tunnelled instead of --tunneled), then scripts using that older spelling will continue to work.
Several virsh commands take an optionally scaled integer; if no scale is provided, then the default is listed in the command (for historical reasons, some commands default to bytes, while other commands default to kibibytes).  The following case-insensitive suffixes can be used to select a specific scale:
b, byte  byte      1 KB       kilobyte  1,000 k, KiB   kibibyte  1,024 MB       megabyte  1,000,000 M, MiB   mebibyte  1,048,576 GB       gigabyte  1,000,000,000 G, GiB   gibibyte  1,073,741,824 TB       terabyte  1,000,000,000,000 T, TiB   tebibyte  1,099,511,627,776 PB       petabyte  1,000,000,000,000,000 P, PiB   pebibyte  1,125,899,906,842,624 EB       exabyte   1,000,000,000,000,000,000 E, EiB   exbibyte  1,152,921,504,606,846,976
The following commands are generic i.e. not specific to a domain.
help Syntax:
help [command-or-group]
This lists each of the virsh commands.  When used without options, all commands are listed, one per line, grouped into related categories, displaying the keyword for each group.
To display only commands for a specific group, give the keyword for that group as an option.  For example:
virsh # help host
Host and Hypervisor (help keyword 'host'): capabilities                   capabilities cpu-models                     show the CPU models for an architecture connect                        (re)connect to hypervisor freecell                       NUMA free memory hostname                       print the hypervisor hostname qemu-attach                    Attach to existing QEMU process qemu-monitor-command           QEMU Monitor Command qemu-agent-command             QEMU Guest Agent Command sysinfo                        print the hypervisor sysinfo uri                            print the hypervisor canonical URI
To display detailed information for a specific command, give its name as the option instead.  For example:
virsh # help list NAME list - list domains
SYNOPSIS list [--inactive] [--all]
DESCRIPTION Returns list of domains.
OPTIONS --inactive       list inactive domains --all            list inactive & active domains
quit, exit Syntax:
quit exit
quit this interactive terminal
version Syntax:
version [--daemon]
Will print out the major version info about what this built from.  If --daemon is specified then the version of the libvirt daemon is included in the output.
$ virsh version Compiled against library: libvirt 1.2.3 Using library: libvirt 1.2.3 Using API: QEMU 1.2.3 Running hypervisor: QEMU 2.0.50
$ virsh version --daemon Compiled against library: libvirt 1.2.3 Using library: libvirt 1.2.3 Using API: QEMU 1.2.3 Running hypervisor: QEMU 2.0.50 Running against daemon: 1.2.6
cd Syntax:
cd [directory]
Will change current directory to directory.  The default directory for the cd command is the home directory or, if there is no HOME variable in the environment, the root directory.
This command is only available in interactive mode.
pwd Syntax:
Will print the current directory.
connect Syntax:
connect [URI] [--readonly]
(Re)-Connect to the hypervisor. When the shell is first started, this is automatically run with the URI parameter requested by the -c option on the command line. The URI parameter specifies how to connect to the hypervisor. The URI docs https://libvirt.org/uri.html list the values supported, but the most common are:
• xen:///system
this is used to connect to the local Xen hypervisor
• qemu:///system
connect locally as root to the daemon supervising QEMU and KVM domains
• qemu:///session
connect locally as a normal user to his own set of QEMU and KVM domains
• lxc:///system
connect to a local linux container
To find the currently used URI, check the uri command documented below.
For remote access see the URI docs https://libvirt.org/uri.html on how to make URIs. The --readonly option allows for read-only connection
uri Syntax:
Prints the hypervisor canonical URI, can be useful in shell mode.
hostname Syntax:
Print the hypervisor hostname.
sysinfo Syntax:
Print the XML representation of the hypervisor sysinfo, if available.
nodeinfo Syntax:
nodeinfo
Returns basic information about the node, like number and type of CPU, and size of the physical memory. The output corresponds to virNodeInfo structure. Specifically, the "CPU socket(s)" field means number of CPU sockets per NUMA cell. The information libvirt displays is dependent upon what each architecture may provide.
nodecpumap Syntax:
nodecpumap [--pretty]
Displays the node's total number of CPUs, the number of online CPUs and the list of online CPUs.
With --pretty the online CPUs are printed as a range instead of a list.
nodecpustats Syntax:
nodecpustats [cpu] [--percent]
Returns cpu stats of the node.  If cpu is specified, this will print the specified cpu statistics only.  If --percent is specified, this will print the percentage of each kind of cpu statistics during 1 second.
nodememstats Syntax:
nodememstats [cell]
Returns memory stats of the node.  If cell is specified, this will print the specified cell statistics only.
nodesuspend Syntax:
nodesuspend [target] [duration]
Puts the node (host machine) into a system-wide sleep state and schedule the node's Real-Time-Clock interrupt to resume the node after the time duration specified by duration is out.  target specifies the state to which the host will be suspended to, it can be "mem" (suspend to RAM), "disk" (suspend to disk), or "hybrid" (suspend to both RAM and disk). duration specifies the time duration in seconds for which the host has to be suspended, it should be at least 60 seconds.
node-memory-tune Syntax:
node-memory-tune [shm-pages-to-scan] [shm-sleep-millisecs] [shm-merge-across-nodes]
Allows you to display or set the node memory parameters. shm-pages-to-scan can be used to set the number of pages to scan before the shared memory service goes to sleep; shm-sleep-millisecs can be used to set the number of millisecs the shared memory service should sleep before next scan; shm-merge-across-nodes specifies if pages from different numa nodes can be merged. When set to 0, only pages which physically reside in the memory area of same NUMA node can be merged. When set to 1, pages from all nodes can be merged. Default to 1.
Note: Currently the "shared memory service" only means KSM (Kernel Samepage Merging).
capabilities Syntax:
Print an XML document describing the capabilities of the hypervisor we are currently connected to. This includes a section on the host capabilities in terms of CPU and features, and a set of description for each kind of guest which can be virtualized. For a more complete description see:
https://libvirt.org/formatcaps.html
The XML also show the NUMA topology information if available.
domcapabilities Syntax:
domcapabilities [virttype] [emulatorbin] [arch] [machine]
Print an XML document describing the domain capabilities for the hypervisor we are connected to using information either sourced from an existing domain or taken from the virsh capabilities output. This may be useful if you intend to create a new domain and are curious if for instance it could make use of VFIO by creating a domain for the hypervisor with a specific emulator and architecture.
Each hypervisor will have different requirements regarding which options are required and which are optional. A hypervisor can support providing a default value for any of the options.
The virttype option specifies the virtualization type used. The value to be used is either from the 'type' attribute of the <domain/> top level element from the domain XML or the 'type' attribute found within each <guest/> element from the virsh capabilities output.  The emulatorbin option specifies the path to the emulator. The value to be used is either the <emulator> element in the domain XML or the virsh capabilities output. The arch option specifies the architecture to be used for the domain. The value to be used is either the "arch" attribute from the domain's XML <os/> element and <type/> subelement or the "name" attribute of an <arch/> element from the virsh capabililites output. The machine specifies the machine type for the emulator. The value to be used is either the "machine" attribute from the domain's XML <os/> element and <type/> subelement or one from a list of machines from the virsh capabilities output for a specific architecture and domain type.
For the QEMU hypervisor, a virttype of either 'qemu' or 'kvm' must be supplied along with either the emulatorbin or arch in order to generate output for the default machine.  Supplying a machine value will generate output for the specific machine.
pool-capabilities Syntax:
pool-capabilities
Print an XML document describing the storage pool capabilities for the connected storage driver. This may be useful if you intend to create a new storage pool and need to know the available pool types and supported storage pool source and target volume formats as well as the required source elements to create the pool.
inject-nmi Syntax: