-13. Historic implementations ignore comments in the text of the i
- and a commands. This implementation follows historic practice.
-
-14. Historic implementations do not consider the last line of a
- file to match $ if an empty file follows, e.g.
-
- sed -n -e '$p' /usr/dict/words /dev/null
-
- will not print anything. This is not mentioned in the POSIX
- specification and is almost certainly a bug. This implementation
- follows the POSIX specification.
-
-TK Diomidis, I think we need to fix this, can you do it?
-DDS We follow POSIX. You don't mean to do it buggy?
-TK I see... (I didn't understand that problem until now.) I think
-TK that we *should* print out the last line of the dictionary, in
-TK the above example, but I can see how it would be hard. What do
-TK you think?
-
-15. Historical implementations do not output the change text
- of a c command in the case of an address range whose second
- line number is greater than the first (e.g. 3,1). The POSIX
- standard requires that the text be output. Since the historic
- behavior doesn't seem to have any particular purpose, this
- implementation follows the POSIX behavior.
-
-16. Historical implementations output the c text on EVERY line not
- included in the two address range in the case of a negation '!'.
-
-TK Diomidis, this seems reasonable, I don't see where the standard
-TK conflicts with this.
-
-17. The standard does not specify that the p flag at the s command will
- write the pattern space plus a newline on the standard output
-
-TK I think this is covered by the general language aruond 11293
-TK that says that the pattern space is always followed by a newline
-TK when output.
-
-18. The standard does not specify whether address ranges are
- checked and reset if a command is not executed due to a
- jump. The following program can behave in two different
- ways depending on whether the range operator is reset at
- line 6 or not. This is important in the case of pattern
- matches.
-
- sed -n -e '
- 4,8b
- s/^/XXX/p
- 1,6 {
- p
- }'
-
-TK I don't understand this -- can you explain further?
-DDS The 1,6 operator will not be executed on line 6 (due to the 4,8b
-DDS line) and thus it will not clear. In this case you can check for
-DDS line > 6 in apply, but what if the 1,6 was /BEGIN/,/END/
-TK OK, I understand, now. Well, I think I do, anyhow. It seems to
-TK me that applies() will never see the 1,6 line under any circumstances
-TK (even if it was /BEGIN/,/END/ because for lines 4 through 8.
-TK A nastier example, as you point out, is:
-TK 2,4b
-TK /one/,/three/c\
-TK append some text
-TK
-TK The BSD sed appends the text after the "branch" no longer applies,
-TK i.e. with the input: one\ntwo\nthree\nfour\nfive\nsix it displays
-TK two\nthree\nfour\nappend some text BUT THEN IT STOPS!
-TK Our sed, of course, simply never outputs "append some text". It
-TK seems to me that our current approach is "right", because it would
-TK be possible to have:
-TK 1,4b
-TK /one/,/five/c\
-TK message
-TK
-TK where you only want to see "message" if the patterns "one" ... "five"
-TK occur, but not in lines 1 to 4. What do you think?
-
-18. Historical implementations allow an output suppressing #n at the
- beginning of -e arguments as well. This implementation follows
- historical practice.
-
-19. POSIX does not specify whether more than one numeric flag is
- allowed on the s command
-
-TK What's historic practice? Currently we don't report an error or
- do all of the flags.
-
-20. The standard does not specify whether a script is mandatory.
- Historic sed implementations behave differently with ls | sed
- (no output) and ls | sed - e'' (behaves like cat).
-
-TK I don't understand what 'sed - e' does (it should be illegal,
-TK right?) It seems to me that a script should be mandatory,
-TK and sed should fail with an error if not given one.
-
-21. The requirement to open all wfiles from the beginning makes sed
- behave nonintuitively when the w commands are preceded by addresses
- or are within conditional blocks. This implementation follows
- historic practice, by default, and provides a flag for more
- reasonable behavior.
-
-TK I'll put it on my TODO list... ;-}
-
-22. The rule specified in lines 11412-11413 of the standard does
- not seem consistent with existing practice. Historic sed
- implementations I tested copied the rfile on standard output
- every time the r command was executed and not before reading
- a line of input. The wording should be changed to be
- consistent with the 'a' command i.e.
-
-TK Something got dropped, here... Can you explain furtehr what
-TK historic versoins did, what they should do, what we do?
-
-23. The standard does not specify how excape sequences other
- than \n and \D (where D is the delimiter character) are to
- be treated. A strict interpretation would be that they
- should be treated literaly. In the sed implementations I
- have tried the \ is simply ingored.
-
-TK I don't understand what you're saying, here. Can you explain?
-
-24. The standard specifies that an address can be "empty". This
- implies that constructs like ,d or 1,d and ,5d are allowed.
- This is not true for historic implementations of sed. This
- implementation follows historic practice.
projects / unix-history / blobdiff