-18. Historical implementations allow an output suppressing #n at the
- beginning of -e arguments as well.
-
-19. POSIX does not specify whether more than one numeric flag is
- allowed on the s command
-
-20. Existing versions of sed have the undocumented feature of allowing
- a semicolon to delimit commands. It is not specified in the standard.
-
-21. The standard does not specify whether a script is mandatory. The
- sed implementations I tested behave differently with ls | sed (no
- output) and ls | sed - e'' (behaves like cat).
-
-22. 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.
-
-23. The rule specified in lines 11412-11413 of the standard does not
- seem consistent with existing practice. The 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.
-
-24. 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.
-
-25. The standard specifies in line 11304 that an address can be empty.
- This is wrong since it implied that constructs like ,d or 1,d or ,5d
- are allowed. The sed implementation I tested do not allow them.
-
-26. The b t and : commands ignore leading white space, but not trailing
- white space. This is not specified in the standard.
-
-27. Although the standard specifies that reading from files that do not
- exist from within the script must not terminate the script; it does not
- specify what happens if a write command fails.
-
-28. In the sed implementation I tested the \n construct for newlines
- works on both strings of a y command. This is not specified in the
- standard.
-
-29. The standard does not specify if the "nth occurrence" of a regular
- expression in a substitute command is an overlapping or a
- non-overlappoin one. I.e. what is the result of s/a*/A/2 on the
- pattern "aaaaa aaaaa". (It crashes the implementation of sed I
- tested.)
-
-30. Existing implementations of sed ignore the regular expression
- delimiter characters within character classes. This is not specified
- in the standard.
+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.
+
+25. The b t and : commands ignore leading white space, but not
+ trailing white space. This is not specified in the standard.
+
+TK I think that line 11347 points out the the synopsis shows
+TK which are valid.
+
+ Although the standard specifies that reading from files that
+ do not exist from within the script must not terminate the
+ script, it does not specify what happens if a write command
+ fails. Historic practice is to fail immediately if the file
+ cannot be open or written. This implementation follows that
+ practice.
+
+26. Historic practice is that the \n construct can be used for
+ either string1 or string2 of the y command. This is not
+ specified by the standard. This implementation follows
+ historic practice.
+
+29. The standard does not specify if the "nth occurrence" of a
+ regular expression in a substitute command is an overlapping
+ or a non-overlapping one, e.g. what is the result of s/a*/A/2
+ on the pattern "aaaaa aaaaa". Historical practice is to drop
+ core or do non-overlapping expressions. This implementation
+ follows historic practice.
+
+30. Historic implementations of sed ignore the regular expression
+ delimiter characters within character classes. This is not
+ specified in the standard. This implementation follows historic
+ practice.
projects / unix-history / commitdiff