---

   ex.1p    ( 1 )

---

Обоснование (Rationale)

The ex/vi specification is based on the historical practice found in the 4 BSD and System V implementations of ex and vi.

A restricted editor (both the historical red utility and modifications to ex) were considered and rejected for inclusion. Neither option provided the level of security that users might expect.

It is recognized that ex visual mode and related features would be difficult, if not impossible, to implement satisfactorily on a block-mode terminal, or a terminal without any form of cursor addressing; thus, it is not a mandatory requirement that such features should work on all terminals. It is the intention, however, that an ex implementation should provide the full set of capabilities on all terminals capable of supporting them.

Options The -c replacement for +command was inspired by the -e option of sed. Historically, all such commands (see edit and next as well) were executed from the last line of the edit buffer. This meant, for example, that "+/pattern" would fail unless the wrapscan option was set. POSIX.1‐2008 requires conformance to historical practice. The +command option is no longer specified by POSIX.1‐2008 but may be present in some implementations. Historically, some implementations restricted the ex commands that could be listed as part of the command line arguments. For consistency, POSIX.1‐2008 does not permit these restrictions.

In historical implementations of the editor, the -R option (and the readonly edit option) only prevented overwriting of files; appending to files was still permitted, mapping loosely into the csh noclobber variable. Some implementations, however, have not followed this semantic, and readonly does not permit appending either. POSIX.1‐2008 follows the latter practice, believing that it is a more obvious and intuitive meaning of readonly.

The -s option suppresses all interactive user feedback and is useful for editing scripts in batch jobs. The list of specific effects is historical practice. The terminal type ``incapable of supporting open and visual modes'' has historically been named ``dumb''.

The -t option was required because the ctags utility appears in POSIX.1‐2008 and the option is available in all historical implementations of ex.

Historically, the ex and vi utilities accepted a -x option, which did encryption based on the algorithm found in the historical crypt utility. The -x option for encryption, and the associated crypt utility, were omitted because the algorithm used was not specifiable and the export control laws of some nations make it difficult to export cryptographic technology. In addition, it did not historically provide the level of security that users might expect.

Standard Input An end-of-file condition is not equivalent to an end-of-file character. A common end-of-file character, <control>‐D, is historically an ex command.

There was no maximum line length in historical implementations of ex. Specifically, as it was parsed in chunks, the addresses had a different maximum length than the filenames. Further, the maximum line buffer size was declared as BUFSIZ, which was different lengths on different systems. This version selected the value of {LINE_MAX} to impose a reasonable restriction on portable usage of ex and to aid test suite writers in their development of realistic tests that exercise this limit.

Input Files It was an explicit decision by the standard developers that a <newline> be added to any file lacking one. It was believed that this feature of ex and vi was relied on by users in order to make text files lacking a trailing <newline> more portable. It is recognized that this will require a user-specified option or extension for implementations that permit ex and vi to edit files of type other than text if such files are not otherwise identified by the system. It was agreed that the ability to edit files of arbitrary type can be useful, but it was not considered necessary to mandate that an ex or vi implementation be required to handle files other than text files.

The paragraph in the INPUT FILES section, ``By default, ...'', is intended to close a long-standing security problem in ex and vi; that of the ``modeline'' or ``modelines'' edit option. This feature allows any line in the first or last five lines of the file containing the strings "ex:" or "vi:" (and, apparently, "ei:" or "vx:") to be a line containing editor commands, and ex interprets all the text up to the next ':' or <newline> as a command. Consider the consequences, for example, of an unsuspecting user using ex or vi as the editor when replying to a mail message in which a line such as:

ex:! rm -rf :

appeared in the signature lines. The standard developers believed strongly that an editor should not by default interpret any lines of a file. Vendors are strongly urged to delete this feature from their implementations of ex and vi.

Asynchronous Events The intention of the phrase ``complete write'' is that the entire edit buffer be written to stable storage. The note regarding temporary files is intended for implementations that use temporary files to back edit buffers unnamed by the user.

Historically, SIGQUIT was ignored by ex, but was the equivalent of the Q command in visual mode; that is, it exited visual mode and entered ex mode. POSIX.1‐2008 permits, but does not require, this behavior. Historically, SIGINT was often used by vi users to terminate text input mode (<control>‐C is often easier to enter than <ESC>). Some implementations of vi alerted the terminal on this event, and some did not. POSIX.1‐2008 requires that SIGINT behave identically to <ESC>, and that the terminal not be alerted.

Historically, suspending the ex editor during text input mode was similar to SIGINT, as completed lines were retained, but any partial line discarded, and the editor returned to command mode. POSIX.1‐2008 is silent on this issue; implementations are encouraged to follow historical practice, where possible.

