1 # @(#)POSIX 8.1 (Berkeley) 6/6/93
4 Comments on the IEEE P1003.2 Draft 12
5 Part 2: Shell and Utilities
6 Section 4.55: sed - Stream editor
8 Diomidis Spinellis <dds@doc.ic.ac.uk>
9 Keith Bostic <bostic@cs.berkeley.edu>
11 In the following paragraphs, "wrong" usually means "inconsistent with
12 historic practice", as most of the following comments refer to
13 undocumented inconsistencies between the historical versions of sed and
14 the POSIX 1003.2 standard. All the comments are notes taken while
15 implementing a POSIX-compatible version of sed, and should not be
16 interpreted as official opinions or criticism towards the POSIX committee.
17 All uses of "POSIX" refer to section 4.55, Draft 12 of POSIX 1003.2.
19 1. 32V and BSD derived implementations of sed strip the text
20 arguments of the a, c and i commands of their initial blanks,
35 POSIX does not specify this behavior as the System V versions of
36 sed do not do this stripping. The argument against stripping is
37 that it is difficult to write sed scripts that have leading blanks
38 if they are stripped. The argument for stripping is that it is
39 difficult to write readable sed scripts unless indentation is allowed
40 and ignored, and leading whitespace is obtainable by entering a
41 backslash in front of it. This implementation follows the BSD
44 2. Historical versions of sed required that the w flag be the last
45 flag to an s command as it takes an additional argument. This
46 is obvious, but not specified in POSIX.
48 3. Historical versions of sed required that whitespace follow a w
49 flag to an s command. This is not specified in POSIX. This
50 implementation permits whitespace but does not require it.
52 4. Historical versions of sed permitted any number of whitespace
53 characters to follow the w command. This is not specified in
54 POSIX. This implementation permits whitespace but does not
57 5. The rule for the l command differs from historic practice. Table
58 2-15 includes the various ANSI C escape sequences, including \\
59 for backslash. Some historical versions of sed displayed two
60 digit octal numbers, too, not three as specified by POSIX. POSIX
61 is a cleanup, and is followed by this implementation.
63 6. The POSIX specification for ! does not specify that for a single
64 command the command must not contain an address specification
65 whereas the command list can contain address specifications. The
66 specification for ! implies that "3!/hello/p" works, and it never
67 has, historically. Note,
75 7. POSIX does not specify what happens with consecutive ! commands
76 (e.g. /foo/!!!p). Historic implementations allow any number of
77 !'s without changing the behaviour. (It seems logical that each
78 one might reverse the behaviour.) This implementation follows
81 8. Historic versions of sed permitted commands to be separated
82 by semi-colons, e.g. 'sed -ne '1p;2p;3q' printed the first
83 three lines of a file. This is not specified by POSIX.
84 Note, the ; command separator is not allowed for the commands
85 a, c, i, w, r, :, b, t, # and at the end of a w flag in the s
86 command. This implementation follows historic practice and
87 implements the ; separator.
89 9. Historic versions of sed terminated the script if EOF was reached
90 during the execution of the 'n' command, i.e.:
98 did not produce any output. POSIX does not specify this behavior.
99 This implementation follows historic practice.
103 11. Historical implementations do not output the change text of a c
104 command in the case of an address range whose first line number
105 is greater than the second (e.g. 3,1). POSIX requires that the
106 text be output. Since the historic behavior doesn't seem to have
107 any particular purpose, this implementation follows the POSIX
110 12. POSIX does not specify whether address ranges are checked and
111 reset if a command is not executed due to a jump. The following
112 program will behave in different ways depending on whether the
113 'c' command is triggered at the third line, i.e. will the text
114 be output even though line 3 of the input will never logically
115 encounter that command.
121 Historic implementations did not output the text in the above
122 example. Therefore it was believed that a range whose second
123 address was never matched extended to the end of the input.
124 However, the current practice adopted by this implementation,
125 as well as by those from GNU and SUN, is as follows: The text
126 from the 'c' command still isn't output because the second address
127 isn't actually matched; but the range is reset after all if its
128 second address is a line number. In the above example, only the
129 first line of the input will be deleted.
131 13. Historical implementations allow an output suppressing #n at the
132 beginning of -e arguments as well as in a script file. POSIX
133 does not specify this. This implementation follows historical
136 14. POSIX does not explicitly specify how sed behaves if no script is
137 specified. Since the sed Synopsis permits this form of the command,
138 and the language in the Description section states that the input
139 is output, it seems reasonable that it behave like the cat(1)
140 command. Historic sed implementations behave differently for "ls |
141 sed", where they produce no output, and "ls | sed -e#", where they
142 behave like cat. This implementation behaves like cat in both cases.
144 15. The POSIX requirement to open all w files at the beginning makes
145 sed behave nonintuitively when the w commands are preceded by
146 addresses or are within conditional blocks. This implementation
147 follows historic practice and POSIX, by default, and provides the
148 -a option which opens the files only when they are needed.
150 16. POSIX does not specify how escape sequences other than \n and \D
151 (where D is the delimiter character) are to be treated. This is
152 reasonable, however, it also doesn't state that the backslash is
153 to be discarded from the output regardless. A strict reading of
154 POSIX would be that "echo xyz | sed s/./\a" would display "\ayz".
155 As historic sed implementations always discarded the backslash,
156 this implementation does as well.
158 17. POSIX specifies that an address can be "empty". This implies
159 that constructs like ",d" or "1,d" and ",5d" are allowed. This
160 is not true for historic implementations or this implementation
163 18. The b t and : commands are documented in POSIX to ignore leading
164 white space, but no mention is made of trailing white space.
165 Historic implementations of sed assigned different locations to
166 the labels "x" and "x ". This is not useful, and leads to subtle
167 programming errors, but it is historic practice and changing it
168 could theoretically break working scripts. This implementation
169 follows historic practice.
171 19. Although POSIX specifies that reading from files that do not exist
172 from within the script must not terminate the script, it does not
173 specify what happens if a write command fails. Historic practice
174 is to fail immediately if the file cannot be opened or written.
175 This implementation follows historic practice.
177 20. Historic practice is that the \n construct can be used for either
178 string1 or string2 of the y command. This is not specified by
179 POSIX. This implementation follows historic practice.
183 22. Historic implementations of sed ignore the RE delimiter characters
184 within character classes. This is not specified in POSIX. This
185 implementation follows historic practice.
187 23. Historic implementations handle empty RE's in a special way: the
188 empty RE is interpreted as if it were the last RE encountered,
189 whether in an address or elsewhere. POSIX does not document this
190 behavior. For example the command:
194 substitutes XXX for the pattern abc. The semantics of "the last
195 RE" can be defined in two different ways:
197 1. The last RE encountered when compiling (lexical/static scope).
198 2. The last RE encountered while running (dynamic scope).
200 While many historical implementations fail on programs depending
201 on scope differences, the SunOS version exhibited dynamic scope
202 behaviour. This implementation does dynamic scoping, as this seems
203 the most useful and in order to remain consistent with historical