ex man page on RedHat

Man page or keyword search:  
man Server   29550 pages
apropos Keyword Search (all sections)
Output format
RedHat logo
[printable version]

EX(1P)			   POSIX Programmer's Manual			EX(1P)

PROLOG
       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
       implementation of this interface may differ (consult the	 corresponding
       Linux  manual page for details of Linux behavior), or the interface may
       not be implemented on Linux.

NAME
       ex - text editor

SYNOPSIS
       ex [-rR][-s | -v][-c command][-t tagstring][-w size][file ...]

DESCRIPTION
       The ex utility is a line-oriented text  editor.	There  are  two	 other
       modes of the editor-open and visual-in which screen-oriented editing is
       available. This is described more fully by the ex open and visual  com‐
       mands and in vi .

       This  section uses the term edit buffer to describe the current working
       text. No specific implementation is implied by this term.  All  editing
       changes	are  performed	on the edit buffer, and no changes to it shall
       affect any file until an editor command writes the file.

       Certain terminals do not have all the capabilities necessary to support
       the  complete ex definition, such as the full-screen editing commands (
       visual mode or open mode).  When these commands cannot be supported  on
       such  terminals, this condition shall not produce an error message such
       as "not an editor command" or report a syntax error. The implementation
       may  either  accept the commands and produce results on the screen that
       are the result of an unsuccessful attempt to meet the  requirements  of
       this  volume  of IEEE Std 1003.1-2001 or report an error describing the
       terminal-related deficiency.

OPTIONS
       The ex  utility	shall  conform	to  the	 Base  Definitions  volume  of
       IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.

       The following options shall be supported:

       -c  command
	      Specify an initial command to be executed in the first edit buf‐
	      fer loaded from an existing file (see the	 EXTENDED  DESCRIPTION
	      section).	 Implementations  may  support	more  than a single -c
	      option. In such implementations, the specified commands shall be
	      executed in the order specified on the command line.

       -r     Recover  the named files (see the EXTENDED DESCRIPTION section).
	      Recovery information for a file shall be saved during an	editor
	      or system crash (for example, when the editor is terminated by a
	      signal which the editor can catch), or after the use  of	an  ex
	      preserve command.

       A crash in this context is an unexpected failure of the system or util‐
       ity that requires restarting the failed system  or  utility.  A	system
       crash implies that any utilities running at the time also crash. In the
       case of an editor or system crash, the number of changes	 to  the  edit
       buffer  (since the most recent preserve command) that will be recovered
       is unspecified.

       If no file operands are given and the -t option is not  specified,  all
       other  options,	the  EXINIT  variable,	and  any  .exrc files shall be
       ignored; a list of all recoverable files available to the invoking user
       shall  be  written,  and the editor shall exit normally without further
       action.

       -R     Set readonly edit option.

       -s     Prepare ex for batch use by taking the following actions:

	       * Suppress writing prompts and informational (but not  diagnos‐
		 tic) messages.

	       * Ignore	 the value of TERM and any implementation default ter‐
		 minal type and assume the terminal is	a  type	 incapable  of
		 supporting  open  or visual modes; see the visual command and
		 the description of vi .

	       * Suppress the use of the EXINIT environment variable  and  the
		 reading  of any .exrc file; see the EXTENDED DESCRIPTION sec‐
		 tion.

	       * Suppress autoindentation, ignoring the value of  the  autoin‐
		 dent edit option.

       -t  tagstring
	      Edit  the	 file  containing the specified tagstring; see ctags .
	      The tags feature represented by -t tagstring and the tag command
	      is  optional.  It shall be provided on any system that also pro‐
	      vides a conforming implementation of ctags; otherwise,  the  use
	      of  -t produces undefined results. On any system, it shall be an
	      error to specify more than a single -t option.

       -v     Begin in visual mode (see vi ).

       -w  size
	      Set the value of the window editor option to size.

OPERANDS
       The following operand shall be supported:

       file   A pathname of a file to be edited.

STDIN
       The standard input consists of a series of commands and input text,  as
       described  in  the EXTENDED DESCRIPTION section. The implementation may
       limit each line of standard input to a length of {LINE_MAX}.

       If the standard input is not a terminal device, it shall be as  if  the
       -s option had been specified.

       If  a  read  from the standard input returns an error, or if the editor
       detects an end-of-file condition from the standard input, it  shall  be
       equivalent to a SIGHUP asynchronous event.

INPUT FILES
       Input  files  shall  be	text  files  or files that would be text files
       except for an incomplete last line that is not longer than {LINE_MAX}-1
       bytes  in length and contains no NUL characters. By default, any incom‐
       plete last line shall be treated as if it had a trailing <newline>. The
       editing	of other forms of files may optionally be allowed by ex imple‐
       mentations.

       The .exrc files and source files shall be text files consisting	of  ex
       commands; see the EXTENDED DESCRIPTION section.

       By  default,  the  editor  shall read lines from the files to be edited
       without interpreting any of those lines as any form of editor command.

ENVIRONMENT VARIABLES
       The following environment variables shall affect the execution of ex:

       COLUMNS
	      Override the system-selected horizontal  screen  size.  See  the
	      Base  Definitions	 volume	 of  IEEE Std 1003.1-2001,  Chapter 8,
	      Environment Variables for valid values and results  when	it  is
	      unset or null.

       EXINIT Determine	 a  list  of  ex  commands that are executed on editor
	      start-up. See the EXTENDED DESCRIPTION section for more  details
	      of the initialization phase.

       HOME   Determine	 a  pathname of a directory that shall be searched for
	      an editor start-up file named .exrc; see the  EXTENDED  DESCRIP‐
	      TION section.

       LANG   Provide  a  default value for the internationalization variables
	      that are unset or null. (See  the	 Base  Definitions  volume  of
	      IEEE Std 1003.1-2001,  Section  8.2,  Internationalization Vari‐
	      ables for the precedence of internationalization variables  used
	      to determine the values of locale categories.)

       LC_ALL If  set  to a non-empty string value, override the values of all
	      the other internationalization variables.

       LC_COLLATE

	      Determine the locale for the  behavior  of  ranges,  equivalence
	      classes,	and  multi-character collating elements within regular
	      expressions.

       LC_CTYPE
	      Determine the locale for	the  interpretation  of	 sequences  of
	      bytes  of	 text  data as characters (for example, single-byte as
	      opposed to multi-byte characters in arguments and input  files),
	      the  behavior  of	 character classes within regular expressions,
	      the classification of characters as uppercase or lowercase  let‐
	      ters,  the case conversion of letters, and the detection of word
	      boundaries.

       LC_MESSAGES
	      Determine the locale that should be used to  affect  the	format
	      and contents of diagnostic messages written to standard error.

       LINES  Override	the  system-selected vertical screen size, used as the
	      number of lines in a screenful and the vertical screen  size  in
	      visual	mode.	 See	the   Base   Definitions   volume   of
	      IEEE Std 1003.1-2001, Chapter 8, Environment Variables for valid
	      values and results when it is unset or null.

       NLSPATH
	      Determine the location of message catalogs for the processing of
	      LC_MESSAGES .

       PATH   Determine the search path for the shell command specified in the
	      ex  editor  commands !, shell, read, and write, and the open and
	      visual mode command !; see the description of command search and
	      execution in Command Search and Execution .

       SHELL  Determine	 the preferred command line interpreter for use as the
	      default value of the shell edit option.

       TERM   Determine the name of the terminal type.	If  this  variable  is
	      unset  or	 null,	an  unspecified default terminal type shall be
	      used.

ASYNCHRONOUS EVENTS
       The following term is used in this and following	 sections  to  specify
       command and asynchronous event actions:

       complete write

	      A	 complete  write is a write of the entire contents of the edit
	      buffer to a file of a type other than a terminal device, or  the
	      saving  of  the  edit buffer caused by the user executing the ex
	      preserve command. Writing the contents of the edit buffer	 to  a
	      temporary	 file that will be removed when the editor exits shall
	      not be considered a complete write.

       The following actions shall be taken upon receipt of signals:

       SIGINT If the standard input is not a terminal  device,	ex  shall  not
	      write  the  file	or  return  to command or text input mode, and
	      shall exit with a non-zero exit status.

       Otherwise, if executing an open or visual text input mode  command,  ex
       in  receipt  of	SIGINT	shall behave identically to its receipt of the
       <ESC> character.

       Otherwise:

	       1. If executing an ex text input mode command, all input	 lines
		  that have been completely entered shall be resolved into the
		  edit buffer, and any partially entered line  shall  be  dis‐
		  carded.

	       2. If  there  is	 a  currently  executing  command, it shall be
		  aborted and a message displayed. Unless otherwise  specified
		  by  the  ex  or  vi  command descriptions, it is unspecified
		  whether any lines modified by the executing  command	appear
		  modified,  or as they were before being modified by the exe‐
		  cuting command, in the buffer.

	      If the currently executing command was  a	 motion	 command,  its
	      associated command shall be discarded.

	       3. If  in  open	or  visual command mode, the terminal shall be
		  alerted.

	       4. The editor shall then return to command mode.

       SIGCONT
	      The screen shall be refreshed if in open or visual mode.

       SIGHUP If the edit buffer has been modified  since  the	last  complete
	      write,  ex  shall attempt to save the edit buffer so that it can
	      be recovered later using the -r option or the  ex	 recover  com‐
	      mand.  The  editor shall not write the file or return to command
	      or text input mode, and shall terminate  with  a	non-zero  exit
	      status.

       SIGTERM
	      Refer to SIGHUP.

       The action taken for all other signals is unspecified.

STDOUT
       The standard output shall be used only for writing prompts to the user,
       for informational messages, and for writing lines from the file.

STDERR
       The standard error shall be used only for diagnostic messages.

OUTPUT FILES
       The output from ex shall be text files.