Historically, the vi editor did not treat SIGTSTP as an asynchronous event, and it was therefore impossible to suspend the editor in visual text input mode. There are two major reasons for this. The first is that SIGTSTP is a broadcast signal on UNIX systems, and the chain of events where the shell execs an application that then execs vi usually caused confusion for the terminal state if SIGTSTP was delivered to the process group in the default manner. The second was that most implementations of the UNIX curses package did not handle SIGTSTP safely, and the receipt of SIGTSTP at the wrong time would cause them to crash. POSIX.1‐2008 is silent on this issue; implementations are encouraged to treat suspension as an asynchronous event if possible.

Historically, modifications to the edit buffer made before SIGINT interrupted an operation were retained; that is, anywhere from zero to all of the lines to be modified might have been modified by the time the SIGINT arrived. These changes were not discarded by the arrival of SIGINT. POSIX.1‐2008 permits this behavior, noting that the undo command is required to be able to undo these partially completed commands.

The action taken for signals other than SIGINT, SIGCONT, SIGHUP, and SIGTERM is unspecified because some implementations attempt to save the edit buffer in a useful state when other signals are received.

Standard Error For ex/vi, diagnostic messages are those messages reported as a result of a failed attempt to invoke ex or vi, such as invalid options or insufficient resources, or an abnormal termination condition. Diagnostic messages should not be confused with the error messages generated by inappropriate or illegal user commands.

Initialization in ex and vi If an ex command (other than cd, chdir, or source) has a filename argument, one or both of the alternate and current pathnames will be set. Informally, they are set as follows:

1. If the ex command is one that replaces the contents of the edit buffer, and it succeeds, the current pathname will be set to the filename argument (the first filename argument in the case of the next command) and the alternate pathname will be set to the previous current pathname, if there was one.

2. In the case of the file read/write forms of the read and write commands, if there is no current pathname, the current pathname will be set to the filename argument.

3. Otherwise, the alternate pathname will be set to the filename argument.

For example, :edit foo and :recover foo, when successful, set the current pathname, and, if there was a previous current pathname, the alternate pathname. The commands :write, !command, and :edit set neither the current or alternate pathnames. If the :edit foo command were to fail for some reason, the alternate pathname would be set. The read and write commands set the alternate pathname to their file argument, unless the current pathname is not set, in which case they set the current pathname to their file arguments. The alternate pathname was not historically set by the :source command. POSIX.1‐2008 requires conformance to historical practice. Implementations adding commands that take filenames as arguments are encouraged to set the alternate pathname as described here.

Historically, ex and vi read the .exrc file in the $HOME directory twice, if the editor was executed in the $HOME directory. POSIX.1‐2008 prohibits this behavior.

Historically, the 4 BSD ex and vi read the $HOME and local .exrc files if they were owned by the real ID of the user, or the sourceany option was set, regardless of other considerations. This was a security problem because it is possible to put normal UNIX system commands inside a .exrc file. POSIX.1‐2008 does not specify the sourceany option, and historical implementations are encouraged to delete it.

The .exrc files must be owned by the real ID of the user, and not writable by anyone other than the owner. The appropriate privileges exception is intended to permit users to acquire special privileges, but continue to use the .exrc files in their home directories.

System V Release 3.2 and later vi implementations added the option [no]exrc. The behavior is that local .exrc files are read-only if the exrc option is set. The default for the exrc option was off, so by default, local .exrc files were not read. The problem this was intended to solve was that System V permitted users to give away files, so there is no possible ownership or writeability test to ensure that the file is safe. This is still a security problem on systems where users can give away files, but there is nothing additional that POSIX.1‐2008 can do. The implementation-defined exception is intended to permit groups to have local .exrc files that are shared by users, by creating pseudo-users to own the shared files.

POSIX.1‐2008 does not mention system-wide ex and vi start-up files. While they exist in several implementations of ex and vi, they are not present in any implementations considered historical practice by POSIX.1‐2008. Implementations that have such files should use them only if they are owned by the real user ID or an appropriate user (for example, root on UNIX systems) and if they are not writable by any user other than their owner. System-wide start-up files should be read before the EXINIT variable, $HOME/.exrc, or local .exrc files are evaluated.

Historically, any ex command could be entered in the EXINIT variable or the .exrc file, although ones requiring that the edit buffer already contain lines of text generally caused historical implementations of the editor to drop core. POSIX.1‐2008 requires that any ex command be permitted in the EXINIT variable and .exrc files, for simplicity of specification and consistency, although many of them will obviously fail under many circumstances.

The initialization of the contents of the edit buffer uses the phrase ``the effect shall be'' with regard to various ex commands. The intent of this phrase is that edit buffer contents loaded during the initialization phase not be lost; that is, loading the edit buffer should fail if the .exrc file read in the contents of a file and did not subsequently write the edit buffer. An additional intent of this phrase is to specify that the initial current line and column is set as specified for the individual ex commands.

