The initial description of this utility was adapted from the
SVID. It contains some features not found in Version 7 or BSD-
derived systems. Some of the differences between the POSIX and
BSD ed utilities include, but need not be limited to:
* The BSD - option does not suppress the '!' prompt after a !
command.
* BSD does not support the special meanings of the '%' and '!'
characters within a ! command.
* BSD does not support the addresses ';' and ','.
* BSD allows the command/suffix pairs pp, ll, and so on, which
are unspecified in this volume of POSIX.1‐2017.
* BSD does not support the '!' character part of the e, r, or
w commands.
* A failed g command in BSD sets the line number to the last
line searched if there are no matches.
* BSD does not default the command list to the p command.
* BSD does not support the G, h, H, n, or V commands.
* On BSD, if there is no inserted text, the insert command
changes the current line to the referenced line -1; that is,
the line before the specified line.
* On BSD, the join command with only a single address changes
the current line to that address.
* BSD does not support the P command; moreover, in BSD it is
synonymous with the p command.
* BSD does not support the undo of the commands j, m, r, s, or
t.
* The Version 7 ed command W, and the BSD ed commands W, wq,
and z are not present in this volume of POSIX.1‐2017.
The -s option was added to allow the functionality of the removed
- option in a manner compatible with the Utility Syntax
Guidelines.
In early proposals there was a limit, {ED_FILE_MAX}, that
described the historical limitations of some ed utilities in
their handling of large files; some of these have had problems
with files larger than 100000 bytes. It was this limitation that
prompted much of the desire to include a split command in this
volume of POSIX.1‐2017. Since this limit was removed, this volume
of POSIX.1‐2017 requires that implementations document the file
size limits imposed by ed in the conformance document. The limit
{ED_LINE_MAX} was also removed; therefore, the global limit
{LINE_MAX} is used for input and output lines.
The manner in which the l command writes non-printable characters
was changed to avoid the historical backspace-overstrike method.
On video display terminals, the overstrike is ambiguous because
most terminals simply replace overstruck characters, making the l
format not useful for its intended purpose of unambiguously
understanding the content of the line. The historical
<backslash>-escapes were also ambiguous. (The string "a\0011"
could represent a line containing those six characters or a line
containing the three characters 'a', a byte with a binary value
of 1, and a 1.) In the format required here, a <backslash>
appearing in the line is written as "\\" so that the output is
truly unambiguous. The method of marking the ends of lines was
adopted from the ex editor and is required for any line ending in
<space> characters; the '$' is placed on all lines so that a real
'$' at the end of a line cannot be misinterpreted.
Earlier versions of this standard allowed for implementations
with bytes other than eight bits, but this has been modified in
this version.
The description of how a NUL is written was removed. The NUL
character cannot be in text files, and this volume of
POSIX.1‐2017 should not dictate behavior in the case of
undefined, erroneous input.
Unlike some of the other editing utilities, the filenames
accepted by the E, e, R, and r commands are not patterns.
Early proposals stated that the -p option worked only when
standard input was associated with a terminal device. This has
been changed to conform to historical implementations, thereby
allowing applications to interpose themselves between a user and
the ed utility.
The form of the substitute command that uses the n suffix was
limited in some historical documentation (where this was
described incorrectly as ``backreferencing''). This limit has
been omitted because there is no reason why an editor processing
lines of {LINE_MAX} length should have this restriction. The
command s/x/X/2047 should be able to substitute the 2047th
occurrence of 'x' on a line.
The use of printing commands with printing suffixes (such as pn,
lp, and so on) was made unspecified because BSD-based systems
allow this, whereas System V does not.
Some BSD-based systems exit immediately upon receipt of end-of-
file if all of the lines in the file have been deleted. Since
this volume of POSIX.1‐2017 refers to the q command in this
instance, such behavior is not allowed.
Some historical implementations returned exit status zero even if
command errors had occurred; this is not allowed by this volume
of POSIX.1‐2017.
Some historical implementations contained a bug that allowed a
single <period> to be entered in input mode as <backslash>
<period> <newline>. This is not allowed by ed because there is
no description of escaping any of the characters in input mode;
<backslash> characters are entered into the buffer exactly as
typed. The typical method of entering a single <period> has been
to precede it with another character and then use the substitute
command to delete that character.
It is difficult under some modes of some versions of historical
operating system terminal drivers to distinguish between an end-
of-file condition and terminal disconnect. POSIX.1‐2008 does not
require implementations to distinguish between the two
situations, which permits historical implementations of the ed
utility on historical platforms to conform. Implementations are
encouraged to distinguish between the two, if possible, and take
appropriate action on terminal disconnect.
Historically, ed accepted a zero address for the a and r commands
in order to insert text at the start of the edit buffer. When the
buffer was empty the command .= returned zero. POSIX.1‐2008
requires conformance to historical practice.
For consistency with the a and r commands and better user
functionality, the i and c commands must also accept an address
of 0, in which case 0i is treated as 1i and likewise for the c
command.
All of the following are valid addresses:
+++ Three lines after the current line.
/pattern/- One line before the next occurrence of pattern.
-2 Two lines before the current line.
3 ---- 2 Line one (note the intermediate negative address).
1 2 3 Line six.
Any number of addresses can be provided to commands taking
addresses; for example, "1,2,3,4,5p" prints lines 4 and 5,
because two is the greatest valid number of addresses accepted by
the print command. This, in combination with the <semicolon>
delimiter, permits users to create commands based on ordered
patterns in the file. For example, the command "3;/foo/;+2p" will
display the first line after line 3 that contains the pattern
foo, plus the next two lines. Note that the address "3;" must
still be evaluated before being discarded, because the search
origin for the "/foo/" command depends on this.
Historically, ed disallowed address chains, as discussed above,
consisting solely of <comma> or <semicolon> separators; for
example, ",,," or ";;;" were considered an error. For consistency
of address specification, this restriction is removed. The
following table lists some of the address forms now possible:
┌────────┬───────┬───────┬────────────┬───────────────────────┐
│Address │ Addr1 │ Addr2 │ Status │ Comment │
├────────┼───────┼───────┼────────────┼───────────────────────┤
│7, │ 7 │ 7 │ Historical │ │
│7,5, │ 5 │ 5 │ Historical │ │
│7,5,9 │ 5 │ 9 │ Historical │ │
│7,9 │ 7 │ 9 │ Historical │ │
│7,+ │ 7 │ 8 │ Historical │ │
│, │ 1 │ $ │ Historical │ │
│,7 │ 1 │ 7 │ Extension │ │
│,, │ $ │ $ │ Extension │ │
│,; │ $ │ $ │ Extension │ │
│7; │ 7 │ 7 │ Historical │ │
│7;5; │ 5 │ 5 │ Historical │ │
│7;5;9 │ 5 │ 9 │ Historical │ │
│7;5,9 │ 5 │ 9 │ Historical │ │
│7;$;4 │ $ │ 4 │ Historical │ Valid, but erroneous. │
│7;9 │ 7 │ 9 │ Historical │ │
│7;+ │ 7 │ 8 │ Historical │ │
│; │ . │ $ │ Historical │ │
│;7 │ . │ 7 │ Extension │ │
│;; │ $ │ $ │ Extension │ │
│;, │ $ │ $ │ Extension │ │
└────────┴───────┴───────┴────────────┴───────────────────────┘
Historically, ed accepted the '^' character as an address, in
which case it was identical to the <hyphen-minus> character.
POSIX.1‐2008 does not require or prohibit this behavior.