EXTENDED DESCRIPTION
       Only the ex mode of the editor is described in this  section.   See  vi
       for additional editing capabilities available in ex.

       When  an	 error	occurs, ex shall write a message. If the terminal sup‐
       ports a standout mode (such as inverse video),  the  message  shall  be
       written	in  standout mode. If the terminal does not support a standout
       mode, and the edit option errorbells is set, an alert action shall pre‐
       cede the error message.

       By default, ex shall start in command mode, which shall be indicated by
       a : prompt; see the prompt command.  Text input mode can be entered  by
       the  append,  insert, or change commands; it can be exited (and command
       mode re-entered) by typing a period ( '.' ) alone at the beginning of a
       line.

   Initialization in ex and vi
       The  following symbols are used in this and following sections to spec‐
       ify locations in the edit buffer:

       alternate and current pathnames

	      Two pathnames, named current and alternate,  are	maintained  by
	      the  editor.  Any	 ex  commands that take filenames as arguments
	      shall set them as follows:

	       1. If a file argument is specified  to  the  ex	edit,  ex,  or
		  recover  commands, or if an ex tag command replaces the con‐
		  tents of the edit buffer.

		   a. If the command replaces the contents of the edit buffer,
		      the  current  pathname shall be set to the file argument
		      or the file indicated by	the  tag,  and	the  alternate
		      pathname	shall be set to the previous value of the cur‐
		      rent pathname.

		   b. Otherwise, the alternate pathname shall be  set  to  the
		      file argument.

	       2. If a file argument is specified to the ex next command:

		   a. If the command replaces the contents of the edit buffer,
		      the current pathname shall be  set  to  the  first  file
		      argument, and the alternate pathname shall be set to the
		      previous value of the current pathname.

	       3. If a file argument is specified to the ex file command,  the
		  current  pathname shall be set to the file argument, and the
		  alternate pathname shall be set to the previous value of the
		  current pathname.

	       4. If  a	 file  argument	 is specified to the ex read and write
		  commands (that is, when reading or writing a file,  and  not
		  to  the  program  named by the shell edit option), or a file
		  argument is specified to the ex xit command:

		   a. If the current pathname has no value, the current	 path‐
		      name shall be set to the file argument.

		   b. Otherwise,  the  alternate  pathname shall be set to the
		      file argument.

       If the alternate pathname is set to the previous value of  the  current
       pathname	 when  the  current  pathname  had no previous value, then the
       alternate pathname shall have no value as a result.

       current line

	      The line of the edit buffer referenced by the cursor. Each  com‐
	      mand  description	 specifies  the current line after the command
	      has been executed, as the current line value. When the edit buf‐
	      fer  contains  no	 lines,	 the  current  line shall be zero; see
	      Addressing in ex .

       current column

	      The current display line column occupied	by  the	 cursor.  (The
	      columns shall be numbered beginning at 1.) Each command descrip‐
	      tion specifies the current column after  the  command  has  been
	      executed,	 as  the current column value. This column is an ideal
	      column that is remembered over the lifetime of the editor.   The
	      actual  display  line  column upon which the cursor rests may be
	      different from the current column; see  the  cursor  positioning
	      discussion in Command Descriptions in vi .

       set to non-<blank>

	      A	 description for a current column value, meaning that the cur‐
	      rent column shall be set to the  last  display  line  column  on
	      which  is	 displayed  any	 part of the first non- <blank> of the
	      line. If the line has no non- <blank> non- <newline>s, the  cur‐
	      rent  column  shall  be  set  to the last display line column on
	      which is displayed any part of the last non-  <newline>  in  the
	      line.  If	 the line is empty, the current column shall be set to
	      column position 1.

       The length of lines in the edit buffer may  be  limited	to  {LINE_MAX}
       bytes.  In open and visual mode, the length of lines in the edit buffer
       may be limited to the number of characters that will fit	 in  the  dis‐
       play.  If  either  limit	 is  exceeded during editing, an error message
       shall be written. If either limit is exceeded by a line read in from  a
       file,  an  error	 message  shall be written and the edit session may be
       terminated.

       If the editor stops running due to any reason other than	 a  user  com‐
       mand,  and  the	edit  buffer has been modified since the last complete
       write, it shall be equivalent to a SIGHUP asynchronous event.   If  the
       system crashes, it shall be equivalent to a SIGHUP asynchronous event.

       During  initialization  (before	the first file is copied into the edit
       buffer or any user commands from the terminal are processed)  the  fol‐
       lowing shall occur:

	1. If the environment variable EXINIT is set, the editor shall execute
	   the ex commands contained in that variable.

	2. If the EXINIT variable is not set, and all  of  the	following  are
	   true:

	    a. The HOME environment variable is not null and not empty.

	    b. The  file  .exrc in the directory referred to by the HOME envi‐
	       ronment variable:

		1. Exists

		2. Is owned by the same user ID as the real  user  ID  of  the
		   process or the process has appropriate privileges

		3. Is not writable by anyone other than the owner

       the editor shall execute the ex commands contained in that file.

	3. If and only if all of the following are true:

	    a. The  current  directory is not referred to by the HOME environ‐
	       ment variable.

	    b. A command in the EXINIT environment variable or	a  command  in
	       the  .exrc  file in the directory referred to by the HOME envi‐
	       ronment variable sets the editor option exrc.

	    c. The .exrc file in the current directory:

		1. Exists

		2. Is owned by the same user ID as the real  user  ID  of  the
		   process,  or by one of a set of implementation-defined user
		   IDs

		3. Is not writable by anyone other than the owner

       the editor shall attempt to execute the ex commands contained  in  that
       file.

       Lines  in any .exrc file that are blank lines shall be ignored.	If any
       .exrc file exists, but is not read for ownership or permission reasons,
       it shall be an error.

       After  the EXINIT variable and any .exrc files are processed, the first
       file specified by the user shall be edited, as follows:

	1. If the user specified the -t option, the effect shall be as if  the
	   ex  tag  command  was entered with the specified argument, with the
	   exception that if tag processing does not result in a file to edit,
	   the effect shall be as described in step 3. below.

	2. Otherwise,  if  the user specified any command line file arguments,
	   the effect shall be as if the ex edit command was entered with  the
	   first of those arguments as its file argument.

	3. Otherwise,  the  effect  shall  be  as  if  the ex edit command was
	   entered with a nonexistent filename as its  file  argument.	It  is
	   unspecified	whether this action shall set the current pathname. In
	   an implementation where this action does not set the current	 path‐
	   name,  any  editor  command	using  the current pathname shall fail
	   until an editor command sets the current pathname.

       If the -r option was specified, the first time a file  in  the  initial
       argument list or a file specified by the -t option is edited, if recov‐
       ery information has previously been saved about	it,  that  information
       shall  be  recovered  and the editor shall behave as if the contents of
       the edit buffer have already  been  modified.  If  there	 are  multiple
       instances  of  the  file	 to  be recovered, the one most recently saved
       shall be recovered, and an informational message that there are	previ‐
       ous  versions of the file that can be recovered shall be written. If no
       recovery information about a file is available, an  informational  mes‐
       sage  to	 this  effect  shall be written, and the edit shall proceed as
       usual.

       If the -c option was specified, the first  time	a  file	 that  already
       exists  (including  a  file that might not exist but for which recovery
       information is available, when the -r option is specified) replaces  or
       initializes  the contents of the edit buffer, the current line shall be
       set to the last line of the edit buffer, the current  column  shall  be
       set  to	non- <blank>, and the ex commands specified with the -c option
       shall be executed. In this case, the current line  and  current	column
       shall  not  be  set  as	described  for the command associated with the
       replacement or initialization of the edit buffer contents.  However, if
       the  -t	option or a tag command is associated with this action, the -c
       option commands shall be executed and then  the	movement  to  the  tag
       shall be performed.

       The current argument list shall initially be set to the filenames spec‐
       ified by the user on the command line. If no filenames are specified by
       the  user,  the	current argument list shall be empty. If the -t option
       was specified, it is unspecified whether any  filename  resulting  from
       tag  processing shall be prepended to the current argument list. In the
       case where the filename is added as a prefix to	the  current  argument
       list,  the  current  argument list reference shall be set to that file‐
       name. In the case where the filename is not added as a  prefix  to  the
       current	argument list, the current argument list reference shall logi‐
       cally be located before the first of the	 filenames  specified  on  the
       command	line (for example, a subsequent ex next command shall edit the
       first filename from the command line). If the -t option was not	speci‐
       fied,  the current argument list reference shall be to the first of the
       filenames on the command line.

   Addressing in ex
       Addressing in ex relates to the current line and	 the  current  column;
       the address of a line is its 1-based line number, the address of a col‐
       umn is its 1-based count from the beginning of the line. Generally, the
       current	line  is the last line affected by a command. The current line
       number is the address of the current line. In each command description,
       the  effect  of	the command on the current line number and the current
       column is described.

       Addresses are constructed as follows:

	1. The character '.' (period) shall address the current line.

	2. The character '$' shall address the last line of the edit buffer.

	3. The positive decimal number n shall address the  nth	 line  of  the
	   edit buffer.

	4. The address "'x" refers to the line marked with the mark name char‐
	   acter 'x', which shall be a	lowercase  letter  from	 the  portable
	   character  set  or one of the characters '`' or '" . It shall be an
	   error if the line that was marked is not currently present  in  the
	   edit	 buffer or the mark has not been set. Lines can be marked with
	   the ex mark or k commands, or the vi m command.

	5. A regular expression enclosed by slashes ( '/' ) shall address  the
	   first  line found by searching forwards from the line following the
	   current line toward the end of the edit buffer and stopping at  the
	   first  line	for which the line excluding the terminating <newline>
	   matches the regular expression. As stated in Regular Expressions in
	   ex, an address consisting of a null regular expression delimited by
	   slashes "//" shall address the next line for which the line exclud‐
	   ing	the  terminating <newline> matches the last regular expression
	   encountered. In addition, the second slash can be  omitted  at  the
	   end	of  a  command	line.  If the wrapscan edit option is set, the
	   search shall wrap around to the beginning of the  edit  buffer  and
	   continue  up	 to and including the current line, so that the entire
	   edit	 buffer	 is  searched.	Within	the  regular  expression,  the
	   sequence  "\/" shall represent a literal slash instead of the regu‐
	   lar expression delimiter.

	6. A regular expression enclosed in  question  marks  (	 '?'  )	 shall
	   address  the	 first line found by searching backwards from the line
	   preceding the current line toward the beginning of the edit	buffer
	   and	stopping  at  the  first line for which the line excluding the
	   terminating <newline> matches the regular expression.   An  address
	   consisting of a null regular expression delimited by question marks
	   "??" shall address the previous line for which the  line  excluding
	   the	terminating  <newline>	matches	 the  last  regular expression
	   encountered. In addition, the second question mark can  be  omitted
	   at  the  end of a command line. If the wrapscan edit option is set,
	   the search shall wrap around from the beginning of the edit	buffer
	   to  the end of the edit buffer and continue up to and including the
	   current line, so that the entire edit buffer	 is  searched.	Within
	   the regular expression, the sequence "\?" shall represent a literal
	   question mark instead of the RE delimiter.

	7. A plus sign ( '+' ) or a minus sign ( '-' ) followed by  a  decimal
	   number  shall  address the current line plus or minus the number. A
	   '+' or '-' not followed by a decimal number shall address the  cur‐
	   rent line plus or minus 1.

       Addresses  can  be followed by zero or more address offsets, optionally
       <blank>-separated. Address offsets are constructed as follows:

	1. A '+' or '-' immediately followed by a  decimal  number  shall  add
	   (subtract)  the  indicated number of lines to (from) the address. A
	   '+' or '-' not followed by a decimal number shall add (subtract)  1
	   to (from) the address.

	2. A  decimal  number  shall  add the indicated number of lines to the
	   address.

       It shall not be an error for an intermediate address value to  be  less
       than zero or greater than the last line in the edit buffer. It shall be
       an error for the final address value to be less than  zero  or  greater
       than the last line in the edit buffer.

       Commands	 take  zero,  one,  or	two addresses; see the descriptions of
       1addr and 2addr in Command Descriptions	in  ex	.  If  more  than  the
       required	 number	 of  addresses are provided to a command that requires
       zero addresses, it shall be an  error.  Otherwise,  if  more  than  the
       required	 number	 of addresses are provided to a command, the addresses
       specified first shall be evaluated and then discarded until the maximum
       number of valid addresses remain.

       Addresses  shall	 be  separated from each other by a comma ( ',' ) or a
       semicolon ( ';' ). If no address is specified before or after  a	 comma
       or  semicolon  separator,  it shall be as if the address of the current
       line was specified before or after the separator.  In  the  case	 of  a
       semicolon separator, the current line ( '.' ) shall be set to the first
       address, and only then will the next address be calculated.  This  fea‐
       ture  can be used to determine the starting line for forwards and back‐
       wards searches (see rules 5. and 6.).

       A percent sign (	 '%'  )	 shall	be  equivalent	to  entering  the  two
       addresses "1,$" .

       Any  delimiting	<blank>s  between  addresses,  address	separators, or
       address offsets shall be discarded.

   Command Line Parsing in ex
       The following symbol is used in this and following sections to describe
       parsing behavior:

       escape If  a character is referred to as "backslash-escaped" or " <con‐
	      trol>-V-escaped," it shall mean that the character  acquired  or
	      lost  a  special	meaning	 by  virtue of being preceded, respec‐
	      tively, by a backslash or <control>-V character.	Unless	other‐
	      wise  specified,	the  escaping  character shall be discarded at
	      that time and shall not be further considered for any purpose.

       Command-line parsing shall be done in the  following  steps.  For  each
       step,  characters  already  evaluated  shall  be	 ignored; that is, the
       phrase "leading character" refers to the next character	that  has  not
       yet been evaluated.

	1. Leading colon characters shall be skipped.

	2. Leading <blank>s shall be skipped.

	3. If  the  leading character is a double-quote character, the charac‐
	   ters up to and including the next  non-backslash-escaped  <newline>
	   shall  be  discarded, and any subsequent characters shall be parsed
	   as a separate command.

	4. Leading characters that can be interpreted as  addresses  shall  be
	   evaluated; see Addressing in ex .

	5. Leading <blank>s shall be skipped.

	6. If the next character is a vertical-line character or a <newline>:

	    a. If the next character is a <newline>:

		1. If  ex is in open or visual mode, the current line shall be
		   set to the last address specified, if any.

		2. Otherwise, if the last command was terminated by  a	verti‐
		   cal-line  character, no action shall be taken; for example,
		   the command "||<newline>" shall execute  two	 implied  com‐
		   mands, not three.

		3. Otherwise, step 6.b. shall apply.

	    b. Otherwise,  the implied command shall be the print command. The
	       last #, p, and l flags specified to any	ex  command  shall  be
	       remembered  and	shall apply to this implied command. Executing
	       the ex number, print, or list command shall set the  remembered
	       flags  to #, nothing, and l, respectively, plus any other flags
	       specified for that execution of the number, print, or list com‐
	       mand.

	   If  ex  is  not  currently performing a global or v command, and no
	   address or count is specified, the current  line  shall  be	incre‐
	   mented  by  1  before  the command is executed. If incrementing the
	   current line would result in an address past the last line  in  the
	   edit	 buffer,  the  command shall fail, and the increment shall not
	   happen.

	    c. The <newline> or vertical-line character shall be discarded and
	       any  subsequent	characters  shall be parsed as a separate com‐
	       mand.

	7. The command name shall be comprised of the next character  (if  the
	   character  is not alphabetic), or the next character and any subse‐
	   quent alphabetic characters (if the character is alphabetic),  with
	   the following exceptions:

	    a. Commands	 that  consist	of any prefix of the characters in the
	       command name delete, followed immediately by any of the charac‐
	       ters  'l',  'p',	 '+',  '-',  or	 '#' shall be interpreted as a
	       delete command, followed by a <blank>, followed by the  charac‐
	       ters  that  were	 not part of the prefix of the delete command.
	       The maximum number of characters shall be matched to  the  com‐
	       mand  name  delete;  for example, "del" shall not be treated as
	       "de" followed by the flag l.

	    b. Commands that consist of the character 'k', followed by a char‐
	       acter  that can be used as the name of a mark, shall be equiva‐
	       lent to the mark command followed by a <blank>, followed by the
	       character that followed the 'k' .

	    c. Commands that consist of the character 's', followed by charac‐
	       ters that could be interpreted as valid options to the  s  com‐
	       mand,  shall  be	 the  equivalent of the s command, without any
	       pattern or replacement values, followed by a <blank>,  followed
	       by the characters after the 's' .

	8. The	command	 name  shall  be  matched against the possible command
	   names, and a command name that contains a prefix matching the char‐
	   acters  specified by the user shall be the executed command. In the
	   case of commands where the characters specified by the  user	 could
	   be ambiguous, the executed command shall be as follows:

		      a	   append   n	 next	 t    t
		      c	   change   p	 print	 u    undo
		      ch   change   pr	 print	 un   undo
		      e	   edit	    r	 read	 v    v
		      m	   move	    re	 read	 w    write
		      ma   mark	    s	 s

       Implementation  extensions with names causing similar ambiguities shall
       not be checked for a match until	 all  possible	matches	 for  commands
       specified by IEEE Std 1003.1-2001 have been checked.

	9. If  the command is a ! command, or if the command is a read command
	   followed by zero or more <blank>s and a !, or if the command	 is  a
	   write command followed by one or more <blank>s and a !, the rest of
	   the command shall include all characters  up	 to  a	non-backslash-
	   escaped  <newline>. The <newline> shall be discarded and any subse‐
	   quent characters shall be parsed as a separate ex command.

       10. Otherwise, if the command is an edit, ex, or	 next  command,	 or  a
	   visual  command  while in open or visual mode, the next part of the
	   command shall be parsed as follows:

	    a. Any '!' character immediately following the  command  shall  be
	       skipped and be part of the command.

	    b. Any  leading  <blank>s shall be skipped and be part of the com‐
	       mand.

	    c. If the next character is a '+', characters up to the first non-
	       backslash-escaped  <newline>  or	 non-backslash-escaped <blank>
	       shall be skipped and be part of the command.

	    d. The rest of the command shall be determined by the steps speci‐
	       fied in paragraph 12.

       11. Otherwise,  if  the command is a global, open, s, or v command, the
	   next part of the command shall be parsed as follows:

	    a. Any leading <blank>s shall be skipped and be part of  the  com‐
	       mand.

	    b. If  the	next  character	 is not an alphanumeric, double-quote,
	       <newline>, backslash, or vertical-line character:

		1. The next character shall be used as a command delimiter.

		2. If the command is a global, open, or v command,  characters
		   up  to  the first non-backslash-escaped <newline>, or first
		   non-backslash-escaped delimiter character, shall be skipped
		   and be part of the command.

		3. If  the command is an s command, characters up to the first
		   non-backslash-escaped <newline>, or	second	non-backslash-
		   escaped  delimiter  character, shall be skipped and be part
		   of the command.

	    c. If the command is a global or v command, characters up  to  the
	       first  non-backslash-escaped  <newline> shall be skipped and be
	       part of the command.

	    d. Otherwise, the rest of the command shall be determined  by  the
	       steps specified in paragraph 12.

       12. Otherwise:

	    a. If  the	command	 was a map, unmap, abbreviate, or unabbreviate
	       command, characters up to the  first  non-  <control>-V-escaped
	       <newline>,  vertical-line,  or  double-quote character shall be
	       skipped and be part of the command.

	    b. Otherwise, characters up	 to  the  first	 non-backslash-escaped
	       <newline>,  vertical-line,  or  double-quote character shall be
	       skipped and be part of the command.

	    c. If the command was an append, change, or	 insert	 command,  and
	       the  step  12.b. ended at a vertical-line character, any subse‐
	       quent characters, up to the  next  non-backslash-escaped	 <new‐
	       line> shall be used as input text to the command.

	    d. If  the command was ended by a double-quote character, all sub‐
	       sequent characters, up to the next non-backslash-escaped	 <new‐
	       line>, shall be discarded.

	    e. The  terminating	 <newline> or vertical-line character shall be
	       discarded and any subsequent characters shall be	 parsed	 as  a
	       separate ex command.

       Command	arguments  shall  be  parsed  as described by the Synopsis and
       Description of each individual ex command. This parsing	shall  not  be
       <blank>-sensitive,  except  for	the  ! argument, which must follow the
       command name without intervening <blank>s, and where it would otherwise
       be  ambiguous.  For  example,  count  and  flag	arguments  need not be
       <blank>-separated because "d22p" is not ambiguous, but  file  arguments
       to  the	ex next command must be separated by one or more <blank>s. Any
       <blank> in command arguments for the abbreviate, unabbreviate, map, and
       unmap  commands	can  be <control>-V-escaped, in which case the <blank>
       shall not be used as an argument delimiter. Any <blank> in the  command
       argument	 for any other command can be backslash-escaped, in which case
       that <blank> shall not be used as an argument delimiter.

       Within command arguments for the	 abbreviate,  unabbreviate,  map,  and
       unmap  commands,	 any  character	 can  be <control>-V-escaped. All such
       escaped characters shall be treated literally and shall have no special
       meaning.	 Within	 command  arguments for all other ex commands that are
       not regular expressions or  replacement	strings,  any  character  that
       would  otherwise	 have  a  special  meaning  can	 be backslash-escaped.
       Escaped characters shall be treated literally, without special  meaning
       as  shell  expansion  characters or '!', '%', and '#' expansion charac‐
       ters. See Regular Expressions in ex and Replacement Strings in  ex  for
       descriptions  of	 command  arguments  that  are	regular expressions or
       replacement strings.

       Non-backslash-escaped '%' characters appearing in file arguments to any
       ex  command  shall  be  replaced by the current pathname; unescaped '#'
       characters shall be replaced by the alternate pathname. It shall be  an
       error  if  '%'  or  '#'	characters appear unescaped in an argument and
       their corresponding values are not set.

       Non-backslash-escaped '!' characters in the arguments to either the  ex
       ! command or the open and visual mode ! command, or in the arguments to
       the ex read command, where the first non-  <blank>  after  the  command
       name  is	 a  '!' character, or in the arguments to the ex write command
       where the command name is followed by one  or  more  <blank>s  and  the
       first  non- <blank> after the command name is a '!' character, shall be
       replaced with the arguments to the last of those three commands as they
       appeared	 after	all  unescaped	'%',  '#',  and	 '!'  characters  were
       replaced. It shall be an error if '!' characters	 appear	 unescaped  in
       one  of	these commands and there has been no previous execution of one
       of these commands.

       If an error occurs during the parsing or execution of an ex command:

	* An informational message to this effect shall be written.  Execution
	  of  the ex command shall stop, and the cursor (for example, the cur‐
	  rent line and column) shall not be further modified.

	* If the ex command resulted from a map expansion, all characters from
	  that map expansion shall be discarded, except as otherwise specified
	  by the map command.

	* Otherwise, if the ex command resulted	 from  the  processing	of  an
	  EXINIT  environment  variable, a .exrc file, a :source command, a -c
	  option, or a + command specified to an ex edit, ex, next, or	visual
	  command,  no	further commands from the source of the commands shall
	  be executed.

	* Otherwise, if the ex command resulted from the execution of a buffer
	  or  a	 global or v command, no further commands caused by the execu‐
	  tion of the buffer or the global or v command shall be executed.

	* Otherwise, if the ex command was not terminated by a <newline>,  all
	  characters  up to and including the next non-backslash-escaped <new‐
	  line> shall be discarded.

   Input Editing in ex
       The following symbol is used in this  and  the  following  sections  to
       specify command actions:

       word   In  the  POSIX  locale, a word consists of a maximal sequence of
	      letters, digits, and underscores,	 delimited  at	both  ends  by
	      characters other than letters, digits, or underscores, or by the
	      beginning or end of a line or the edit buffer.

       When accepting input characters from the user,  in  either  ex  command
       mode  or	 ex text input mode, ex shall enable canonical mode input pro‐
       cessing,	  as   defined	 in   the   System   Interfaces	  volume    of
       IEEE Std 1003.1-2001.

       If in ex text input mode:

	1. If  the  number edit option is set, ex shall prompt for input using
	   the line number that would  be  assigned  to	 the  line  if	it  is
	   entered, in the format specified for the ex number command.

	2. If  the  autoindent	edit  option is set, ex shall prompt for input
	   using autoindent characters, as described by	 the  autoindent  edit
	   option. autoindent characters shall follow the line number, if any.

       If in ex command mode:

	1. If the prompt edit option is set, input shall be prompted for using
	   a single ':' character; otherwise, there shall be no prompt.

       The input characters in the following sections shall have the following
       effects on the input line.

   Scroll
       Synopsis:

	      eof

       See the description of the stty eof character in stty .

       If  in  ex  command  mode:  If the eof character is the first character
       entered on the line, the line shall be evaluated as if it contained two
       characters: a <control>-D and a <newline>.

       Otherwise, the eof character shall have no special meaning.

       If  in  ex text input mode: If the cursor follows an autoindent charac‐
       ter, the autoindent characters in the line shall be modified so that  a
       part  of	 the  next text input character will be displayed on the first
       column in the line after the previous  shiftwidth  edit	option	column
       boundary,  and  the user shall be prompted again for input for the same
       line.

       Otherwise, if the cursor follows a '0',	which  follows	an  autoindent
       character,  and	the '0' was the previous text input character, the '0'
       and all autoindent characters in the line shall be discarded,  and  the
       user shall be prompted again for input for the same line.

       Otherwise,  if  the  cursor  follows a '^', which follows an autoindent
       character, and the '^' was the previous text input character,  the  '^'
       and  all	 autoindent characters in the line shall be discarded, and the
       user shall be prompted again for input for the same line. In  addition,
       the  autoindent level for the next input line shall be derived from the
       same line from which the autoindent level for the  current  input  line
       was derived.

       Otherwise,  if  there are no autoindent or text input characters in the
       line, the eof character shall be discarded.

       Otherwise, the eof character shall have no special meaning.

   <newline>
       Synopsis:

	      <newline>

	      <control>-J

       If in ex command mode: Cause the command line to be parsed; <control>-J
       shall be mapped to the <newline> for this purpose.

       If  in  ex text input mode: Terminate the current line. If there are no
       characters other than autoindent characters on the line, all characters
       on the line shall be discarded.

       Prompt  for  text  input	 on  a new line after the current line. If the
       autoindent edit option is set,  an  appropriate	number	of  autoindent
       characters  shall  be added as a prefix to the line as described by the
       ex autoindent edit option.

   <backslash>
       Synopsis:

	      <backslash>

       Allow the entry of a subsequent <newline> or <control>-J as  a  literal
       character,  removing any special meaning that it may have to the editor
       during text input mode. The backslash character shall be	 retained  and
       evaluated  when	the  command  line is parsed, or retained and included
       when the input text becomes part of the edit buffer.

   <control>-V
       Synopsis:

	      <control>-V

       Allow the entry of any subsequent character  as	a  literal  character,
       removing any special meaning that it may have to the editor during text
       input mode. The <control>-V character shall  be	discarded  before  the
       command	line is parsed or the input text becomes part of the edit buf‐
       fer.

       If the "literal next" functionality is performed by the underlying sys‐
       tem,  it is implementation-defined whether a character other than <con‐
       trol>-V performs this function.

   <control>-W
       Synopsis:

	      <control>-W

       Discard the <control>-W, and the word previous to it in the input line,
       including  any  <blank>s	 following  the	 word  and preceding the <con‐
       trol>-W. If the "word erase" functionality is performed by the underly‐
       ing system, it is implementation-defined whether a character other than
       <control>-W performs this function.

   Command Descriptions in ex
       The following symbols are used in this  section	to  represent  command
       modifiers.  Some	 of  these modifiers can be omitted, in which case the
       specified defaults shall be used.

       1addr  A single line address, given in any of the  forms	 described  in
	      Addressing  in  ex ; the default shall be the current line ( '.'
	      ), unless otherwise specified.

       If the line address is zero, it shall be	 an  error,  unless  otherwise
       specified in the following command descriptions.

       If  the	edit buffer is empty, and the address is specified with a com‐
       mand other than =, append, insert, open, put, read, or visual,  or  the
       address is not zero, it shall be an error.

       2addr  Two  addresses  specifying  an  inclusive	 range of lines. If no
	      addresses are specified, the default for 2addr shall be the cur‐
	      rent line only ( ".,." ), unless otherwise specified in the fol‐
	      lowing command descriptions. If one address is specified,	 2addr
	      shall  specify that line only, unless otherwise specified in the
	      following command descriptions.

       It shall be an error if the first address is greater  than  the	second
       address.

       If the edit buffer is empty, and the two addresses are specified with a
       command other than the !, write, wq, or xit commands, or either address
       is not zero, it shall be an error.

       count  A	 positive  decimal  number. If count is specified, it shall be
	      equivalent to specifying an additional address to	 the  command,
	      unless  otherwise	 specified  by	the following command descrip‐
	      tions.  The additional  address  shall  be  equal	 to  the  last
	      address  specified  to  the  command  (either  explicitly	 or by
	      default) plus count-1.

       If this would result in an address greater than the last	 line  of  the
       edit  buffer,  it shall be corrected to equal the last line of the edit
       buffer.

       flags  One or more of the characters '+', '-', '#', 'p', or 'l'	(ell).
	      The  flag	 characters can be <blank>-separated, and in any order
	      or combination.  The characters '#', 'p', and  'l'  shall	 cause
	      lines to be written in the format specified by the print command
	      with the specified flags.

       The lines to be written are as follows:

	       1. All edit buffer lines written during the execution of the ex
		  &,  ~,  list, number, open, print, s, visual, and z commands
		  shall be written as specified by flags.

	       2. After the completion of an ex command	 with  a  flag	as  an
		  argument,  the current line shall be written as specified by
		  flags, unless the current line was the last line written  by
		  the command.

       The  characters	'+'  and '-' cause the value of the current line after
       the execution of the ex command to be adjusted by the offset address as
       described  in Addressing in ex . This adjustment shall occur before the
       current line is written as described in 2. above.

       The default for flags shall be none.

       buffer One of a number of named areas for holding text. The named  buf‐
	      fers  are	 specified by the alphanumeric characters of the POSIX
	      locale. There shall also be one "unnamed" buffer. When no buffer
	      is  specified for editor commands that use a buffer, the unnamed
	      buffer shall be used. Commands  that  store  text	 into  buffers
	      shall  store  the text as it was before the command took effect,
	      and shall store text occurring earlier in the file  before  text
	      occurring	 later	in the file, regardless of how the text region
	      was specified. Commands that store text into buffers shall store
	      the  text	 into the unnamed buffer as well as any specified buf‐
	      fer.

       In ex commands, buffer names are specified as the name by  itself.   In
       open or visual mode commands the name is preceded by a double quote ( '
       )' character.

       If the specified buffer name is an uppercase character, and the	buffer
       contents	 are  to  be  modified, the buffer shall be appended to rather
       than being overwritten. If the buffer is not being modified, specifying
       the  buffer  name  in  lowercase	 and  uppercase	 shall	have identical
       results.

       There shall also be buffers named by the numbers 1 through 9.  In  open
       and  visual  mode,  if  a region of text including characters from more
       than a single line is being modified by the vi c	 or  d	commands,  the
       motion character associated with the c or d commands specifies that the
       buffer text shall be in line mode, or the commands %, `, /, ?, (, ), N,
       n, {, or } are used to define a region of text for the c or d commands,
       the contents of buffers 1 through 8 shall  be  moved  into  the	buffer
       named  by  the next numerically greater value, the contents of buffer 9
       shall be discarded, and the region of text shall be copied into	buffer
       1.  This shall be in addition to copying the text into a user-specified
       buffer or unnamed buffer, or both. Numeric buffers can be specified  as
       a  source buffer for open and visual mode commands; however, specifying
       a numeric buffer as the write target of an open or visual mode  command
       shall have unspecified results.

       The  text  of  each  buffer  shall  have the characteristic of being in
       either line or character mode. Appending text  to  a  non-empty	buffer
       shall  set  the	mode  to  match	 the  characteristic of the text being
       appended. Appending text to a buffer shall cause	 the  creation	of  at
       least  one  additional line in the buffer. All text stored into buffers
       by ex commands shall be in line mode.  The ex commands that use buffers
       as  the	source	of  text specify individually how buffers of different
       modes are handled. Each open or visual mode command that	 uses  buffers
       for any purpose specifies individually the mode of the text stored into
       the buffer and how buffers of different modes are handled.

       file   Command text used to derive a pathname. The default shall be the
	      current  pathname,  as  defined previously, in which case, if no
	      current pathname has yet been established it shall be an	error,
	      except  where  specifically  noted  in  the  individual  command
	      descriptions that follow. If the command text  contains  any  of
	      the  characters  '~', '{', '[', '*', '?', '$', '`', '", ' ,' and
	      '\', it shall be subjected to the process of "shell expansions",
	      as  described  below; if more than a single pathname results and
	      the command expects only one, it shall be an error.

       The process of shell expansions in the editor shall be done as follows.
       The  ex	utility	 shall	pass two arguments to the program named by the
       shell edit option; the first shall be -c, and the second shall  be  the
       string  "echo"  and the command text as a single argument. The standard
       output and standard error of that command  shall	 replace  the  command
       text.

       !      A	 character  that can be appended to the command name to modify
	      its operation, as detailed in the	 individual  command  descrip‐
	      tions. With the exception of the ex read, write, and ! commands,
	      the '!' character shall only act as a modifier if there  are  no
	      <blank>s between it and the command name.

       remembered search direction

	      The  vi  commands N and n begin searching in a forwards or back‐
	      wards direction in the edit buffer based on a remembered	search
	      direction,  which	 is  initially	unset,	and  is	 set by the ex
	      global, v, s, and tag commands, and the vi / and ? commands.

   Abbreviate
       Synopsis:

	      ab[breviate][lhs rhs]

       If lhs and rhs are not specified, write the current list	 of  abbrevia‐
       tions and do nothing more.

       Implementations	may  restrict the set of characters accepted in lhs or
       rh,  except  that  printable  characters	 and  <blank>s	shall  not  be
       restricted. Additional restrictions shall be implementation-defined.

       In  both	 lhs and rhs, any character may be escaped with a <control>-V,
       in which case the character shall not be used to delimit lhs from  rhs,
       and the escaping <control>-V shall be discarded.

       In  open	 and  visual text input mode, if a non-word or <ESC> character
       that is not escaped by a <control>-V character is entered after a  word
       character,  a check shall be made for a set of characters matching lhs,
       in the text input entered during this command.  If  it  is  found,  the
       effect shall be as if rhs was entered instead of lhs.

       The set of characters that are checked is defined as follows:

	1. If there are no characters inserted before the word and non-word or
	   <ESC> characters that triggered the check, the  set	of  characters
	   shall consist of the word character.

	2. If  the  character  inserted	 before the word and non-word or <ESC>
	   characters that triggered the check is a word character, the set of
	   characters  shall  consist  of  the characters inserted immediately
	   before the triggering characters that are word characters, plus the
	   triggering word character.

	3. If  the  character  inserted	 before the word and non-word or <ESC>
	   characters that triggered the check is not a	 word  character,  the
	   set	of  characters	shall  consist	of  the	 characters  that were
	   inserted before the triggering characters that are neither <blank>s
	   nor word characters, plus the triggering word character.

       It  is unspecified whether the lhs argument entered for the ex abbrevi‐
       ate and unabbreviate commands is replaced in this  fashion.  Regardless
       of  whether  or	not  the replacement occurs, the effect of the command
       shall be as if the replacement had not occurred.

       Current line: Unchanged.

       Current column: Unchanged.

   Append
       Synopsis:

	      [1addr] a[ppend][!]

       Enter ex text input mode; the input text	 shall	be  placed  after  the
       specified  line. If line zero is specified, the text shall be placed at
       the beginning of the edit buffer.

       This command shall be  affected	by  the	 number	 and  autoindent  edit
       options; following the command name with '!' shall cause the autoindent
       edit option setting to be toggled for  the  duration  of	 this  command
       only.

       Current	line:  Set to the last input line; if no lines were input, set
       to the specified line, or to the first line of the  edit	 buffer	 if  a
       line of zero was specified, or zero if the edit buffer is empty.

       Current column: Set to non- <blank>.

   Arguments
       Synopsis:

	      ar[gs]

       Write  the current argument list, with the current argument-list entry,
       if any, between '[' and ']' characters.

       Current line: Unchanged.

       Current column: Unchanged.

   Change
       Synopsis:

	      [2addr] c[hange][!][count]

       Enter ex text input mode; the input text shall  replace	the  specified
       lines.  The  specified  lines  shall be copied into the unnamed buffer,
       which shall become a line mode buffer.

       This command shall be  affected	by  the	 number	 and  autoindent  edit
       options; following the command name with '!' shall cause the autoindent
       edit option setting to be toggled for  the  duration  of	 this  command
       only.

       Current	line:  Set to the last input line; if no lines were input, set
       to the line before the first address, or to the first line of the  edit
       buffer if there are no lines preceding the first address, or to zero if
       the edit buffer is empty.

       Current column: Set to non- <blank>.

   Change Directory
       Synopsis:

	      chd[ir][!][directory]cd[!][directory]

       Change the current working directory to directory.

       If no directory argument is specified, and the HOME  environment	 vari‐
       able  is set to a non-null and non-empty value, directory shall default
       to the value named in the HOME environment variable. If the HOME	 envi‐
       ronment	variable is empty or is undefined, the default value of direc‐
       tory is implementation-defined.

       If no '!' is appended to the command name, and the edit buffer has been
       modified	 since	the last complete write, and the current pathname does
       not begin with a '/', it shall be an error.

       Current line: Unchanged.

       Current column: Unchanged.

   Copy
       Synopsis:

	      [2addr] co[py] 1addr [flags]
	      [2addr] t 1addr [flags]

       Copy the specified lines after the  specified  destination  line;  line
       zero  specifies	that the lines shall be placed at the beginning of the
       edit buffer.

       Current line: Set to the last line copied.

       Current column: Set to non- <blank>.

   Delete
       Synopsis:

	      [2addr] d[elete][buffer][count][flags]

       Delete the specified lines into a buffer	 (defaulting  to  the  unnamed
       buffer), which shall become a line-mode buffer.

       Flags can immediately follow the command name; see Command Line Parsing
       in ex .

       Current line: Set to the line following the deleted lines,  or  to  the
       last  line  in the edit buffer if that line is past the end of the edit
       buffer, or to zero if the edit buffer is empty.

       Current column: Set to non- <blank>.

   Edit
       Synopsis:

	      e[dit][!][+command][file]ex[!][+command][file]

       If no '!' is appended to the command name, and the edit buffer has been
       modified since the last complete write, it shall be an error.

       If  file	 is specified, replace the current contents of the edit buffer
       with the current contents of file, and  set  the	 current  pathname  to
       file.  If  file	is  not specified, replace the current contents of the
       edit buffer with the current contents of the file named by the  current
       pathname.  If for any reason the current contents of the file cannot be
       accessed, the edit buffer shall be empty.

       The + command option shall be <blank>-delimited; <blank>s within + com‐
       mand can be escaped by preceding them with a backslash character. The +
       command shall be interpreted as an ex  command  immediately  after  the
       contents of the edit buffer have been replaced and the current line and
       column have been set.

       If the edit buffer is empty:

       Current line: Set to 0.

       Current column: Set to 1.

       Otherwise, if executed while in ex command mode or  if  the  +  command
       argument is specified:

       Current line: Set to the last line of the edit buffer.

       Current column: Set to non- <blank>.

       Otherwise, if file is omitted or results in the current pathname:

       Current line: Set to the first line of the edit buffer.

       Current column: Set to non- <blank>.

       Otherwise,  if  file  is the same as the last file edited, the line and
       column shall be set as follows; if the file was previously edited,  the
       line and column may be set as follows:

       Current	line:  Set  to	the  last  value  held when that file was last
       edited. If this value is not a valid line in the new edit  buffer,  set
       to the first line of the edit buffer.

       Current column: If the current line was set to the last value held when
       the file was last edited, set to the last value held when the file  was
       last  edited.  Otherwise, or if the last value is not a valid column in
       the new edit buffer, set to non- <blank>.

       Otherwise:

       Current line: Set to the first line of the edit buffer.

       Current column: Set to non- <blank>.

   File
       Synopsis:

	      f[ile][file]

       If a file argument is specified, the alternate pathname shall be set to
       the current pathname, and the current pathname shall be set to file.

       Write  an informational message. If the file has a current pathname, it
       shall be included in this message; otherwise, the message  shall	 indi‐
       cate  that  there  is  no current pathname. If the edit buffer contains
       lines, the current line number and the number of lines in the edit buf‐
       fer  shall  be  included	 in this message; otherwise, the message shall
       indicate that the edit buffer is empty. If the  edit  buffer  has  been
       modified	 since the last complete write, this fact shall be included in
       this message. If the readonly edit option is set, this  fact  shall  be
       included	 in  this  message.  The message may contain other unspecified
       information.

       Current line: Unchanged.

       Current column: Unchanged.

   Global
       Synopsis:

	      [2addr] g[lobal] /pattern/ [commands]
	      [2addr] v /pattern/ [commands]

       The optional '!' character after the global command shall be  the  same
       as executing the v command.

       If  pattern  is	empty  (for example, "//" ) or not specified, the last
       regular expression used in the editor command shall be used as the pat‐
       tern.  The pattern can be delimited by slashes (shown in the Synopsis),
       as well as any non-alphanumeric or non- <blank> other  than  backslash,
       vertical line, double quote, or <newline>.

       If no lines are specified, the lines shall default to the entire file.

       The  global  and	 v commands are logically two-pass operations.	First,
       mark the lines within the specified lines for which the line  excluding
       the  terminating	 <newline>  matches ( global) or does not match ( v or
       global!)	 the specified pattern. Second, execute the ex commands	 given
       by  commands, with the current line ( '.' ) set to each marked line. If
       an error occurs during this process, or the contents of the edit buffer
       are  replaced  (for  example, by the ex :edit command) an error message
       shall be written and no more commands resulting from the	 execution  of
       this command shall be processed.

       Multiple	 ex commands can be specified by entering multiple commands on
       a single line using a vertical line to delimit them, or one  per	 line,
       by escaping each <newline> with a backslash.

       If no commands are specified:

	1. If  in  ex  command	mode, it shall be as if the print command were
	   specified.

	2. Otherwise, no command shall be executed.

       For the append, change, and insert commands, the input  text  shall  be
       included	 as  part  of  the  command, and the terminating period can be
       omitted if the command ends the list of commands. The open  and	visual
       commands	 can  be  specified as one of the commands, in which case each
       marked line shall cause the editor to enter open	 or  visual  mode.  If
       open  or visual mode is exited using the vi Q command, the current line
       shall be set to the next marked line, and open  or  visual  mode	 reen‐
       tered, until the list of marked lines is exhausted.

       The  global,  v,	 and  undo commands cannot be used in commands. Marked
       lines may be deleted by commands executed for lines  occurring  earlier
       in  the file than the marked lines.  In this case, no commands shall be
       executed for the deleted lines.

       If the remembered search direction is not set, the global  and  v  com‐
       mands shall set it to forward.

       The  autoprint  and  autoindent edit options shall be inhibited for the
       duration of the g or v command.

       Current line: If no commands executed, set to  the  last	 marked	 line.
       Otherwise, as specified for the executed ex commands.

       Current	column: If no commands are executed, set to non- <blank>; oth‐
       erwise, as specified for the individual ex commands.

   Insert
       Synopsis:

	      [1addr] i[nsert][!]

       Enter ex text input mode; the input text shall  be  placed  before  the
       specified  line.	 If the line is zero or 1, the text shall be placed at
       the beginning of the edit buffer.

       This command shall be  affected	by  the	 number	 and  autoindent  edit
       options; following the command name with '!' shall cause the autoindent
       edit option setting to be toggled for  the  duration  of	 this  command
       only.

       Current	line:  Set to the last input line; if no lines were input, set
       to the line before the specified line, or to the first line of the edit
       buffer  if  there are no lines preceding the specified line, or zero if
       the edit buffer is empty.

       Current column: Set to non- <blank>.

   Join
       Synopsis:

	      [2addr] j[oin][!][count][flags]

       If count is specified: If no address was specified,  the	 join  command
       shall  behave  as  if  2addr were the current line and the current line
       plus count (.,. + count).

       If one address was specified, the join command shall behave as if 2addr
       were the specified address and the specified address plus count ( addr,
       addr + count).

       If two addresses were specified, the join command shall behave as if an
       additional  address,  equal  to the last address plus count -1 ( addr1,
       addr2, addr2 + count -1), was specified.

       If this would result in a second address greater than the last line  of
       the  edit buffer, it shall be corrected to be equal to the last line of
       the edit buffer.

       If no count is specified: If no address was specified, the join command
       shall  behave  as if 2addr were the current line and the next line (.,.
       +1).

       If one address was specified, the join command shall behave as if 2addr
       were the specified address and the next line ( addr, addr +1).

       Join  the  text	from  the specified lines together into a single line,
       which shall replace the specified lines.

       If a '!' character is appended to the command name, the join  shall  be
       without modification of any line, independent of the current locale.

       Otherwise,  in  the  POSIX locale, set the current line to the first of
       the specified lines, and then, for each	subsequent  line,  proceed  as
       follows:

	1. Discard leading <space>s from the line to be joined.

	2. If  the line to be joined is now empty, delete it, and skip steps 3
	   through 5.

	3. If the current line ends in a <blank>, or the  first	 character  of
	   the	line  to  be joined is a ')' character, join the lines without
	   further modification.

	4. If the last character of the current line is a '.', join the	 lines
	   with two <space>s between them.

	5. Otherwise, join the lines with a single <space> between them.

       Current line: Set to the first line specified.

       Current column: Set to non- <blank>.

   List
       Synopsis:

	      [2addr] l[ist][count][flags]

       This command shall be equivalent to the ex command:

	      [2addr] p[rint][count] l[flags]

       See Print .

   Map
       Synopsis:

	      map[!][lhs rhs]

       If lhs and rhs are not specified:

	1. If  '!'  is	specified,  write  the current list of text input mode
	   maps.

	2. Otherwise, write the current list of command mode maps.

	3. Do nothing more.

       Implementations may restrict the set of characters accepted in  lhs  or
       rhs,  except  that  printable  characters  and  <blank>s	 shall	not be
       restricted. Additional restrictions shall be implementation-defined. In
       both  lhs  and rhs, any character can be escaped with a <control>-V, in
       which case the character shall not be used to delimit lhs from rhs, and
       the escaping <control>-V shall be discarded.

       If  the	character '!' is appended to the map command name, the mapping
       shall be effective during open or visual text input  mode  rather  than
       open or visual command mode.  This allows lhs to have two different map
       definitions at the same time: one for command mode  and	one  for  text
       input mode.

       For  command mode mappings: When the lhs is entered as any part of a vi
       command in open or visual mode (but not as part of the arguments to the
       command),  the  action  shall  be  as if the corresponding rhs had been
       entered.

       If any character in the command, other than the first, is escaped using
       a <control>-V character, that character shall not be part of a match to
       an lhs.

       It is unspecified whether implementations shall	support	 map  commands
       where  the  lhs	is  more  than a single character in length, where the
       first character of the lhs is printable.

       If lhs contains more than one character and the first character is '#',
       followed	 by  a sequence of digits corresponding to a numbered function
       key, then when this function key is typed it shall be  mapped  to  rhs.
       Characters  other  than digits following a '#' character also represent
       the function key named by the characters in the lhs following  the  '#'
       and may be mapped to rhs. It is unspecified how function keys are named
       or what function keys are supported.

       For text input mode mappings: When the lhs is entered as	 any  part  of
       text entered in open or visual text input modes, the action shall be as
       if the corresponding rhs had been entered.

       If any character in the input text is escaped using a <control>-V char‐
       acter, that character shall not be part of a match to an lhs.

       It  is  unspecified  whether the lhs text entered for subsequent map or
       unmap commands is replaced with the rhs text for the  purposes  of  the
       screen  display; regardless of whether or not the display appears as if
       the corresponding rhs text was entered, the effect of the command shall
       be as if the lhs text was entered.

       If only part of the lhs is entered, it is unspecified how long the edi‐
       tor will wait  for  additional,	possibly  matching  characters	before
       treating the already entered characters as not matching the lhs.

       The  rhs	 characters  shall  themselves be subject to remapping, unless
       otherwise specified by the remap edit option, except that if the	 char‐
       acters in lhs occur as prefix characters in rhs, those characters shall
       not be remapped.

       On block-mode terminals, the mapping need not  occur  immediately  (for
       example,	 it  may occur after the terminal transmits a group of charac‐
       ters to the system), but it shall achieve the same  results  as	if  it
       occurred immediately.

       Current line: Unchanged.

       Current column: Unchanged.

   Mark
       Synopsis:

	      [1addr] ma[rk] character
	      [1addr] k character

       Implementations	shall  support	character values of a single lowercase
       letter of the POSIX locale and the characters '`' and '" ;  support  of
       other characters is implementation-defined.

       If  executing  the  vi m command, set the specified mark to the current
       line and 1-based numbered character referenced by the  current  column,
       if any; otherwise, column position 1.

       Otherwise,  set	the  specified	mark to the specified line and 1-based
       numbered first non- <blank> non- <newline> in the line, if any;	other‐
       wise,  the  last	 non- <newline> in the line, if any; otherwise, column
       position 1.

       The mark shall remain associated with the line until the mark is	 reset
       or  the	line is deleted. If a deleted line is restored by a subsequent
       undo command, any marks previously associated with the line, which have
       not  been reset, shall be restored as well. Any use of a mark not asso‐
       ciated with a current line in the edit buffer shall be an error.

       The marks ` and ' shall be set  as  described  previously,  immediately
       before the following events occur in the editor:

	1. The use of '$' as an ex address

	2. The use of a positive decimal number as an ex address

	3. The use of a search command as an ex address

	4. The use of a mark reference as an ex address

	5. The	use  of	 the  following	 open  and visual mode commands: <con‐
	   trol>-], %, (, ), [, ], {, }

	6. The use of the following open and visual mode commands: ', G, H, L,
	   M, z if the current line will change as a result of the command

	7. The	use of the open and visual mode commands: /, ?, N, `, n if the
	   current line or column will change as a result of the command

	8. The use of the ex mode commands: z, undo, global, v

       For rules 1., 2., 3., and 4., the ` and ' marks shall not be set if the
       ex  command is parsed as specified by rule 6.a. in Command Line Parsing
       in ex .

       For rules 5., 6., and 7., the ` and ' marks shall not  be  set  if  the
       commands are used as motion commands in open and visual mode.

       For  rules  1., 2., 3., 4., 5., 6., 7., and 8., the ` and ' marks shall
       not be set if the command fails.

       The ` and ' marks shall be set as described previously, each  time  the
       contents	 of the edit buffer are replaced (including the editing of the
       initial buffer), if in open or visual mode, or if in ex	mode  and  the
       edit  buffer  is not empty, before any commands or movements (including
       commands or movements specified by the -c or -t options or the  +  com‐
       mand  argument)	are  executed on the edit buffer. If in open or visual
       mode, the marks shall be set as if executing the vi m  command;	other‐
       wise, as if executing the ex mark command.

       When changing from ex mode to open or visual mode, if the ` and ' marks
       are not already set, the ` and ' marks shall be set as described previ‐
       ously.

       Current line: Unchanged.

       Current column: Unchanged.

   Move
       Synopsis:

	      [2addr] m[ove] 1addr [flags]

       Move the specified lines after the specified destination line. A desti‐
       nation of line zero specifies that the lines shall  be  placed  at  the
       beginning  of  the edit buffer. It shall be an error if the destination
       line is within the range of lines to be moved.

       Current line: Set to the last of the moved lines.

       Current column: Set to non- <blank>.

   Next
       Synopsis:

	      n[ext][!][+command][file ...]

       If no '!' is appended to the command name, and the edit buffer has been
       modified	 since	the  last complete write, it shall be an error, unless
       the file is successfully written as specified by the autowrite option.

       If one or more files is specified:

	1. Set the argument list to the specified filenames.

	2. Set the current argument list reference to be the  first  entry  in
	   the argument list.

	3. Set the current pathname to the first filename specified.

       Otherwise:

	1. It shall be an error if there are no more filenames in the argument
	   list after the filename currently referenced.

	2. Set the current pathname and the current argument list reference to
	   the	filename  after the filename currently referenced in the argu‐
	   ment list.

       Replace the contents of the edit buffer with the contents of  the  file
       named  by  the  current pathname. If for any reason the contents of the
       file cannot be accessed, the edit buffer shall be empty.

       This command shall be affected  by  the	autowrite  and	writeany  edit
       options.

       The  +  command	option	shall  be  <blank>-delimited;  <blank>s can be
       escaped by preceding them with a backslash  character.  The  +  command
       shall be interpreted as an ex command immediately after the contents of
       the edit buffer have been replaced and the current line and column have
       been set.

       Current line: Set as described for the edit command.

       Current column: Set as described for the edit command.

   Number
       Synopsis:

	      [2addr] nu[mber][count][flags]
	      [2addr] #[count][flags]

       These commands shall be equivalent to the ex command:

	      [2addr] p[rint][count] #[flags]

       See Print .

   Open
       Synopsis:

	      [1addr] o[pen] /pattern/ [flags]

       This command need not be supported on block-mode terminals or terminals
       with insufficient capabilities. If standard input, standard output,  or
       standard error are not terminal devices, the results are unspecified.

       Enter open mode.

       The  trailing  delimiter	 can be omitted from pattern at the end of the
       command line. If pattern is empty (for example, "//" )  or  not	speci‐
       fied,  the  last regular expression used in the editor shall be used as
       the pattern. The pattern can be delimited by slashes (shown in the Syn‐
       opsis),	as  well as any alphanumeric, or non- <blank> other than back‐
       slash, vertical line, double quote, or <newline>.

       Current line: Set to the specified line.

       Current column: Set to non- <blank>.

   Preserve
       Synopsis:

	      pre[serve]

       Save the edit buffer in a form that can later be recovered by using the
       -r  option  or by using the ex recover command. After the file has been
       preserved, a mail message shall be sent to the user. This message shall
       be  readable  by	 invoking the mailx utility. The message shall contain
       the name of the file, the time of preservation, and an ex command  that
       could  be  used	to  recover  the  file.	 Additional information may be
       included in the mail message.

       Current line: Unchanged.

       Current column: Unchanged.

   Print
       Synopsis:

	      [2addr] p[rint][count][flags]

       Write the addressed lines. The behavior is unspecified if the number of
       columns	on  the display is less than the number of columns required to
       write any single character in the lines being written.

       Non-printable characters, except for the <tab>,	shall  be  written  as
       implementation-defined multi-character sequences.

       If  the # flag is specified or the number edit option is set, each line
       shall be preceded by its line number in the following format:

	      "%6d  ", <line number>

       If the l flag is specified or the list edit option is set:

	1. The	characters  listed  in	the   Base   Definitions   volume   of
	   IEEE Std 1003.1-2001,  Table	 5-1,  Escape Sequences and Associated
	   Actions shall be written as the corresponding escape sequence.

	2. Non-printable characters not in  the	 Base  Definitions  volume  of
	   IEEE Std 1003.1-2001,  Table	 5-1,  Escape Sequences and Associated
	   Actions shall be written as one three-digit octal  number  (with  a
	   preceding  backslash) for each byte in the character (most signifi‐
	   cant byte first). If the size of a byte on the  system  is  greater
	   than 9 bits, the format used for non-printable characters is imple‐
	   mentation-defined.

	3. The end of each line shall be marked with a '$',  and  literal  '$'
	   characters  within the line shall be written with a preceding back‐
	   slash.

       Long lines shall be folded; the	length	at  which  folding  occurs  is
       unspecified, but should be appropriate for the output terminal, consid‐
       ering the number of columns of the terminal.

       If a line is folded, and the l flag is not specified and the list  edit
       option  is  not set, it is unspecified whether a multi-column character
       at the folding position is separated; it shall not be discarded.

       Current line: Set to the last written line.

       Current column: Unchanged if the current line is unchanged;  otherwise,
       set to non- <blank>.

   Put
       Synopsis:

	      [1addr] pu[t][buffer]

       Append  text from the specified buffer (by default, the unnamed buffer)
       to the specified line; line zero	 specifies  that  the  text  shall  be
       placed  at  the beginning of the edit buffer. Each portion of a line in
       the buffer shall become a new line in the edit  buffer,	regardless  of
       the mode of the buffer.

       Current line: Set to the last line entered into the edit buffer.

       Current column: Set to non- <blank>.

   Quit
       Synopsis:

	      q[uit][!]

       If no '!' is appended to the command name:

	1. If the edit buffer has been modified since the last complete write,
	   it shall be an error.

	2. If there are filenames in the argument list after the filename cur‐
	   rently referenced, and the last command was not a quit, wq, xit, or
	   ZZ (see Exit ) command, it shall be an error.

       Otherwise, terminate the editing session.

   Read
       Synopsis:

	      [1addr] r[ead][!][file]

       If '!' is not the first non- <blank> to follow the command name, a copy
       of  the specified file shall be appended into the edit buffer after the
       specified line; line zero specifies that the copy shall	be  placed  at
       the  beginning  of  the edit buffer. The number of lines and bytes read
       shall be written. If no file is named, the current  pathname  shall  be
       the  default.   If there is no current pathname, then file shall become
       the current pathname. If there is no current pathname or file  operand,
       it  shall  be  an  error. Specifying a file that is not of type regular
       shall have unspecified results.

       Otherwise, if file is preceded by '!', the rest of the line  after  the
       '!'  shall  have	 '%', '#', and '!' characters expanded as described in
       Command Line Parsing in ex .

       The ex utility shall then pass two arguments to the  program  named  by
       the  shell  edit	 option; the first shall be -c and the second shall be
       the expanded arguments to the read command as a	single	argument.  The
       standard input of the program shall be set to the standard input of the
       ex program when it was invoked. The standard error and standard	output
       of  the program shall be appended into the edit buffer after the speci‐
       fied line.

       Each line in the copied file or program output (as delimited  by	 <new‐
       line>s  or  the end of the file or output if it is not immediately pre‐
       ceded by a <newline>), shall be a separate line in the edit buffer. Any
       occurrences  of	<carriage-return>  and	<newline>  pairs in the output
       shall be treated as single <newline>s.

       The special meaning of the '!' following the read command can be	 over‐
       ridden by escaping it with a backslash character.

       Current	line:  If  no  lines  are added to the edit buffer, unchanged.
       Otherwise, if in open or visual mode, set to  the  first	 line  entered
       into  the edit buffer. Otherwise, set to the last line entered into the
       edit buffer.

       Current column: Set to non- <blank>.

   Recover
       Synopsis:

	      rec[over][!] file

       If no '!' is appended to the command name, and the edit buffer has been
       modified since the last complete write, it shall be an error.

       If  no  file  operand  is specified, then the current pathname shall be
       used. If there is no current pathname or file operand, it shall	be  an
       error.

       If  no  recovery	 information has previously been saved about file, the
       recover command shall behave identically to the edit  command,  and  an
       informational message to this effect shall be written.

       Otherwise,  set	the  current pathname to file, and replace the current
       contents of the edit buffer with the recovered  contents	 of  file.  If
       there  are multiple instances of the file to be recovered, the one most
       recently saved shall be recovered, and an  informational	 message  that
       there  are previous versions of the file that can be recovered shall be
       written. The editor shall behave as if the contents of the edit	buffer
       have already been modified.

       Current file: Set as described for the edit command.

       Current column: Set as described for the edit command.

   Rewind
       Synopsis:

	      rew[ind][!]

       If no '!' is appended to the command name, and the edit buffer has been
       modified since the last complete write, it shall be  an	error,	unless
       the file is successfully written as specified by the autowrite option.

       If the argument list is empty, it shall be an error.

       The  current  argument list reference and the current pathname shall be
       set to the first filename in the argument list.

       Replace the contents of the edit buffer with the contents of  the  file
       named  by  the  current pathname. If for any reason the contents of the
       file cannot be accessed, the edit buffer shall be empty.

       This command shall be affected  by  the	autowrite  and	writeany  edit
       options.

       Current line: Set as described for the edit command.

       Current column: Set as described for the edit command.

   Set
       Synopsis:

	      se[t][option[=[value]] ...][nooption ...][option? ...][all]

       When  no	 arguments  are	 specified,  write  the value of the term edit
       option and those options	 whose	values	have  been  changed  from  the
       default	settings; when the argument all is specified, write all of the
       option values.

       Giving an option name followed by the character	'?'  shall  cause  the
       current	value  of  that option to be written. The '?' can be separated
       from the option name by zero or more <blank>s.  The '?' shall be neces‐
       sary only for Boolean valued options. Boolean options can be given val‐
       ues by the form set option to turn them on or set  no  option  to  turn
       them  off;  string  and numeric options can be assigned by the form set
       option= value. Any <blank>s in strings can be included as is by preced‐
       ing  each  <blank> with an escaping backslash. More than one option can
       be set or listed by a single set command by specifying  multiple	 argu‐
       ments, each separated from the next by one or more <blank>s.

       See Edit Options in ex for details about specific options.

       Current line: Unchanged.

       Current column: Unchanged.

   Shell
       Synopsis:

	      sh[ell]

       Invoke the program named in the shell edit option with the single argu‐
       ment -i (interactive mode). Editing shall be resumed when  the  program
       exits.

       Current line: Unchanged.

       Current column: Unchanged.

   Source
       Synopsis:

	      so[urce] file

       Read  and  execute  ex  commands	 from file. Lines in the file that are
       blank lines shall be ignored.

       Current line: As specified for the individual ex commands.

       Current column: As specified for the individual ex commands.

   Substitute
       Synopsis:

	      [2addr] s[ubstitute][/pattern/repl/[options][count][flags]]

	      [2addr] &[options][count][flags]]

	      [2addr] ~[options][count][flags]]

       Replace the first instance of the pattern pattern by the string repl on
       each  specified	line.  (See  Regular Expressions in ex and Replacement
       Strings in ex .) Any non-alphabetic, non- <blank> delimiter other  than
       '\', '|', double quote, or <newline> can be used instead of '/' . Back‐
       slash characters can be used to escape  delimiters,  backslash  charac‐
       ters, and other special characters.

       The  trailing delimiter can be omitted from pattern or from repl at the
       end of the command line. If both pattern and repl are not specified  or
       are  empty  (for example, "//" ), the last s command shall be repeated.
       If only pattern is not specified or is empty, the last regular  expres‐
       sion  used  in the editor shall be used as the pattern. If only repl is
       not specified or is empty, the pattern shall be replaced by nothing. If
       the  entire replacement pattern is '%', the last replacement pattern to
       an s command shall be used.

       Entering a <carriage-return> in repl (which requires an escaping	 back‐
       slash  in ex mode and an escaping <control>-V in open or vi mode) shall
       split the line at that point, creating a new line in the	 edit  buffer.
       The <carriage-return> shall be discarded.

       If  options  includes  the  letter  'g'	( global), all non-overlapping
       instances of the pattern in the line shall be replaced.

       If options includes the letter 'c' ( confirm), then before each substi‐
       tution  the  line  shall be written; the written line shall reflect all
       previous substitutions. On the following line, <space>s shall be	 writ‐
       ten beneath the characters from the line that are before the pattern to
       be replaced, and '^' characters written beneath the characters included
       in  the	pattern	 to  be replaced. The ex utility shall then wait for a
       response from the user. An affirmative response shall cause the substi‐
       tution  to  be done, while any other input shall not make the substitu‐
       tion. An affirmative response shall consist of a line with the affirma‐
       tive  response  (as  defined by the current locale) at the beginning of
       the line.  This line shall be subject to editing in the same way as the
       ex command line.

       If interrupted (see the ASYNCHRONOUS EVENTS section), any modifications
       confirmed by the user shall be preserved in the edit buffer  after  the
       interrupt.

       If  the remembered search direction is not set, the s command shall set
       it to forward.

       In the second Synopsis, the & command shall repeat the previous substi‐
       tution, as if the & command were replaced by:

	      s/pattern/repl/

       where pattern and repl are as specified in the previous s, &, or ~ com‐
       mand.

       In the third Synopsis, the ~ command shall repeat the previous  substi‐
       tution, as if the '~' were replaced by:

	      s/pattern/repl/

       where  pattern  shall  be  the last regular expression specified to the
       editor, and repl shall be from the previous substitution	 (including  &
       and ~) command.

       These  commands	shall be affected by the LC_MESSAGES environment vari‐
       able.

       Current line: Set to the last line in which  a  substitution  occurred,
       or, unchanged if no substitution occurred.

       Current column: Set to non- <blank>.

   Suspend
       Synopsis:

	      su[spend][!]st[op][!]

       Allow  control  to  return  to  the  invoking process; ex shall suspend
       itself as if it had received the SIGTSTP signal. The  suspension	 shall
       occur  only  if	job  control is enabled in the invoking shell (see the
       description of set -m).

       These commands shall be affected by the	autowrite  and	writeany  edit
       options.

       The  current susp character (see stty ) shall be equivalent to the sus‐
       pend command.

   Tag
       Synopsis:

	      ta[g][!] tagstring

       The results are unspecified if the format of a  tags  file  is  not  as
       specified by the ctags utility (see ctags ) description.

       The tag command shall search for tagstring in the tag files referred to
       by the tag edit option, in the order they are specified, until a refer‐
       ence  to	 tagstring is found. Files shall be searched from beginning to
       end. If no reference is found, it shall be an error and an  error  mes‐
       sage to this effect shall be written. If the reference is not found, or
       if an error occurs while processing a file referred to in the tag  edit
       option,	it shall be an error, and an error message shall be written at
       the first occurrence of such an error.

       Otherwise, if the tags file contained a pattern, the pattern  shall  be
       treated	as  a  regular expression used in the editor; for example, for
       the purposes of the s command.

       If the tagstring is in a file with a different name  than  the  current
       pathname,  set  the  current  pathname  to  the	name of that file, and
       replace the contents of the edit buffer with the contents of that file.
       In  this	 case, if no '!' is appended to the command name, and the edit
       buffer has been modified since the last complete write, it shall be  an
       error,  unless  the  file  is  successfully written as specified by the
       autowrite option.

       This command shall be affected by the autowrite,	 tag,  taglength,  and
       writeany edit options.

       Current	line:  If  the	tags file contained a line number, set to that
       line number. If the line number is larger than the  last	 line  in  the
       edit  buffer,  an  error	 message shall be written and the current line
       shall be set as specified for the edit command.

       If the tags file contained a pattern, set to the	 first	occurrence  of
       the pattern in the file. If no matching pattern is found, an error mes‐
       sage shall be written and the current line shall be  set	 as  specified
       for the edit command.

       Current	column: If the tags file contained a line-number reference and
       that line-number was not larger than the last line in the edit  buffer,
       or if the tags file contained a pattern and that pattern was found, set
       to non- <blank>. Otherwise, set as specified for the edit command.

   Unabbreviate
       Synopsis:

	      una[bbrev] lhs

       If lhs is not an entry in the current list of abbreviations (see Abbre‐
       viate  ),  it shall be an error. Otherwise, delete lhs from the list of
       abbreviations.

       Current line: Unchanged.

       Current column: Unchanged.

   Undo
       Synopsis:

	      u[ndo]

       Reverse the changes made by the last command that modified the contents
       of  the	edit  buffer, including undo. For this purpose, the global, v,
       open, and visual commands, and commands resulting  from	buffer	execu‐
       tions and mapped character expansions, are considered single commands.

       If  no action that can be undone preceded the undo command, it shall be
       an error.

       If the undo command restores lines that were  marked,  the  mark	 shall
       also  be restored unless it was reset subsequent to the deletion of the
       lines.

       Current line:

	1. If lines are added or changed in the file, set to  the  first  line
	   added or changed.

	2. Set to the line before the first line deleted, if it exists.

	3. Set to 1 if the edit buffer is not empty.

	4. Set to zero.

       Current column: Set to non- <blank>.

   Unmap
       Synopsis:

	      unm[ap][!] lhs

       If  '!'	is appended to the command name, and if lhs is not an entry in
       the list of text input mode map definitions, it shall be an error. Oth‐
       erwise, delete lhs from the list of text input mode map definitions.

       If  no  '!' is appended to the command name, and if lhs is not an entry
       in the list of command mode map definitions, it shall be an error. Oth‐
       erwise, delete lhs from the list of command mode map definitions.

       Current line: Unchanged.

       Current column: Unchanged.

   Version
       Synopsis:

	      ve[rsion]

       Write a message containing version information for the editor. The for‐
       mat of the message is unspecified.

       Current line: Unchanged.

       Current column: Unchanged.

   Visual
       Synopsis:

	      [1addr] vi[sual][type][count][flags]

       If ex is currently in open or visual mode, the Synopsis and behavior of
       the  visual command shall be the same as the edit command, as specified
       by Edit .

       Otherwise, this command need not be supported on	 block-mode  terminals
       or  terminals  with insufficient capabilities. If standard input, stan‐
       dard output, or standard error are not terminal	devices,  the  results
       are unspecified.

       If count is specified, the value of the window edit option shall be set
       to count (as described in window ). If the '^' type character was  also
       specified, the window edit option shall be set before being used by the
       type character.

       Enter visual mode. If type is not specified, it shall be as if  a  type
       of '+' was specified. The type shall cause the following effects:

       +      Place the beginning of the specified line at the top of the dis‐
	      play.

       -      Place the end of the specified line at the bottom	 of  the  dis‐
	      play.

       .      Place  the  beginning of the specified line in the middle of the
	      display.

       ^      If the specified line is less than or equal to the value of  the
	      window  edit option, set the line to 1; otherwise, decrement the
	      line by the value of the window edit option minus 1.  Place  the
	      beginning	 of  this line as close to the bottom of the displayed
	      lines as possible, while still displaying the value of the  win‐
	      dow edit option number of lines.

       Current line: Set to the specified line.

       Current column: Set to non- <blank>.

   Write
       Synopsis:

	      [2addr] w[rite][!][>>][file]
	      [2addr] w[rite][!][file]
	      [2addr] wq[!][>>][file]

       If no lines are specified, the lines shall default to the entire file.

       The  command  wq	 shall	be equivalent to a write command followed by a
       quit command; wq! shall be equivalent to write! followed	 by  quit.  In
       both  cases,  if	 the  write  command  fails,  the  quit	 shall	not be
       attempted.

       If the command name is not followed by one or more <blank>s, or file is
       not preceded by a '!' character, the write shall be to a file.

	1. If  the  >> argument is specified, and the file already exists, the
	   lines shall be appended to the file instead of replacing  its  con‐
	   tents.  If  the  >>	argument  is  specified, and the file does not
	   already exist, it is unspecified whether the write shall proceed as
	   if  the  >>	argument  had not been specified or if the write shall
	   fail.

	2. If the readonly edit option is set (see readonly ), the write shall
	   fail.

	3. If file is specified, and is not the current pathname, and the file
	   exists, the write shall fail.

	4. If file is not specified, the current pathname shall be  used.   If
	   there is no current pathname, the write command shall fail.

	5. If  the current pathname is used, and the current pathname has been
	   changed by the file or read commands,  and  the  file  exists,  the
	   write  shall	 fail.	If  the write is successful, subsequent writes
	   shall not fail for this reason  (unless  the	 current  pathname  is
	   changed again).

	6. If  the  whole edit buffer is not being written, and the file to be
	   written exists, the write shall fail.

       For rules 1., 2., 4., and 5., the write can be forced by appending  the
       character '!' to the command name.

       For  rules  2.,	4.,  and  5.,  the  write can be forced by setting the
       writeany edit option.

       Additional, implementation-defined tests may cause the write to fail.

       If the edit buffer is empty, a file without any contents shall be writ‐
       ten.

       An  informational  message  shall be written noting the number of lines
       and bytes written.

       Otherwise, if the command is followed by one or more <blank>s, and  the
       file  is preceded by '!', the rest of the line after the '!' shall have
       '%', '#', and '!'  characters expanded as  described  in	 Command  Line
       Parsing in ex .

       The  ex	utility	 shall then pass two arguments to the program named by
       the shell edit option; the first shall be -c and the  second  shall  be
       the  expanded  arguments to the write command as a single argument. The
       specified lines shall be written to the standard input of the  command.
       The standard error and standard output of the program, if any, shall be
       written as described for the print command. If the  last	 character  in
       that output is not a <newline>, a <newline> shall be written at the end
       of the output.

       The special meaning of the '!' following the write command can be over‐
       ridden by escaping it with a backslash character.

       Current line: Unchanged.

       Current column: Unchanged.

   Write and Exit
       Synopsis:

	      [2addr] x[it][!][file]

       If the edit buffer has not been modified since the last complete write,
       xit shall be equivalent to the quit command, or if a '!' is appended to
       the command name, to quit!.

       Otherwise,  xit	shall  be equivalent to the wq command, or if a '!' is
       appended to the command name, to wq!.

       Current line: Unchanged.

       Current column: Unchanged.

   Yank
       Synopsis:

	      [2addr] ya[nk][buffer][count]

       Copy the specified lines to  the	 specified  buffer  (by	 default,  the
       unnamed buffer), which shall become a line-mode buffer.

       Current line: Unchanged.

       Current column: Unchanged.

   Adjust Window
       Synopsis:

	      [1addr] z[!][type ...][count][flags]

       If no line is specified, the current line shall be the default; if type
       is omitted as well, the current line value shall first  be  incremented
       by  1.  If  incrementing	 the current line would cause it to be greater
       than the last line in the edit buffer, it shall be an error.

       If there are <blank>s between the type argument	and  the  preceding  z
       command name or optional '!'  character, it shall be an error.

       If count is specified, the value of the window edit option shall be set
       to count (as described in window ).  If	count  is  omitted,  it	 shall
       default	to  2  times  the value of the scroll edit option, or if ! was
       specified, the number of lines in the display minus 1.

       If type is omitted, then count lines starting with the  specified  line
       shall  be written. Otherwise, count lines starting with the line speci‐
       fied by the type argument shall be written.

       The type argument shall change the lines to be  written.	 The  possible
       values of type are as follows:

       -      The specified line shall be decremented by the following value:

	      (((number of "-" characters) x count) -1)

       If the calculation would result in a number less than 1, it shall be an
       error. Write lines from the edit buffer, starting at the new  value  of
       line,  until  count  lines or the last line in the edit buffer has been
       written.

       +      The specified line shall be incremented by the following value:

	      (((number of "+" characters) -1) x count) +1

       If the calculation would result in a number greater than the last  line
       in  the	edit  buffer,  it shall be an error. Write lines from the edit
       buffer, starting at the new value of line, until	 count	lines  or  the
       last line in the edit buffer has been written.

       =,.    If  more	than  a single '.' or '=' is specified, it shall be an
	      error. The following steps shall be taken:

	       1. If count is zero, nothing shall be written.

	       2. Write as many of the N lines before the current line in  the
		  edit buffer as exist. If count or '!' was specified, N shall
		  be:

		  (count -1) /2

	      Otherwise, N shall be:

		     (count -3) /2

	      If N is a number less than 3, no lines shall be written.

	       3. If '=' was specified as the type  character,	write  a  line
		  consisting  of  the  smaller of the number of columns in the
		  display divided by two, or 40 '-' characters.

	       4. Write the current line.

	       5. Repeat step 3.

	       6. Write as many of the N lines after the current line  in  the
		  edit buffer as exist. N shall be defined as in step 2.  If N
		  is a number less than 3, no lines shall be written. If count
		  is less than 3, no lines shall be written.

       ^      The specified line shall be decremented by the following value:

	      (((number of "^" characters) +1) x count) -1

       If the calculation would result in a number less than 1, it shall be an
       error. Write lines from the edit buffer, starting at the new  value  of
       line,  until  count  lines or the last line in the edit buffer has been
       written.

       Current line: Set to the last line written, unless the type  is	=,  in
       which case, set to the specified line.

       Current column: Set to non- <blank>.

   Escape
       Synopsis:

	      ! command
	      [addr]! command

       The  contents  of  the  line after the '!' shall have '%', '#', and '!'
       characters expanded as described in Command Line Parsing in ex . If the
       expansion  causes  the  text  of the line to change, it shall be redis‐
       played, preceded by a single '!' character.

       The ex utility shall execute  the  program  named  by  the  shell  edit
       option.	It shall pass two arguments to the program; the first shall be
       -c, and the second shall be the expanded arguments to the ! command  as
       a single argument.

       If  no  lines  are  specified, the standard input, standard output, and
       standard error of the program shall be set to the standard input, stan‐
       dard  output, and standard error of the ex program when it was invoked.
       In addition, a warning message shall be written if the edit buffer  has
       been  modified  since the last complete write, and the warn edit option
       is set.

       If lines are specified, they shall be passed to the program as standard
       input,  and the standard output and standard error of the program shall
       replace those lines in the edit buffer. Each line in the program output
       (as delimited by <newline>s or the end of the output if it is not imme‐
       diately preceded by a <newline>), shall be a separate line in the  edit
       buffer. Any occurrences of <carriage-return> and <newline> pairs in the
       output shall be treated as single <newline>s. The specified lines shall
       be  copied  into	 the  unnamed buffer before they are replaced, and the
       unnamed buffer shall become a line-mode buffer.

       If in ex mode, a single '!' character shall be written when the program
       completes.

       This  command  shall be affected by the shell and warn edit options. If
       no lines are specified, this command shall be affected by the autowrite
       and  writeany edit options.  If lines are specified, this command shall
       be affected by the autoprint edit option.

       Current line:

	1. If no lines are specified, unchanged.

	2. Otherwise, set to the last line read in, if any lines are read in.

	3. Otherwise, set to the line before the first line of the lines spec‐
	   ified, if that line exists.

	4. Otherwise,  set  to	the  first line of the edit buffer if the edit
	   buffer is not empty.

	5. Otherwise, set to zero.

       Current column: If no lines are specified, unchanged. Otherwise, set to
       non- <blank>.

   Shift Left
       Synopsis:

	      [2addr] <[< ...][count][flags]

       Shift  the specified lines to the start of the line; the number of col‐
       umn positions to be shifted shall be the number of  command  characters
       times  the  value  of the shiftwidth edit option. Only leading <blank>s
       shall be deleted or changed into	 other	<blank>s  in  shifting;	 other
       characters shall not be affected.

       Lines  to  be  shifted  shall  be copied into the unnamed buffer, which
       shall become a line-mode buffer.

       This command shall be affected by the autoprint edit option.

       Current line: Set to the last line in the lines specified.

       Current column: Set to non- <blank>.

   Shift Right
       Synopsis:

	      [2addr] >[> ...][count][flags]

       Shift the specified lines away from the start of the line;  the	number
       of  column positions to be shifted shall be the number of command char‐
       acters times the value of the shiftwidth edit option.  The shift	 shall
       be  accomplished by adding <blank>s as a prefix to the line or changing
       leading <blank>s	 into  other  <blank>s.	  Empty	 lines	shall  not  be
       changed.

       Lines  to  be  shifted  shall  be copied into the unnamed buffer, which
       shall become a line-mode buffer.

       This command shall be affected by the autoprint edit option.

       Current line: Set to the last line in the lines specified.

       Current column: Set to non- <blank>.

   <control>-D
       Synopsis:

	      <control>-D

       Write the next n lines, where n is the minimum of  the  values  of  the
       scroll  edit  option  and the number of lines after the current line in
       the edit buffer. If the current line is the last line of the edit  buf‐
       fer it shall be an error.

       Current line: Set to the last line written.

       Current column: Set to non- <blank>.

   Write Line Number
       Synopsis:

	      [1addr] = [flags]

       If line is not specified, it shall default to the last line in the edit
       buffer. Write the line number of the specified line.

       Current line: Unchanged.

       Current column: Unchanged.

   Execute
       Synopsis:

	      [2addr] @ buffer[2addr] * buffer

       If no buffer is specified or is specified as '@' or '*', the last  buf‐
       fer executed shall be used. If no previous buffer has been executed, it
       shall be an error.

       For each line specified by the addresses, set the current line ( '.'  )
       to the specified line, and execute the contents of the named buffer (as
       they were at the time the @ command was executed) as ex	commands.  For
       each line of a line-mode buffer, and all but the last line of a charac‐
       ter-mode buffer, the ex command parser shall behave as if the line  was
       terminated by a <newline>.

       If  an  error  occurs  during  this process, or a line specified by the
       addresses does not exist when the current line would be set to  it,  or
       more  than  a  single line was specified by the addresses, and the con‐
       tents of the edit buffer are replaced (for example,  by	the  ex	 :edit
       command)	 an  error  message  shall  be	written,  and no more commands
       resulting from the execution of this command shall be processed.

       Current line: As specified for the individual ex commands.

       Current column: As specified for the individual ex commands.

   Regular Expressions in ex
       The ex utility shall support regular expressions that are a superset of
       the  basic regular expressions described in the Base Definitions volume
       of IEEE Std 1003.1-2001, Section 9.3, Basic Regular Expressions. A null
       regular	expression  (  "//"  ) shall be equivalent to the last regular
       expression encountered.

       Regular expressions can be used in addresses to specify lines  and,  in
       some  commands  (for  example, the substitute command), to specify por‐
       tions of a line to be substituted.

       The following constructs can be	used  to  enhance  the	basic  regular
       expressions:

       \<     Match  the  beginning  of a word. (See the definition of word at
	      the beginning of Command Descriptions in ex .)

       \>     Match the end of a word.

       ~      Match the replacement part of the last substitute	 command.  The
	      tilde  (	'~' ) character can be escaped in a regular expression
	      to become a normal character with no special meaning.  The back‐
	      slash shall be discarded.

       When  the editor option magic is not set, the only characters with spe‐
       cial meanings shall be '^' at the beginning of a pattern,  '$'  at  the
       end  of	a  pattern,  and  '\' .	 The characters '.', '*', '[', and '~'
       shall be treated as ordinary characters unless preceded by a '\' ; when
       preceded	 by  a	'\' they shall regain their special meaning, or in the
       case of backslash, be handled as a single backslash.  Backslashes  used
       to escape other characters shall be discarded.

   Replacement Strings in ex
       The  character '&' ( '\&' if the editor option magic is not set) in the
       replacement string shall stand for the text matched by the  pattern  to
       be  replaced.  The  character  '~' ( '\~' if magic is not set) shall be
       replaced by the replacement part of the	previous  substitute  command.
       The sequence '\n', where n is an integer, shall be replaced by the text
       matched by the pattern enclosed in the nth set of parentheses '\('  and
       '\)' .

       The  strings  '\l', '\u', '\L', and '\U' can be used to modify the case
       of elements in the replacement string (using the	 '\&'  or  "\"	digit)
       notation.  The string '\l' ( '\u' ) shall cause the character that fol‐
       lows to be converted to lowercase (uppercase).  The string '\L' (  '\U'
       ) shall cause all characters subsequent to it to be converted to lower‐
       case (uppercase) as they are inserted by	 the  substitution  until  the
       string  '\e'  or '\E', or the end of the replacement string, is encoun‐
       tered.

       Otherwise, any character following a backslash shall be treated as that
       literal character, and the escaping backslash shall be discarded.

       An example of case conversion with the s command is as follows:

	      :p
	      The cat sat on the mat.
	      :s/\<.at\>/\u&/gp
	      The Cat Sat on the Mat.
	      :s/S\(.*\)M/S\U\1\eM/p
	      The Cat SAT ON THE Mat.

   Edit Options in ex
       The ex utility has a number of options that modify its behavior.	 These
       options have default settings, which can be changed using the set  com‐
       mand.

       Options are Boolean unless otherwise specified.

   autoindent, ai
       [Default unset]

       If  autoindent is set, each line in input mode shall be indented (using
       first as many <tab>s as possible, as determined by  the	editor	option
       tabstop,	 and  then using <space>s) to align with another line, as fol‐
       lows:

	1. If in open or visual mode and the text input is part of a line-ori‐
	   ented  command  (see the EXTENDED DESCRIPTION in vi ), align to the
	   first column.

	2. Otherwise, if in open or visual mode,  indentation  for  each  line
	   shall be set as follows:

	    a. If  a  line was previously inserted as part of this command, it
	       shall be set to the indentation of the last  inserted  line  by
	       default,	 or as otherwise specified for the <control>-D charac‐
	       ter in Input Mode Commands in vi .

	    b. Otherwise, it shall be set to the indentation of	 the  previous
	       current line, if any; otherwise, to the first column.

	3. For the ex a, i, and c commands, indentation for each line shall be
	   set as follows:

	    a. If a line was previously inserted as part of this  command,  it
	       shall  be  set  to the indentation of the last inserted line by
	       default, or as otherwise specified for  the  eof	 character  in
	       Scroll .

	    b. Otherwise,  if the command is the ex a command, it shall be set
	       to the line appended after, if any; otherwise to the first col‐
	       umn.

	    c. Otherwise,  if the command is the ex i command, it shall be set
	       to the line inserted before, if any;  otherwise	to  the	 first
	       column.

	    d. Otherwise,  if the command is the ex c command, it shall be set
	       to the indentation of the line replaced.

   autoprint, ap
       [Default set]

       If autoprint is set, the current line shall be written  after  each  ex
       command	that  modifies	the  contents  of the current edit buffer, and
       after each tag command for which the tag search pattern	was  found  or
       tag line number was valid, unless:

	1. The command was executed while in open or visual mode.

	2. The command was executed as part of a global or v command or @ buf‐
	   fer execution.

	3. The command was the form of the read command that reads a file into
	   the edit buffer.

	4. The command was the append, change, or insert command.

	5. The command was not terminated by a <newline>.

	6. The	current	 line shall be written by a flag specified to the com‐
	   mand; for example, delete # shall write the current line as	speci‐
	   fied for the flag modifier to the delete command, and not as speci‐
	   fied by the autoprint edit option.

   autowrite, aw
       [Default unset]

       If autowrite is set, and the edit buffer has been modified since it was
       last  completely	 written  to any file, the contents of the edit buffer
       shall be written as if the ex write command had been specified  without
       arguments, before each command affected by the autowrite edit option is
       executed. Appending the character '!' to the command name of any of the
       ex commands except '!' shall prevent the write.	If the write fails, it
       shall be an error and the command shall not be executed.

   beautify, bf
       [Default unset]

       If beautify is set, all non-printable characters,  other	 than  <tab>s,
       <newline>s, and <form-feed>s, shall be discarded from text read in from
       files.

   directory, dir
       [Default implementation-defined]

       The value of this option specifies the directory in  which  the	editor
       buffer  is to be placed. If this directory is not writable by the user,
       the editor shall quit.

   edcompatible, ed
       [Default unset]

       Causes the presence of g and c suffixes on substitute  commands	to  be
       remembered, and toggled by repeating the suffixes.

   errorbells, eb
       [Default unset]

       If the editor is in ex mode, and the terminal does not support a stand‐
       out mode (such as inverse video), and errorbells is set, error messages
       shall be preceded by alerting the terminal.

   exrc
       [Default unset]

       If  exrc	 is  set, ex shall access any .exrc file in the current direc‐
       tory, as described in Initialization in ex and vi . If exrc is not set,
       ex shall ignore any .exrc file in the current directory during initial‐
       ization, unless the current directory is that named by the  HOME	 envi‐
       ronment variable.

   ignorecase, ic
       [Default unset]

       If ignorecase is set, characters that have uppercase and lowercase rep‐
       resentations shall have those representations considered as  equivalent
       for purposes of regular expression comparison.

       The  ignorecase edit option shall affect all remembered regular expres‐
       sions; for example, unsetting the ignorecase edit option shall cause  a
       subsequent vi n command to search for the last basic regular expression
       in a case-sensitive fashion.

   list
       [Default unset]

       If list is set, edit buffer lines written  while	 in  ex	 command  mode
       shall  be  written  as  specified for the print command with the l flag
       specified. In open or visual mode, each edit buffer line shall be  dis‐
       played as specified for the ex print command with the l flag specified.
       In open or visual text input mode, when the cursor does not rest on any
       character  in the line, it shall rest on the '$' marking the end of the
       line.

   magic
       [Default set]

       If magic is set, modify the interpretation  of  characters  in  regular
       expressions  and	 substitution replacement strings (see Regular Expres‐
       sions in ex and Replacement Strings in ex ).

   mesg
       [Default set]

       If mesg is set, the permission for others to use the write or talk com‐
       mands to write to the terminal shall be turned on while in open or vis‐
       ual mode. The shell-level command mesg n shall take precedence over any
       setting of the ex mesg option; that is, if mesg y was issued before the
       editor started (or in a shell escape), such as:

	      :!mesg y

       the mesg option in ex shall suppress incoming messages,	but  the  mesg
       option shall not enable incoming messages if mesg n was issued.

   number, nu
       [Default unset]

       If  number  is  set, edit buffer lines written while in ex command mode
       shall be written with line numbers, in  the  format  specified  by  the
       print  command  with  the # flag specified. In ex text input mode, each
       line shall be preceded by the line number it will have in the file.

       In open or visual mode, each edit buffer line shall be displayed with a
       preceding  line number, in the format specified by the ex print command
       with the # flag specified. This line number  shall  not	be  considered
       part  of	 the  line  for the purposes of evaluating the current column;
       that is, column position 1 shall be the first column position after the
       format specified by the print command.

   paragraphs, para
       [Default in the POSIX locale IPLPPPQPP LIpplpipbp]

       The paragraphs edit option shall define additional paragraph boundaries
       for the open and visual mode commands. The paragraphs edit  option  can
       be  set	to  a  character  string  consisting of zero or more character
       pairs. It shall be an error to set it to an odd number of characters.

   prompt
       [Default set]

       If prompt is set, ex command mode input shall be prompted  for  with  a
       colon ( ':' ); when unset, no prompt shall be written.

   readonly
       [Default see text]

       If  the	readonly  edit	option is set, read-only mode shall be enabled
       (see Write ). The readonly edit option shall be initialized to  set  if
       either of the following conditions are true:

	* The command-line option -R was specified.

	* Performing  actions  equivalent to the access() function called with
	  the following arguments indicates that the file lacks write  permis‐
	  sion:

	   1. The current pathname is used as the path argument.

	   2. The constant W_OK is used as the amode argument.

       The readonly edit option may be initialized to set for other, implemen‐
       tation-defined reasons. The readonly edit option shall not be  initial‐
       ized  to	 unset based on any special privileges of the user or process.
       The readonly edit option shall be reinitialized each time that the con‐
       tents  of the edit buffer are replaced (for example, by an edit or next
       command) unless the user has explicitly set it, in which case it	 shall
       remain  set  until  the user explicitly unsets it. Once unset, it shall
       again be reinitialized each time that the contents of the  edit	buffer
       are replaced.

   redraw
       [Default unset]

       The editor simulates an intelligent terminal on a dumb terminal. (Since
       this is likely to require a large amount of output to the terminal,  it
       is useful only at high transmission speeds.)

   remap
       [Default set]

       If  remap is set, map translation shall allow for maps defined in terms
       of other maps; translation shall continue  until	 a  final  product  is
       obtained. If unset, only a one-step translation shall be done.

   report
       [Default 5]

       The  value  of  this  report edit option specifies what number of lines
       being added, copied, deleted, or modified in the edit buffer will cause
       an informational message to be written to the user.  The following con‐
       ditions shall cause an informational message. The message shall contain
       the  number of lines added, copied, deleted, or modified, but is other‐
       wise unspecified.

	* An ex or vi editor command, other than open, undo, or	 visual,  that
	  modifies  at	least  the  value  of the report edit option number of
	  lines, and which is not part of an ex global or v command, or ex  or
	  vi  buffer  execution,  shall	 cause	an informational message to be
	  written.

	* An ex yank or vi y or Y command, that copies at least the  value  of
	  the report edit option plus 1 number of lines, and which is not part
	  of an ex global or v command, or ex or vi  buffer  execution,	 shall
	  cause an informational message to be written.

	* An  ex  global,  v, open, undo, or visual command or ex or vi buffer
	  execution, that adds or deletes a total of at least the value of the
	  report  edit	option number of lines, and which is not part of an ex
	  global or v command, or ex or vi buffer execution,  shall  cause  an
	  informational	 message  to be written. (For example, if 3 lines were
	  added and 8 lines deleted during an ex visual command,  5  would  be
	  the number compared against the report edit option after the command
	  completed.)

   scroll, scr
       [Default (number of lines in the display -1)/2]

       The value of the scroll edit option shall determine the number of lines
       scrolled	 by  the ex <control>-D and z commands. For the vi <control>-D
       and <control>-U commands, it shall be the initial number	 of  lines  to
       scroll  when  no	 previous  <control>-D or <control>-U command has been
       executed.

   sections
       [Default in the POSIX locale NHSHH HUnhsh]

       The sections edit option shall define additional section boundaries for
       the  open and visual mode commands. The sections edit option can be set
       to a character string consisting of zero or more	 character  pairs;  it
       shall be an error to set it to an odd number of characters.

   shell, sh
       [Default from the environment variable SHELL ]

       The  value of this option shall be a string. The default shall be taken
       from the SHELL environment variable. If the SHELL environment  variable
       is null or empty, the sh (see sh ) utility shall be the default.

   shiftwidth, sw
       [Default 8]

       The value of this option shall give the width in columns of an indenta‐
       tion level used during autoindentation and by the shift	commands  (  <
       and >).

   showmatch, sm
       [Default unset]

       The  functionality  described for the showmatch edit option need not be
       supported on block-mode terminals or terminals with insufficient	 capa‐
       bilities.

       If  showmatch  is  set,	in  open  or visual mode, when a ')' or '}' is
       typed, if the matching '(' or '{' is currently visible on the  display,
       the matching '(' or '{' shall be flagged moving the cursor to its loca‐
       tion for an unspecified amount of time.

   showmode
       [Default unset]

       If showmode is set, in open or visual mode, the current mode  that  the
       editor  is  in shall be displayed on the last line of the display. Com‐
       mand mode and text input mode shall be differentiated;  other  unspeci‐
       fied modes and implementation-defined information may be displayed.

   slowopen
       [Default unset]

       If  slowopen is set during open and visual text input modes, the editor
       shall not update portions of the display other than those display  line
       columns that display the characters entered by the user (see Input Mode
       Commands in vi ).

   tabstop, ts
       [Default 8]

       The value of this edit option shall specify the column boundary used by
       a <tab> in the display (see autoprint, ap and Input Mode Commands in vi
       ).

   taglength, tl
       [Default zero]

       The value of this edit option shall specify the maximum number of char‐
       acters  that  are considered significant in the user-specified tag name
       and in the tag name from the tags file. If the value is zero, all char‐
       acters in both tag names shall be significant.

   tags
       [Default see text]

       The  value  of  this edit option shall be a string of <blank>-delimited
       pathnames of files used by the  tag  command.   The  default  value  is
       unspecified.

   term
       [Default from the environment variable TERM ]

       The  value  of this edit option shall be a string. The default shall be
       taken from the TERM variable in the environment. If the	TERM  environ‐
       ment  variable is empty or null, the default is unspecified. The editor
       shall use the value of this edit option to determine the	 type  of  the
       display device.

       The  results  are unspecified if the user changes the value of the term
       edit option after editor initialization.

   terse
       [Default unset]

       If terse is set, error messages may be less  verbose.  However,	except
       for  this caveat, error messages are unspecified.  Furthermore, not all
       error messages need change for different settings of this option.

   warn
       [Default set]

       If warn is set, and the contents of the edit buffer have been  modified
       since they were last completely written, the editor shall write a warn‐
       ing message before certain ! commands (see Escape ).

   window
       [Default see text]

       A value used in open and visual mode,  by  the  <control>-B  and	 <con‐
       trol>-F	commands,  and, in visual mode, to specify the number of lines
       displayed when the screen is repainted.

       If the -w command-line option is not specified, the default value shall
       be  set	to  the	 value of the LINES environment variable. If the LINES
       environment variable is empty or null, the default shall be the	number
       of lines in the display minus 1.

       Setting	the  window edit option to zero or to a value greater than the
       number of lines in the display minus 1 (either explicitly or  based  on
       the -w option or the LINES environment variable) shall cause the window
       edit option to be set to the number of lines in the display minus 1.

       The baud rate of the terminal line may change the default in an	imple‐
       mentation-defined manner.

   wrapmargin, wm
       [Default 0]

       If the value of this edit option is zero, it shall have no effect.

       If not in the POSIX locale, the effect of this edit option is implemen‐
       tation-defined.

       Otherwise, it shall specify a number of columns from the ending	margin
       of the terminal.

       During  open  and visual text input modes, for each character for which
       any part of the character is displayed in a column that	is  less  than
       wrapmargin columns from the ending margin of the display line, the edi‐
       tor shall behave as follows:

	1. If the character triggering this event is a <blank>,	 it,  and  all
	   immediately	preceding  <blank>s on the current line entered during
	   the execution of the current text  input  command,  shall  be  dis‐
	   carded,  and	 the  editor shall behave as if the user had entered a
	   single <newline> instead. In addition,  if  the  next  user-entered
	   character is a <space>, it shall be discarded as well.

	2. Otherwise,  if  there  are one or more <blank>s on the current line
	   immediately preceding the last  group  of  inserted	non-  <blank>s
	   which  was  entered	during the execution of the current text input
	   command, the <blank>s shall be replaced as if the user had  entered
	   a single <newline> instead.

       If the autoindent edit option is set, and the events described in 1. or
       2. are performed, any <blank>s at or after the cursor  in  the  current
       line shall be discarded.

       The  ending  margin  shall be determined by the system or overridden by
       the user, as described for COLUMNS in the ENVIRONMENT VARIABLES section
       and  the	 Base  Definitions  volume of IEEE Std 1003.1-2001, Chapter 8,
       Environment Variables.

   wrapscan, ws
       [Default set]

       If wrapscan is set, searches (the ex / or ?   addresses,	 or  open  and
       visual mode /, ?, N, and n commands) shall wrap around the beginning or
       end of the edit buffer; when unset, searches shall stop at  the	begin‐
       ning or end of the edit buffer.

   writeany, wa
       [Default unset]

       If  writeany is set, some of the checks performed when executing the ex
       write commands shall  be	 inhibited,  as	 described  in	editor	option
       autowrite.

EXIT STATUS
       The following exit values shall be returned:

	0     Successful completion.

       >0     An error occurred.

CONSEQUENCES OF ERRORS
       When  any error is encountered and the standard input is not a terminal
       device file, ex shall not write the file or return to command  or  text
       input mode, and shall terminate with a non-zero exit status.

       Otherwise,  when	 an  unrecoverable  error  is encountered, it shall be
       equivalent to a SIGHUP asynchronous event.

       Otherwise, when an error is encountered, the  editor  shall  behave  as
       specified in Command Line Parsing in ex .

       The following sections are informative.

APPLICATION USAGE
       If  a  SIGSEGV  signal  is received while ex is saving a file, the file
       might not be successfully saved.

       The next command can accept more than one file, so usage such as:

	      next `ls [abc]*`

       is valid; it would not be valid for the	edit  or  read	commands,  for
       example,	 because  they	expect	only  one file and unspecified results
       occur.

EXAMPLES
       None.

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 freely redis‐
       tributable   implementation   of	  ex/	vi,    which	is    tracking
       IEEE Std 1003.1-2001  fairly  closely,  and  demonstrates  the intended
       changes between historical  implementations  and	 IEEE Std 1003.1-2001,
       may be obtained by anonymous FTP from:

	      ftp://ftp.rdg.opengroup.org/pub/mirrors/nvi

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

       It is recognized that ex visual mode and related features would be dif‐
       ficult, 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  exe‐
       cuted  from  the last line of the edit buffer. This meant, for example,
       that "+/pattern"	 would	fail  unless  the  wrapscan  option  was  set.
       IEEE Std 1003.1-2001  requires conformance to historical practice. His‐
       torically, some implementations restricted the ex commands  that	 could
       be  listed  as  part  of	 the  command line arguments. For consistency,
       IEEE Std 1003.1-2001 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 vari‐
       able.  Some  implementations, however, have not followed this semantic,
       and readonly does not permit  appending	either.	  IEEE Std 1003.1-2001
       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 his‐
       torical 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
       IEEE Std 1003.1-2001 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	 util‐
       ity.  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 crypto‐
       graphic 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 com‐
       mand.

       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 rea‐
       sonable restriction on portable usage of ex and to aid test suite writ‐
       ers 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 contain‐
       ing  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. IEEE Std 1003.1-2001 permits, but does not require,  this	behav‐
       ior.  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. IEEE Std 1003.1-2001 requires that SIGINT  behave  identically  to
       <ESC>, and that the terminal not be alerted.

       Historically, suspending the ex editor during text input mode was simi‐
       lar to SIGINT, as completed lines were retained, but any	 partial  line
       discarded,    and    the	   editor    returned	 to    command	 mode.
       IEEE Std 1003.1-2001 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 implemen‐
       tations of the UNIX curses package are not reentrant, and  the  receipt
       of   SIGTSTP   at   the	 wrong	 time	will   cause  them  to	crash.
       IEEE Std 1003.1-2001 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.	IEEE Std 1003.1-2001  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. Diagnos‐
       tic 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 argu‐
       ment, 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	previ‐
	   ous current pathname, if there was one.

	2. In the case of the file read/write forms of the read and write com‐
	   mands, 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 argu‐
	   ment.

       For example, :edit foo and :recover foo, when successful, set the  cur‐
       rent  pathname,	and,  if  there	 was  a previous current pathname, the
       alternate pathname. The commands :write, !command, and :edit  set  nei‐
       ther  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 cur‐
       rent  pathname  to their file arguments. The alternate pathname was not
       historically set by the :source command. IEEE Std 1003.1-2001  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.
       IEEE Std 1003.1-2001 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 prob‐
       lem because it is possible to put normal UNIX system commands inside  a
       .exrc  file.   IEEE Std 1003.1-2001  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
       IEEE Std 1003.1-2001  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.

       IEEE Std 1003.1-2001  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 IEEE Std 1003.1-2001.	 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. IEEE Std 1003.1-2001 requires that any ex com‐
       mand  be permitted in the EXINIT variable and .exrc files, for simplic‐
       ity of specification and consistency, although many of them will	 obvi‐
       ously 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 initializa‐
       tion 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	 spec‐
       ify  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 +  com‐
       mand; 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.
       IEEE Std 1003.1-2001 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
       IEEE Std 1003.1-2001;  however,	implementations are encouraged to pro‐
       vide 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
       IEEE Std 1003.1-2001;  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.	IEEE Std 1003.1-2001 requires  confor‐
       mance  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>-]. His‐
       torically, reading a file into an edit buffer did not cause the -c com‐
       mand  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, IEEE Std 1003.1-2001 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 speci‐
       fication,  IEEE Std 1003.1-2001	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  com‐
       mand  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 sim‐
       plicity	of  specification,  IEEE Std 1003.1-2001  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  IEEE Std 1003.1-2001, mostly because nobody can
       remember whether they ever did anything different historically.

       Historically, ex and vi permitted an address of zero for	 several  com‐
       mands,  and permitted the % address in empty files for others. For con‐
       sistency, IEEE Std 1003.1-2001 requires support for the former  in  the
       few commands where it makes sense, and disallows it otherwise. In addi‐
       tion, because IEEE Std 1003.1-2001 requires that % be logically equiva‐
       lent 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, IEEE Std 1003.1-2001
       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  com‐
       mand 3;/foo/;+2print will display the first line after line 3 that con‐
       tains 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>s; for example, 3 - 5p wrote the seventh line
       of the file, and /foo/ 5 was the same as /foo/+5. However,  only	 abso‐
       lute  values  could  be	added;	for  example,  5 /foo/	was  an error.
       IEEE Std 1003.1-2001  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,
       IEEE Std 1003.1-2001  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. IEEE Std 1003.1-2001 does not	 require  or  prohibit
       this behavior.

       Historically,  the  enhancements	 to basic regular expressions could be
       used  in	  addressing;	for   example,	 '~',	'\<',	and   '\>'   .
       IEEE Std 1003.1-2001  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.  IEEE Std 1003.1-2001  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	 func‐
       tionality is obscure, at best.) Historical implementations will require
       changes in order to comply with	IEEE Std 1003.1-2001;  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>s (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.	  IEEE Std 1003.1-2001
       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 exam‐
       ple, 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. IEEE Std 1003.1-2001 requires  the  vi
       behavior;  that	is, a single default command and line number increment
       for each command separator, and trailing <newline>s 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.
       IEEE Std 1003.1-2001  generalizes  this	to  require that any number of
       leading colon characters be stripped.

       Historically, any prefix of the delete command could be followed	 with‐
       out  intervening	 <blank>s  by  a flag character because in the command
       d p, p is interpreted as the buffer  p.	IEEE Std 1003.1-2001  requires
       conformance to historical practice.

       Historically,  the k command could be followed by the mark name without
       intervening <blank>s.   IEEE Std 1003.1-2001  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 com‐
       mands sp and s l would fail, while the command sgp and s gl would  suc‐
       ceed.  (Obviously, the '#' flag character was used as a delimiter char‐
       acter if it followed the command.)  Another issue was that option char‐
       acters  had  to precede flag characters even when the command was fully
       specified; for example, the command s/e/E/pg would fail, while the com‐
       mand  s/e/E/gp would succeed. IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001 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 multi‐
       ple 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,  IEEE Std 1003.1-2001  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 '!'	 char‐
       acter,  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 pro‐
       vided a cleaner presentation of the lines in the	 file  for  the	 user.
       IEEE Std 1003.1-2001  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 com‐
       mand, 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. IEEE Std 1003.1-2001 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 exe‐
       cution of their associated commands. Because this would almost  invari‐
       ably  result in catastrophic failure of the editor, and implementations
       exist that do exhibit  these  problems,	IEEE Std 1003.1-2001  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 simultane‐
       ously are strongly encouraged to apply the same semantics to  switching
       between buffers as well.

       The  ex	command quoting required by IEEE Std 1003.1-2001 is a superset
       of the quoting in historical implementations of the editor.  For	 exam‐
       ple,  it	 was  not historically possible to escape a <blank> in a file‐
       name; for example, :edit foo\\\ bar would report that  too  many	 file‐
       names 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  vis‐
       ual  command  at all. IEEE Std 1003.1-2001 extends historical practice,
       requiring that quoting behavior be made consistent across all  ex  com‐
       mands,  except  for  the	 map, unmap, abbreviate, and unabbreviate com‐
       mands, which historically used <control>-V instead of  backslashes  for
       quoting.	  For  those four commands, IEEE Std 1003.1-2001 requires con‐
       formance 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 back‐
       slash is usually one of the characters that causes shell	 expansion  to
       be performed, and therefore shell quoting rules must be taken into con‐
       sideration.  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 <con‐
       trol>-V	whether	 it   would   have   a	 special   meaning   or	  not.
       IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001 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>s in ex commands was  handled  inconsis‐
       tently.	In  most  cases,  the <newline> always terminated the command,
       regardless of any preceding escape character, because backslash charac‐
       ters  did  not escape <newline>s for most ex commands. However, some ex
       commands (for example, s, map, and abbreviation)	 permitted  <newline>s
       to  be  escaped	(although  in  the case of map and abbreviation, <con‐
       trol>-V characters escaped them instead of backslashes). 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	 <con‐
       trol>-V and the inserted <newline> passed to the ex parser. For consis‐
       tency and simplicity of	specification,	IEEE Std 1003.1-2001  requires
       that  it	 be possible to escape <newline>s in ex commands at all times,
       using backslashes for most ex commands, and using  <control>-V  charac‐
       ters  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,
       IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001  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,
       IEEE Std 1003.1-2001  requires  that  ex be implemented using canonical
       mode input processing, as was done historically.

       IEEE Std 1003.1-2001 does not require the historical 4 BSD input	 edit‐
       ing  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  implementa‐
       tions that rely on the underlying system terminal support for this pro‐
       cessing, are both conforming. Implementations are strongly urged to use
       the  underlying	system functionality, if at all possible, for compati‐
       bility with other system text input interfaces.

       Historically, when the eof character was used to decrement the  autoin‐
       dent  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. IEEE Std 1003.1-2001 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.

       IEEE Std 1003.1-2001 does not require the historical 4 BSD input	 edit‐
       ing  character  "reprint", traditionally <control>-R, which redisplayed
       the current input from the user. For this reason, and because the func‐
       tionality  cannot  be implemented after the line has been terminated by
       the user, IEEE Std 1003.1-2001 makes no requirements about  this	 func‐
       tionality.  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. IEEE Std 1003.1-2001 requires conformance to his‐
       torical practice to avoid breaking  historical  ex  scripts  and	 .exrc
       files.

   eof
       Whether	the  eof character immediately modifies the autoindent charac‐
       ters in the prompt is left unspecified so that implementations can con‐
       form 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).
       IEEE Std 1003.1-2001  requires this behavior for such commands and dis‐
       allows 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  suc‐
       ceed.   IEEE Std 1003.1-2001  requires  conformance to historical prac‐
       tice.

       Historically, the use of flags in ex commands could be  obscure.	  Gen‐
       eral  historical practice was as described by IEEE Std 1003.1-2001, 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	execu‐
       tion  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 consis‐
       tency and simplicity of specification,  IEEE Std 1003.1-2001  does  not
       permit any of these exceptions to the general rule.

       IEEE Std 1003.1-2001  uses  the	word  copy in several places when dis‐
       cussing 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.  IEEE Std 1003.1-2001
       requires	 conformance  to  historical practice by default, but does not
       preclude extensions.

       Historically, the contents of the unnamed buffer were  frequently  dis‐
       carded  after  commands that did not explicitly affect it; for example,
       when using the edit command to switch files. For consistency  and  sim‐
       plicity	of  specification,  IEEE Std 1003.1-2001  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.	IEEE Std 1003.1-2001  requires
       conformance  to	historical  practice. Numeric buffers are described in
       the ex utility in order to confine the description of buffers to a sin‐
       gle location in IEEE Std 1003.1-2001.

       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 com‐
       mand requires only a single line of the	screen.	  IEEE Std 1003.1-2001
       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. IEEE Std 1003.1-2001 requires conformance  to  his‐
       torical	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>s, 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 char‐
       acters  (or  vice  versa)  other than between the last and next-to-last
       characters in the lhs, and there can be no  <blank>s  in	 the  lhs.  In
       addition, because of the historical quoting rules, it was impossible to
       enter a literal <control>-V in the lhs.	IEEE Std 1003.1-2001  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
       IEEE Std 1003.1-2001. 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 IEEE Std 1003.1-2001  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 com‐
       mand. IEEE Std 1003.1-2001 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.	 IEEE Std 1003.1-2001 requires confor‐
       mance to historical practice, but disallows  the	 historical  need  for
       multiple terminating lines.

   Change
       See  the RATIONALE for the append command. Historical practice for cur‐
       sor positioning after the change command when no text is input,	is  as
       described in IEEE Std 1003.1-2001. 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.	 IEEE Std 1003.1-2001 disallows this modification for  consis‐
       tency.

       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
       IEEE Std 1003.1-2001.

   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-sepa‐
       rated.  The initial value of the cdpath edit option is the value of the
       shell  CDPATH  environment  variable.  This feature was not included in
       IEEE Std 1003.1-2001 because it does not exist in any of the  implemen‐
       tations 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.
       IEEE Std 1003.1-2001 requires conformance to historical practice.

   Delete
       IEEE Std 1003.1-2001  requires  support for the historical parsing of a
       delete command followed by flags, without any intervening <blank>s. 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,  IEEE Std 1003.1-2001  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 com‐
       mand  was  executed  from  visual  mode	or  not.  IEEE Std 1003.1-2001
       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,  IEEE Std 1003.1-2001 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,
       IEEE Std 1003.1-2001  does  not permit this usage to fail for that rea‐
       son.

       Historically, only the cursor position of  the  last  file  edited  was
       remembered  by  the  editor. IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001  does not permit this discrepancy, instead requir‐
       ing 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.	 IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001  requires  this  behavior.	Historically, entering
       <control>-V as the first character of a vi command was an error.	  Sev‐
       eral  implementations have extended the semantics of vi such that <con‐
       trol>-V means that the subsequent command character is not mapped. This
       is  permitted,  but  not required, by IEEE Std 1003.1-2001. 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. IEEE Std 1003.1-2001 requires conformance to historical
       practice.

       Historical implementations permitted digits to be used as a map command
       lhs,  but then ignored the map.	IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001.

       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.  IEEE Std 1003.1-2001 requires con‐
       formance 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 com‐
       mands.	See   the   RATIONALE	for   the   ex	 abbreviate   command.
       IEEE Std 1003.1-2001  requires  similar modification of some historical
       practice for the map and unmap commands, as described for the  abbrevi‐
       ate 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,
       IEEE Std 1003.1-2001  requires  that  the shortest match be used at all
       times.

       The length of time the editor spends waiting for the characters to com‐
       plete 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 pre‐
       vious context marks were not set if the command, with which the address
       setting	the mark was associated, failed. IEEE Std 1003.1-2001 requires
       conformance to historical practice. Historically, if marked lines  were
       deleted,	 the  mark  was also deleted, but would reappear if the change
       was undone. IEEE Std 1003.1-2001	 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.  IEEE Std 1003.1-2001
       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 exam‐
       ple, 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, IEEE Std 1003.1-2001 does not permit this behav‐
       ior.

       Historically, the next command positioned the cursor as if the file had
       never  been  edited  before, regardless.	 IEEE Std 1003.1-2001 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. IEEE Std 1003.1-2001 does not require this com‐
       mand.

   Open
       Historically,  the  open command would fail if the open edit option was
       not set. IEEE Std 1003.1-2001 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, IEEE Std 1003.1-2001 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 consis‐
       tency, IEEE Std 1003.1-2001 does not permit this behavior.

       Historically, the open command only permitted '/' characters to be used
       as  the search pattern delimiter. For consistency, IEEE Std 1003.1-2001
       requires that the search delimiters used by the s, global, and  v  com‐
       mands be accepted as well.

   Preserve
       The preserve command does not historically cause the file to be consid‐
       ered unmodified for the purposes of future commands that may  exit  the
       editor.	IEEE Std 1003.1-2001  requires conformance to historical prac‐
       tice.

       Historical documentation stated that mail was not sent to the user when
       preserve	 was  executed;	 however,  historical implementations did send
       mail in this case. IEEE Std 1003.1-2001	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 sup‐
       port  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	 stan‐
       dard.   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 IEEE Std 1003.1-2001.

       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.
       IEEE Std 1003.1-2001 permits, but does  not  require,  this  historical
       practice	 because capital forms of the commands are used by some imple‐
       mentations 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	 (sup‐
       posed) contents of the buffer. For consistency and simplicity of speci‐
       fication, IEEE Std 1003.1-2001 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,
       IEEE Std 1003.1-2001  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, IEEE Std 1003.1-2001 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,
       IEEE Std 1003.1-2001 does not permit this behavior.

       Historically, the ex and vi message after a successful  read  or	 write
       command	 specified  "characters",  not	"bytes".  IEEE Std 1003.1-2001
       requires that the number of bytes be displayed, not the number of char‐
       acters,	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 regu‐
       lar, except that FIFO files could be read (probably only	 because  they
       did not exist when ex and vi were originally written). Because the his‐
       torical ex evaluated read! and read ! equivalently,  there  can	be  no
       optional way to force the read.	IEEE Std 1003.1-2001 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  IEEE Std 1003.1-2001	 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. IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001. Historically, the c and g  options  were  tog‐
       gled;   for   example,	the   command  :s/abc/def/  was	 the  same  as
       s/abc/def/ccccgggg.     For	simplicity	of	specification,
       IEEE Std 1003.1-2001 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

       IEEE Std 1003.1-2001 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 specifica‐
       tion, IEEE Std 1003.1-2001 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.  IEEE Std 1003.1-2001 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 mul‐
       tiple 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,
       IEEE Std 1003.1-2001 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 nec‐
       essary  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, IEEE Std 1003.1-2001 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.  IEEE Std 1003.1-2001  considers this a bug, and implementations
       are required to search for the first occurrence in  the	file,  regard‐
       less.

   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 his‐
       torical vi, sometimes attempting to restore the original	 cursor	 posi‐
       tion ( 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. IEEE Std 1003.1-2001 requires a simplified behavior for con‐
       sistency 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 con‐
       tain. Implementations are encouraged to do something reasonably	intel‐
       ligent.

   Write
       Historically,  the  ex  and vi message after a successful read or write
       command	specified  "characters",  not  "bytes".	  IEEE Std 1003.1-2001
       requires that the number of bytes be displayed, not the number of char‐
       acters because it may be difficult  in  multi-byte  implementations  to
       determine the number of characters written. Implementations are encour‐
       aged 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 IEEE Std 1003.1-2001 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.	 IEEE Std 1003.1-2001  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  per‐
       formed.	This  could disturb the terminal configuration as well as be a
       security issue for some terminals.  IEEE Std 1003.1-2001 does not  per‐
       mit  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, IEEE Std 1003.1-2001 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  distin‐
       guished	from  a	 flag.	(The commands z\fP.  and z = were historically
       invalid.) IEEE Std 1003.1-2001 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  permit‐
       ted by IEEE Std 1003.1-2001.

   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.
       IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001; implementations are encouraged
       to provide it if possible.  Historically, the <control>-D command took,
       and then ignored, a count.  IEEE Std 1003.1-2001 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, IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001 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 exe‐
       cuted; that is, buffer execution did not support	 self-modifying	 code.
       IEEE Std 1003.1-2001 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 spec‐
       ified  line.  IEEE Std 1003.1-2001  requires  conformance to historical
       practice.

       Some historical implementations did not notice if errors occurred  dur‐
       ing 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.   IEEE Std 1003.1-2001  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 reg‐
       ular 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.
       IEEE Std 1003.1-2001 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
       IEEE Std 1003.1-2001.  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
	      IEEE Std 1003.1-2001  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
	      IEEE Std 1003.1-2001 because it is not found in some  historical
	      implementations.

       hardtabs
	      The hardtabs edit option historically defined the number of col‐
	      umns between hardware tab settings. This option was omitted from
	      IEEE Std 1003.1-2001  because  it	 was  believed to no longer be
	      generally useful.

       modeline
	      The modeline (sometimes named modelines)	edit  option  histori‐
	      cally  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 com‐
	      mands are required by IEEE Std 1003.1-2001.

       optimize
	      The optimize edit option historically expedited text  throughput
	      by  setting  the terminal to not do automatic <carriage-return>s
	      when printing more than one logical line of output.  This option
	      was  omitted  from  IEEE Std 1003.1-2001 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 IEEE Std 1003.1-2001 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 run‐
	      ning 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
	      IEEE Std 1003.1-2001 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
	      IEEE Std 1003.1-2001  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  IEEE Std 1003.1-2001 because it is not wide‐
	      spread 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.	IEEE Std 1003.1-2001  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 auto‐
       print. IEEE Std 1003.1-2001 requires conformance	 to  historical	 prac‐
       tice.

       Historically, the autoprint option only applied to the last of multiple
       commands entered using vertical-bar  delimiters;	 for  example,	delete
       <newline>  was  affected by autoprint, but delete|version <newline> was
       not.  IEEE Std 1003.1-2001 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.
       IEEE Std 1003.1-2001 requires that the behavior match the other ex com‐
       mands for consistency.

   ignorecase, ic
       Historical implementations of case-insensitive matching (the ignorecase
       edit option) lead to counterintuitive situations when uppercase charac‐
       ters  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,
       IEEE Std 1003.1-2001 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.  IEEE Std 1003.1-2001
       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  con‐
       tents  of the edit buffer were replaced. This behavior is disallowed by
       IEEE Std 1003.1-2001.

   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.
       IEEE Std 1003.1-2001 extends historical practice by requiring that buf‐
       fer 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 inex‐
       act and variable. The time should  be  long  enough  for	 the  user  to
       notice, but not long enough for the user to become annoyed. Some imple‐
       mentations of vi have added a matchtime option that  permits  users  to
       set  the number of 0,1 second intervals the cursor pauses on the match‐
       ing 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 use‐
       ful,   particularly   to	  novice   users,   and	  is	required    by
       IEEE Std 1003.1-2001.

       The  smd	 shorthand for the showmode option was not present in all his‐
       torical implementations of the editor.	IEEE Std 1003.1-2001  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. IEEE Std 1003.1-2001 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 over‐
       written. 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.	IEEE Std 1003.1-2001 permits most his‐
       torical 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 IEEE Std 1003.1-2001; however, implementations are encour‐
       aged 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 IEEE Std 1003.1-2001.  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
       IEEE Std 1003.1-2001 because  of	 their	dependence  on	specific  baud
       rates.

       In historical implementations, the size of the window displayed by var‐
       ious commands was related to, but not necessarily the same as, the win‐
       dow  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.   IEEE Std 1003.1-2001  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 char‐
       acters  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, IEEE Std 1003.1-2001
       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>s 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.
       IEEE Std 1003.1-2001 requires conformance to historical practice.

FUTURE DIRECTIONS
       None.

SEE ALSO
       Command Search and Execution, ctags, ed, sed, sh, stty, vi, the	System
       Interfaces volume of IEEE Std 1003.1-2001, access()

COPYRIGHT
       Portions	 of  this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
       --  Portable  Operating	System	Interface (POSIX), The Open Group Base
       Specifications Issue 6, Copyright (C) 2001-2003	by  the	 Institute  of
       Electrical  and	Electronics  Engineers, Inc and The Open Group. In the
       event of any discrepancy between this version and the original IEEE and
       The  Open Group Standard, the original IEEE and The Open Group Standard
       is the referee document. The original Standard can be  obtained	online
       at http://www.opengroup.org/unix/online.html .

IEEE/The Open Group		     2003				EX(1P)
[top]

List of man pages available for RedHat

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net