Historically, the -t option behaved as if the tag search were a +command; that is, it was executed from the last line of the file specified by the tag. This resulted in the search failing if the pattern was a forward search pattern and the wrapscan edit option was not set. POSIX.1‐2008 does not permit this behavior, requiring that the search for the tag pattern be performed on the entire file, and, if not found, that the current line be set to a more reasonable location in the file.

Historically, the empty edit buffer presented for editing when a file was not specified by the user was unnamed. This is permitted by POSIX.1‐2008; however, implementations are encouraged to provide users a temporary filename for this buffer because it permits them the use of ex commands that use the current pathname during temporary edit sessions.

Historically, the file specified using the -t option was not part of the current argument list. This practice is permitted by POSIX.1‐2008; however, implementations are encouraged to include its name in the current argument list for consistency.

Historically, the -c command was generally not executed until a file that already exists was edited. POSIX.1‐2008 requires conformance to this historical practice. Commands that could cause the -c command to be executed include the ex commands edit, next, recover, rewind, and tag, and the vi commands <control>‐^ and <control>‐]. Historically, reading a file into an edit buffer did not cause the -c command to be executed (even though it might set the current pathname) with the exception that it did cause the -c command to be executed if: the editor was in ex mode, the edit buffer had no current pathname, the edit buffer was empty, and no read commands had yet been attempted. For consistency and simplicity of specification, POSIX.1‐2008 does not permit this behavior.

Historically, the -r option was the same as a normal edit session if there was no recovery information available for the file. This allowed users to enter:

vi -r *.c

and recover whatever files were recoverable. In some implementations, recovery was attempted only on the first file named, and the file was not entered into the argument list; in others, recovery was attempted for each file named. In addition, some historical implementations ignored -r if -t was specified or did not support command line file arguments with the -t option. For consistency and simplicity of specification, POSIX.1‐2008 disallows these special cases, and requires that recovery be attempted the first time each file is edited.

Historically, vi initialized the ` and ' marks, but ex did not. This meant that if the first command in ex mode was visual or if an ex command was executed first (for example, vi +10 file), vi was entered without the marks being initialized. Because the standard developers believed the marks to be generally useful, and for consistency and simplicity of specification, POSIX.1‐2008 requires that they always be initialized if in open or visual mode, or if in ex mode and the edit buffer is not empty. Not initializing it in ex mode if the edit buffer is empty is historical practice; however, it has always been possible to set (and use) marks in empty edit buffers in open and visual mode edit sessions.

Addressing Historically, ex and vi accepted the additional addressing forms '\/' and '\?'. They were equivalent to "//" and "??", respectively. They are not required by POSIX.1‐2008, mostly because nobody can remember whether they ever did anything different historically.

Historically, ex and vi permitted an address of zero for several commands, and permitted the % address in empty files for others. For consistency, POSIX.1‐2008 requires support for the former in the few commands where it makes sense, and disallows it otherwise. In addition, because POSIX.1‐2008 requires that % be logically equivalent to "1,$", it is also supported where it makes sense and disallowed otherwise.

Historically, the % address could not be followed by further addresses. For consistency and simplicity of specification, POSIX.1‐2008 requires that additional addresses be supported.

All of the following are valid addresses:

+++ Three lines after the current line.

/re/- One line before the next occurrence of re.

-2 Two lines before the current line.

3 ---- 2 Line one (note intermediate negative address).

1 2 3 Line six.

Any number of addresses can be provided to commands taking addresses; for example, "1,2,3,4,5p" prints lines 4 and 5, because two is the greatest valid number of addresses accepted by the print command. This, in combination with the <semicolon> delimiter, permits users to create commands based on ordered patterns in the file. For example, the command 3;/foo/;+2print will display the first line after line 3 that contains the pattern foo, plus the next two lines. Note that the address 3; must be evaluated before being discarded because the search origin for the /foo/ command depends on this.

Historically, values could be added to addresses by including them after one or more <blank> characters; for example, 3 - 5p wrote the seventh line of the file, and /foo/ 5 was the same as /foo/+5. However, only absolute values could be added; for example, 5 /foo/ was an error. POSIX.1‐2008 requires conformance to historical practice. Address offsets are separately specified from addresses because they could historically be provided to visual mode search commands.

Historically, any missing addresses defaulted to the current line. This was true for leading and trailing <comma>-delimited addresses, and for trailing <semicolon>-delimited addresses. For consistency, POSIX.1‐2008 requires it for leading <semicolon> addresses as well.

Historically, ex and vi accepted the '^' character as both an address and as a flag offset for commands. In both cases it was identical to the '-' character. POSIX.1‐2008 does not require or prohibit this behavior.

Historically, the enhancements to basic regular expressions could be used in addressing; for example, '~', '\<', and '\>'. POSIX.1‐2008 requires conformance to historical practice; that is, that regular expression usage be consistent, and that regular expression enhancements be supported wherever regular expressions are used.

Command Line Parsing in ex Historical ex command parsing was even more complex than that described here. POSIX.1‐2008 requires the subset of the command parsing that the standard developers believed was documented and that users could reasonably be expected to use in a portable fashion, and that was historically consistent between implementations. (The discarded functionality is obscure, at best.) Historical implementations will require changes in order to comply with POSIX.1‐2008; however, users are not expected to notice any of these changes. Most of the complexity in ex parsing is to handle three special termination cases:

1. The !, global, v, and the filter versions of the read and write commands are delimited by <newline> characters (they can contain <vertical-line> characters that are usually shell pipes).

2. The ex, edit, next, and visual in open and visual mode commands all take ex commands, optionally containing <vertical-line> characters, as their first arguments.

3. The s command takes a regular expression as its first argument, and uses the delimiting characters to delimit the command.

Historically, <vertical-line> characters in the +command argument of the ex, edit, next, vi, and visual commands, and in the pattern and replacement parts of the s command, did not delimit the command, and in the filter cases for read and write, and the !, global, and v commands, they did not delimit the command at all. For example, the following commands are all valid:

:edit +25 | s/abc/ABC/ file.c :s/ | /PIPE/ :read !spell % | columnate :global/pattern/p | l :s/a/b/ | s/c/d | set

Historically, empty or <blank> filled lines in .exrc files and sourced files (as well as EXINIT variables and ex command scripts) were treated as default commands; that is, print commands. POSIX.1‐2008 specifically requires that they be ignored when encountered in .exrc and sourced files to eliminate a common source of new user error.

Historically, ex commands with multiple adjacent (or <blank>-separated) vertical lines were handled oddly when executed from ex mode. For example, the command ||| <carriage- return>, when the cursor was on line 1, displayed lines 2, 3, and 5 of the file. In addition, the command | would only display the line after the next line, instead of the next two lines. The former worked more logically when executed from vi mode, and displayed lines 2, 3, and 4. POSIX.1‐2008 requires the vi behavior; that is, a single default command and line number increment for each command separator, and trailing <newline> characters after <vertical-line> separators are discarded.

Historically, ex permitted a single extra <colon> as a leading command character; for example, :g/pattern/:p was a valid command. POSIX.1‐2008 generalizes this to require that any number of leading <colon> characters be stripped.

Historically, any prefix of the delete command could be followed without intervening <blank> characters by a flag character because in the command d p, p is interpreted as the buffer p. POSIX.1‐2008 requires conformance to historical practice.

Historically, the k command could be followed by the mark name without intervening <blank> characters. POSIX.1‐2008 requires conformance to historical practice.

Historically, the s command could be immediately followed by flag and option characters; for example, s/e/E/|s|sgc3p was a valid command. However, flag characters could not stand alone; for example, the commands sp and s l would fail, while the command sgp and s gl would succeed. (Obviously, the '#' flag character was used as a delimiter character if it followed the command.) Another issue was that option characters had to precede flag characters even when the command was fully specified; for example, the command s/e/E/pg would fail, while the command s/e/E/gp would succeed. POSIX.1‐2008 requires conformance to historical practice.

Historically, the first command name that had a prefix matching the input from the user was the executed command; for example, ve, ver, and vers all executed the version command. Commands were in a specific order, however, so that a matched append, not abbreviate. POSIX.1‐2008 requires conformance to historical practice. The restriction on command search order for implementations with extensions is to avoid the addition of commands such that the historical prefixes would fail to work portably.

Historical implementations of ex and vi did not correctly handle multiple ex commands, separated by <vertical-line> characters, that entered or exited visual mode or the editor. Because implementations of vi exist that do not exhibit this failure mode, POSIX.1‐2008 does not permit it.

The requirement that alphabetic command names consist of all following alphabetic characters up to the next non-alphabetic character means that alphabetic command names must be separated from their arguments by one or more non-alphabetic characters, normally a <blank> or '!' character, except as specified for the exceptions, the delete, k, and s commands.

Historically, the repeated execution of the ex default print commands (<control>‐D, eof, <newline>, <carriage-return>) erased any prompting character and displayed the next lines without scrolling the terminal; that is, immediately below any previously displayed lines. This provided a cleaner presentation of the lines in the file for the user. POSIX.1‐2008 does not require this behavior because it may be impossible in some situations; however, implementations are strongly encouraged to provide this semantic if possible.

Historically, it was possible to change files in the middle of a command, and have the rest of the command executed in the new file; for example:

:edit +25 file.c | s/abc/ABC/ | 1

was a valid command, and the substitution was attempted in the newly edited file. POSIX.1‐2008 requires conformance to historical practice. The following commands are examples that exercise the ex parser:

echo 'foo | bar' > file1; echo 'foo/bar' > file2; vi :edit +1 | s/|/PIPE/ | w file1 | e file2 | 1 | s/\//SLASH/ | wq

Historically, there was no protection in editor implementations to avoid ex global, v, @, or * commands changing edit buffers during execution of their associated commands. Because this would almost invariably result in catastrophic failure of the editor, and implementations exist that do exhibit these problems, POSIX.1‐2008 requires that changing the edit buffer during a global or v command, or during a @ or * command for which there will be more than a single execution, be an error. Implementations supporting multiple edit buffers simultaneously are strongly encouraged to apply the same semantics to switching between buffers as well.

The ex command quoting required by POSIX.1‐2008 is a superset of the quoting in historical implementations of the editor. For example, it was not historically possible to escape a <blank> in a filename; for example, :edit foo\\\ bar would report that too many filenames had been entered for the edit command, and there was no method of escaping a <blank> in the first argument of an edit, ex, next, or visual command at all. POSIX.1‐2008 extends historical practice, requiring that quoting behavior be made consistent across all ex commands, except for the map, unmap, abbreviate, and unabbreviate commands, which historically used <control>‐V instead of <backslash> characters for quoting. For those four commands, POSIX.1‐2008 requires conformance to historical practice.

Backslash quoting in ex is non-intuitive. <backslash>-escapes are ignored unless they escape a special character; for example, when performing file argument expansion, the string "\\%" is equivalent to '\%', not "\<current pathname>". This can be confusing for users because <backslash> is usually one of the characters that causes shell expansion to be performed, and therefore shell quoting rules must be taken into consideration. Generally, quoting characters are only considered if they escape a special character, and a quoting character must be provided for each layer of parsing for which the character is special. As another example, only a single <backslash> is necessary for the '\l' sequence in substitute replacement patterns, because the character 'l' is not special to any parsing layer above it.

<control>‐V quoting in ex is slightly different from backslash quoting. In the four commands where <control>‐V quoting applies (abbreviate, unabbreviate, map, and unmap), any character may be escaped by a <control>‐V whether it would have a special meaning or not. POSIX.1‐2008 requires conformance to historical practice.

Historical implementations of the editor did not require delimiters within character classes to be escaped; for example, the command :s/[/]// on the string "xxx/yyy" would delete the '/' from the string. POSIX.1‐2008 disallows this historical practice for consistency and because it places a large burden on implementations by requiring that knowledge of regular expressions be built into the editor parser.

Historically, quoting <newline> characters in ex commands was handled inconsistently. In most cases, the <newline> character always terminated the command, regardless of any preceding escape character, because <backslash> characters did not escape <newline> characters for most ex commands. However, some ex commands (for example, s, map, and abbreviation) permitted <newline> characters to be escaped (although in the case of map and abbreviation, <control>‐V characters escaped them instead of <backslash> characters). This was true in not only the command line, but also .exrc and sourced files. For example, the command:

map = foo<control-V><newline>bar

would succeed, although it was sometimes difficult to get the <control>‐V and the inserted <newline> passed to the ex parser. For consistency and simplicity of specification, POSIX.1‐2008 requires that it be possible to escape <newline> characters in ex commands at all times, using <backslash> characters for most ex commands, and using <control>‐V characters for the map and abbreviation commands. For example, the command print<newline>list is required to be parsed as the single command print<newline>list. While this differs from historical practice, POSIX.1‐2008 developers believed it unlikely that any script or user depended on the historical behavior.

Historically, an error in a command specified using the -c option did not cause the rest of the -c commands to be discarded. POSIX.1‐2008 disallows this for consistency with mapped keys, the @, global, source, and v commands, the EXINIT environment variable, and the .exrc files.

Input Editing in ex One of the common uses of the historical ex editor is over slow network connections. Editors that run in canonical mode can require far less traffic to and from, and far less processing on, the host machine, as well as more easily supporting block-mode terminals. For these reasons, POSIX.1‐2008 requires that ex be implemented using canonical mode input processing, as was done historically.

POSIX.1‐2008 does not require the historical 4 BSD input editing characters ``word erase'' or ``literal next''. For this reason, it is unspecified how they are handled by ex, although they must have the required effect. Implementations that resolve them after the line has been ended using a <newline> or <control>‐M character, and implementations that rely on the underlying system terminal support for this processing, are both conforming. Implementations are strongly urged to use the underlying system functionality, if at all possible, for compatibility with other system text input interfaces.

Historically, when the eof character was used to decrement the autoindent level, the cursor moved to display the new end of the autoindent characters, but did not move the cursor to a new line, nor did it erase the <control>‐D character from the line. POSIX.1‐2008 does not specify that the cursor remain on the same line or that the rest of the line is erased; however, implementations are strongly encouraged to provide the best possible user interface; that is, the cursor should remain on the same line, and any <control>‐D character on the line should be erased.

POSIX.1‐2008 does not require the historical 4 BSD input editing character ``reprint'', traditionally <control>‐R, which redisplayed the current input from the user. For this reason, and because the functionality cannot be implemented after the line has been terminated by the user, POSIX.1‐2008 makes no requirements about this functionality. Implementations are strongly urged to make this historical functionality available, if possible.

Historically, <control>‐Q did not perform a literal next function in ex, as it did in vi. POSIX.1‐2008 requires conformance to historical practice to avoid breaking historical ex scripts and .exrc files.

eof Whether the eof character immediately modifies the autoindent characters in the prompt is left unspecified so that implementations can conform in the presence of systems that do not support this functionality. Implementations are encouraged to modify the line and redisplay it immediately, if possible.

The specification of the handling of the eof character differs from historical practice only in that eof characters are not discarded if they follow normal characters in the text input. Historically, they were always discarded.

Command Descriptions in ex Historically, several commands (for example, global, v, visual, s, write, wq, yank, !, <, >, &, and ~) were executable in empty files (that is, the default address(es) were 0), or permitted explicit addresses of 0 (for example, 0 was a valid address, or 0,0 was a valid range). Addresses of 0, or command execution in an empty file, make sense only for commands that add new text to the edit buffer or write commands (because users may wish to write empty files). POSIX.1‐2008 requires this behavior for such commands and disallows it otherwise, for consistency and simplicity of specification.

A count to an ex command has been historically corrected to be no greater than the last line in a file; for example, in a five-line file, the command 1,6print would fail, but the command 1print300 would succeed. POSIX.1‐2008 requires conformance to historical practice.

Historically, the use of flags in ex commands could be obscure. General historical practice was as described by POSIX.1‐2008, but there were some special cases. For instance, the list, number, and print commands ignored trailing address offsets; for example, 3p +++# would display line 3, and 3 would be the current line after the execution of the command. The open and visual commands ignored both the trailing offsets and the trailing flags. Also, flags specified to the open and visual commands interacted badly with the list edit option, and setting and then unsetting it during the open/visual session would cause vi to stop displaying lines in the specified format. For consistency and simplicity of specification, POSIX.1‐2008 does not permit any of these exceptions to the general rule.

POSIX.1‐2008 uses the word copy in several places when discussing buffers. This is not intended to imply implementation.

Historically, ex users could not specify numeric buffers because of the ambiguity this would cause; for example, in the command 3 delete 2, it is unclear whether 2 is a buffer name or a count. POSIX.1‐2008 requires conformance to historical practice by default, but does not preclude extensions.

Historically, the contents of the unnamed buffer were frequently discarded after commands that did not explicitly affect it; for example, when using the edit command to switch files. For consistency and simplicity of specification, POSIX.1‐2008 does not permit this behavior.

The ex utility did not historically have access to the numeric buffers, and, furthermore, deleting lines in ex did not modify their contents. For example, if, after doing a delete in vi, the user switched to ex, did another delete, and then switched back to vi, the contents of the numeric buffers would not have changed. POSIX.1‐2008 requires conformance to historical practice. Numeric buffers are described in the ex utility in order to confine the description of buffers to a single location in POSIX.1‐2008.

The metacharacters that trigger shell expansion in file arguments match historical practice, as does the method for doing shell expansion. Implementations wishing to provide users with the flexibility to alter the set of metacharacters are encouraged to provide a shellmeta string edit option.

Historically, ex commands executed from vi refreshed the screen when it did not strictly need to do so; for example, :!date > /dev/null does not require a screen refresh because the output of the UNIX date command requires only a single line of the screen. POSIX.1‐2008 requires that the screen be refreshed if it has been overwritten, but makes no requirements as to how an implementation should make that determination. Implementations may prompt and refresh the screen regardless.

Abbreviate Historical practice was that characters that were entered as part of an abbreviation replacement were subject to map expansions, the showmatch edit option, further abbreviation expansions, and so on; that is, they were logically pushed onto the terminal input queue, and were not a simple replacement. POSIX.1‐2008 requires conformance to historical practice. Historical practice was that whenever a non-word character (that had not been escaped by a <control>‐V) was entered after a word character, vi would check for abbreviations. The check was based on the type of the character entered before the word character of the word/non-word pair that triggered the check. The word character of the word/non-word pair that triggered the check and all characters entered before the trigger pair that were of that type were included in the check, with the exception of <blank> characters, which always delimited the abbreviation.

This means that, for the abbreviation to work, the lhs must end with a word character, there can be no transitions from word to non-word characters (or vice versa) other than between the last and next-to-last characters in the lhs, and there can be no <blank> characters in the lhs. In addition, because of the historical quoting rules, it was impossible to enter a literal <control>‐V in the lhs. POSIX.1‐2008 requires conformance to historical practice. Historical implementations did not inform users when abbreviations that could never be used were entered; implementations are strongly encouraged to do so.

For example, the following abbreviations will work:

:ab (p REPLACE :ab p REPLACE :ab ((p REPLACE

The following abbreviations will not work:

:ab ( REPLACE :ab (pp REPLACE

Historical practice is that words on the vi colon command line were subject to abbreviation expansion, including the arguments to the abbrev (and more interestingly) the unabbrev command. Because there are implementations that do not do abbreviation expansion for the first argument to those commands, this is permitted, but not required, by POSIX.1‐2008. However, the following sequence:

:ab foo bar :ab foo baz

resulted in the addition of an abbreviation of "baz" for the string "bar" in historical ex/vi, and the sequence:

:ab foo1 bar :ab foo2 bar :unabbreviate foo2

deleted the abbreviation "foo1", not "foo2". These behaviors are not permitted by POSIX.1‐2008 because they clearly violate the expectations of the user.

It was historical practice that <control>‐V, not <backslash>, characters be interpreted as escaping subsequent characters in the abbreviate command. POSIX.1‐2008 requires conformance to historical practice; however, it should be noted that an abbreviation containing a <blank> will never work.

Append Historically, any text following a <vertical-line> command separator after an append, change, or insert command became part of the insert text. For example, in the command:

:g/pattern/append|stuff1

a line containing the text "stuff1" would be appended to each line matching pattern. It was also historically valid to enter:

:append|stuff1 stuff2 .

and the text on the ex command line would be appended along with the text inserted after it. There was an historical bug, however, that the user had to enter two terminating lines (the '.' lines) to terminate text input mode in this case. POSIX.1‐2008 requires conformance to historical practice, but disallows the historical need for multiple terminating lines.

Change See the RATIONALE for the append command. Historical practice for cursor positioning after the change command when no text is input, is as described in POSIX.1‐2008. However, one System V implementation is known to have been modified such that the cursor is positioned on the first address specified, and not on the line before the first address. POSIX.1‐2008 disallows this modification for consistency.

Historically, the change command did not support buffer arguments, although some implementations allow the specification of an optional buffer. This behavior is neither required nor disallowed by POSIX.1‐2008.

Change Directory A common extension in ex implementations is to use the elements of a cdpath edit option as prefix directories for path arguments to chdir that are relative pathnames and that do not have '.' or ".." as their first component. Elements in the cdpath edit option are <colon>-separated. The initial value of the cdpath edit option is the value of the shell CDPATH environment variable. This feature was not included in POSIX.1‐2008 because it does not exist in any of the implementations considered historical practice.

Copy Historical implementations of ex permitted copies to lines inside of the specified range; for example, :2,5copy3 was a valid command. POSIX.1‐2008 requires conformance to historical practice.

Delete POSIX.1‐2008 requires support for the historical parsing of a delete command followed by flags, without any intervening <blank> characters. For example:

1dp Deletes the first line and prints the line that was second.

1delep As for 1dp.

1d Deletes the first line, saving it in buffer p.

1d p1l (Pee-one-ell.) Deletes the first line, saving it in buffer p, and listing the line that was second.

Edit Historically, any ex command could be entered as a +command argument to the edit command, although some (for example, insert and append) were known to confuse historical implementations. For consistency and simplicity of specification, POSIX.1‐2008 requires that any command be supported as an argument to the edit command.

Historically, the command argument was executed with the current line set to the last line of the file, regardless of whether the edit command was executed from visual mode or not. POSIX.1‐2008 requires conformance to historical practice.

Historically, the +command specified to the edit and next commands was delimited by the first <blank>, and there was no way to quote them. For consistency, POSIX.1‐2008 requires that the usual ex backslash quoting be provided.

Historically, specifying the +command argument to the edit command required a filename to be specified as well; for example, :edit +100 would always fail. For consistency and simplicity of specification, POSIX.1‐2008 does not permit this usage to fail for that reason.

Historically, only the cursor position of the last file edited was remembered by the editor. POSIX.1‐2008 requires that this be supported; however, implementations are permitted to remember and restore the cursor position for any file previously edited.

File Historical versions of the ex editor file command displayed a current line and number of lines in the edit buffer of 0 when the file was empty, while the vi <control>‐G command displayed a current line and number of lines in the edit buffer of 1 in the same situation. POSIX.1‐2008 does not permit this discrepancy, instead requiring that a message be displayed indicating that the file is empty.

Global The two-pass operation of the global and v commands is not intended to imply implementation, only the required result of the operation.

The current line and column are set as specified for the individual ex commands. This requirement is cumulative; that is, the current line and column must track across all the commands executed by the global or v commands.

Insert See the RATIONALE for the append command.

Historically, insert could not be used with an address of zero; that is, not when the edit buffer was empty. POSIX.1‐2008 requires that this command behave consistently with the append command.

Join The action of the join command in relation to the special characters is only defined for the POSIX locale because the correct amount of white space after a period varies; in Japanese none is required, in French only a single space, and so on.

List The historical output of the list command was potentially ambiguous. The standard developers believed correcting this to be more important than adhering to historical practice, and POSIX.1‐2008 requires unambiguous output.

Map Historically, command mode maps only applied to command names; for example, if the character 'x' was mapped to 'y', the command fx searched for the 'x' character, not the 'y' character. POSIX.1‐2008 requires this behavior. Historically, entering <control>‐V as the first character of a vi command was an error. Several implementations have extended the semantics of vi such that <control>‐V means that the subsequent command character is not mapped. This is permitted, but not required, by POSIX.1‐2008. Regardless, using <control>‐V to escape the second or later character in a sequence of characters that might match a map command, or any character in text input mode, is historical practice, and stops the entered keys from matching a map. POSIX.1‐2008 requires conformance to historical practice.

Historical implementations permitted digits to be used as a map command lhs, but then ignored the map. POSIX.1‐2008 requires that the mapped digits not be ignored.

The historical implementation of the map command did not permit map commands that were more than a single character in length if the first character was printable. This behavior is permitted, but not required, by POSIX.1‐2008.

Historically, mapped characters were remapped unless the remap edit option was not set, or the prefix of the mapped characters matched the mapping characters; for example, in the map:

:map ab abcd

the characters "ab" were used as is and were not remapped, but the characters "cd" were mapped if appropriate. This can cause infinite loops in the vi mapping mechanisms. POSIX.1‐2008 requires conformance to historical practice, and that such loops be interruptible.

Text input maps had the same problems with expanding the lhs for the ex map! and unmap! command as did the ex abbreviate and unabbreviate commands. See the RATIONALE for the ex abbreviate command. POSIX.1‐2008 requires similar modification of some historical practice for the map and unmap commands, as described for the abbreviate and unabbreviate commands.

Historically, maps that were subsets of other maps behaved differently depending on the order in which they were defined. For example:

:map! ab short :map! abc long

would always translate the characters "ab" to "short", regardless of how fast the characters "abc" were entered. If the entry order was reversed:

:map! abc long :map! ab short

the characters "ab" would cause the editor to pause, waiting for the completing 'c' character, and the characters might never be mapped to "short". For consistency and simplicity of specification, POSIX.1‐2008 requires that the shortest match be used at all times.

The length of time the editor spends waiting for the characters to complete the lhs is unspecified because the timing capabilities of systems are often inexact and variable, and it may depend on other factors such as the speed of the connection. The time should be long enough for the user to be able to complete the sequence, but not long enough for the user to have to wait. Some implementations of vi have added a keytime option, which permits users to set the number of 0,1 seconds the editor waits for the completing characters. Because mapped terminal function and cursor keys tend to start with an <ESC> character, and <ESC> is the key ending vi text input mode, maps starting with <ESC> characters are generally exempted from this timeout period, or, at least timed out differently.

Mark Historically, users were able to set the ``previous context'' marks explicitly. In addition, the ex commands '' and '` and the vi commands '', ``, `', and '` all referred to the same mark. In addition, the previous context marks were not set if the command, with which the address setting the mark was associated, failed. POSIX.1‐2008 requires conformance to historical practice. Historically, if marked lines were deleted, the mark was also deleted, but would reappear if the change was undone. POSIX.1‐2008 requires conformance to historical practice.

The description of the special events that set the ` and ' marks matches historical practice. For example, historically the command /a/,/b/ did not set the ` and ' marks, but the command /a/,/b/delete did.

Next Historically, any ex command could be entered as a +command argument to the next command, although some (for example, insert and append) were known to confuse historical implementations. POSIX.1‐2008 requires that any command be permitted and that it behave as specified. The next command can accept more than one file, so usage such as:

next `ls [abc] `

is valid; it need not be valid for the edit or read commands, for example, because they expect only one filename.

Historically, the next command behaved differently from the :rewind command in that it ignored the force flag if the autowrite flag was set. For consistency, POSIX.1‐2008 does not permit this behavior.

Historically, the next command positioned the cursor as if the file had never been edited before, regardless. POSIX.1‐2008 does not permit this behavior, for consistency with the edit command.

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.