Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
# SUSv3 compliant sed tests.
|
|
|
|
# Copyright 2005 by Rob Landley <rob@landley.net>
|
2010-08-16 23:44:46 +05:30
|
|
|
# Licensed under GPLv2, see file LICENSE in this source tree.
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
2009-11-05 05:11:22 +05:30
|
|
|
. ./testing.sh
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
2011-08-16 16:59:34 +05:30
|
|
|
# testing "description" "commands" "result" "infile" "stdin"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
|
|
|
# Corner cases
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed no files (stdin)" 'sed ""' "hello\n" "" "hello\n"
|
|
|
|
testing "sed explicit stdin" 'sed "" -' "hello\n" "" "hello\n"
|
|
|
|
testing "sed handles empty lines" "sed -e 's/\$/@/'" "@\n" "" "\n"
|
|
|
|
testing "sed stdin twice" 'sed "" - -' "hello" "" "hello"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
|
|
|
# Trailing EOF.
|
|
|
|
# Match $, at end of each file or all files?
|
2006-03-01 22:02:01 +05:30
|
|
|
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
# -e corner cases
|
|
|
|
# without -e
|
|
|
|
# multiple -e
|
|
|
|
# interact with a
|
|
|
|
# -eee arg1 arg2 arg3
|
|
|
|
# -f corner cases
|
|
|
|
# -e -f -e
|
|
|
|
# -n corner cases
|
|
|
|
# no newline at EOF?
|
|
|
|
# -r corner cases
|
|
|
|
# Just make sure it works.
|
|
|
|
# -i corner cases:
|
|
|
|
# sed -i -
|
|
|
|
# permissions
|
|
|
|
# -i on a symlink
|
|
|
|
# on a directory
|
2006-03-01 22:02:01 +05:30
|
|
|
# With $ last-line test
|
|
|
|
# Continue with \
|
|
|
|
# End of script with trailing \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
|
|
|
# command list
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed accepts blanks before command" "sed -e '1 d'" "" "" ""
|
|
|
|
testing "sed accepts newlines in -e" "sed -e 'i\
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
1
|
|
|
|
a\
|
|
|
|
3'" "1\n2\n3\n" "" "2\n"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed accepts multiple -e" "sed -e 'i\' -e '1' -e 'a\' -e '3'" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"1\n2\n3\n" "" "2\n"
|
|
|
|
|
|
|
|
# substitutions
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed -n" "sed -n -e s/foo/bar/ -e s/bar/baz/" "" "" "foo\n"
|
2012-04-24 22:51:16 +05:30
|
|
|
testing "sed with empty match" "sed 's/z*//g'" "string\n" "" "string\n"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed s//p" "sed -e s/foo/bar/p -e s/bar/baz/p" "bar\nbaz\nbaz\n" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"" "foo\n"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed -n s//p" "sed -ne s/abc/def/p" "def\n" "" "abc\n"
|
2009-07-18 19:52:26 +05:30
|
|
|
test x"$SKIP_KNOWN_BUGS" = x"" && {
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed s//g (exhaustive)" "sed -e 's/[[:space:]]*/,/g'" ",1,2,3,4,5,\n" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"" "12345\n"
|
2009-07-18 19:52:26 +05:30
|
|
|
}
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed s arbitrary delimiter" "sed -e 's woo boing '" "boing\n" "" "woo\n"
|
|
|
|
testing "sed s chains" "sed -e s/foo/bar/ -e s/bar/baz/" "baz\n" "" "foo\n"
|
|
|
|
testing "sed s chains2" "sed -e s/foo/bar/ -e s/baz/nee/" "bar\n" "" "foo\n"
|
|
|
|
testing "sed s [delimiter]" "sed -e 's@[@]@@'" "onetwo" "" "one@two"
|
2007-11-13 22:18:10 +05:30
|
|
|
testing "sed s with \\t (GNU ext)" "sed 's/\t/ /'" "one two" "" "one\ttwo"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
|
|
|
# branch
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed b (branch)" "sed -e 'b one;p;: one'" "foo\n" "" "foo\n"
|
|
|
|
testing "sed b (branch with no label jumps to end)" "sed -e 'b;p'" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"foo\n" "" "foo\n"
|
|
|
|
|
|
|
|
# test and branch
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed t (test/branch)" "sed -e 's/a/1/;t one;p;: one;p'" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"1\n1\nb\nb\nb\nc\nc\nc\n" "" "a\nb\nc\n"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed t (test/branch clears test bit)" "sed -e 's/a/b/;:loop;t loop'" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"b\nb\nc\n" "" "a\nb\nc\n"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed T (!test/branch)" "sed -e 's/a/1/;T notone;p;: notone;p'" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"1\n1\n1\nb\nb\nc\nc\n" "" "a\nb\nc\n"
|
|
|
|
|
2009-07-18 19:52:26 +05:30
|
|
|
test x"$SKIP_KNOWN_BUGS" = x"" && {
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
# Normal sed end-of-script doesn't print "c" because n flushed the pattern
|
|
|
|
# space. If n hits EOF, pattern space is empty when script ends.
|
|
|
|
# Query: how does this interact with no newline at EOF?
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed n (flushes pattern space, terminates early)" "sed -e 'n;p'" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"a\nb\nb\nc\n" "" "a\nb\nc\n"
|
2009-07-18 19:52:26 +05:30
|
|
|
}
|
2010-08-16 19:56:33 +05:30
|
|
|
# non-GNU sed: N does _not_ flush pattern space, therefore c is eaten @ script end
|
|
|
|
# GNU sed: N flushes pattern space, therefore c is printed too @ script end
|
|
|
|
testing "sed N (flushes pattern space (GNU behavior))" "sed -e 'N;p'" \
|
|
|
|
"a\nb\na\nb\nc\n" "" "a\nb\nc\n"
|
|
|
|
|
|
|
|
testing "sed N test2" "sed ':a;N;s/\n/ /;ta'" \
|
|
|
|
"a b c\n" "" "a\nb\nc\n"
|
|
|
|
|
|
|
|
testing "sed N test3" "sed 'N;s/\n/ /'" \
|
|
|
|
"a b\nc\n" "" "a\nb\nc\n"
|
|
|
|
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed address match newline" 'sed "/b/N;/b\\nc/i woo"' \
|
|
|
|
"a\nwoo\nb\nc\nd\n" "" "a\nb\nc\nd\n"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
|
|
|
# Multiple lines in pattern space
|
|
|
|
testing "sed N (stops at end of input) and P (prints to first newline only)" \
|
2006-03-16 20:50:45 +05:30
|
|
|
"sed -n 'N;P;p'" "a\na\nb\n" "" "a\nb\nc\n"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
|
|
|
# Hold space
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed G (append hold space to pattern space)" 'sed G' "a\n\nb\n\nc\n\n" \
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
"" "a\nb\nc\n"
|
|
|
|
#testing "sed g/G (swap/append hold and patter space)"
|
|
|
|
#testing "sed g (swap hold/pattern space)"
|
|
|
|
|
|
|
|
testing "sed d ends script iteration" \
|
2006-03-16 20:50:45 +05:30
|
|
|
"sed -e '/ook/d;s/ook/ping/p;i woot'" "" "" "ook\n"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
testing "sed d ends script iteration (2)" \
|
2006-03-16 20:50:45 +05:30
|
|
|
"sed -e '/ook/d;a\' -e 'bang'" "woot\nbang\n" "" "ook\nwoot\n"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
2006-02-24 04:43:16 +05:30
|
|
|
# Multiple files, with varying newlines and NUL bytes
|
2009-07-18 19:52:26 +05:30
|
|
|
test x"$SKIP_KNOWN_BUGS" = x"" && {
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed embedded NUL" "sed -e 's/woo/bang/'" "\0bang\0woo\0" "" \
|
|
|
|
"\0woo\0woo\0"
|
2009-07-18 19:52:26 +05:30
|
|
|
}
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed embedded NUL g" "sed -e 's/woo/bang/g'" "bang\0bang\0" "" \
|
|
|
|
"woo\0woo\0"
|
2009-07-18 19:52:26 +05:30
|
|
|
test x"$SKIP_KNOWN_BUGS" = x"" && {
|
2010-05-12 19:29:32 +05:30
|
|
|
$ECHO -e "/woo/a he\0llo" > sed.commands
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed NUL in command" "sed -f sed.commands" "woo\nhe\0llo\n" "" "woo"
|
2006-03-01 22:02:01 +05:30
|
|
|
rm sed.commands
|
2009-07-18 19:52:26 +05:30
|
|
|
}
|
2006-02-24 04:43:16 +05:30
|
|
|
|
|
|
|
# sed has funky behavior with newlines at the end of file. Test lots of
|
|
|
|
# corner cases with the optional newline appending behavior.
|
|
|
|
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed normal newlines" "sed -e 's/woo/bang/' input -" "bang\nbang\n" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"woo\n" "woo\n"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed leave off trailing newline" "sed -e 's/woo/bang/' input -" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"bang\nbang" "woo\n" "woo"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed autoinsert newline" "sed -e 's/woo/bang/' input -" "bang\nbang" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"woo" "woo"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed empty file plus cat" "sed -e 's/nohit//' input -" "one\ntwo" \
|
2006-09-17 21:58:10 +05:30
|
|
|
"" "one\ntwo"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed cat plus empty file" "sed -e 's/nohit//' input -" "one\ntwo" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"one\ntwo" ""
|
2009-07-18 19:52:26 +05:30
|
|
|
test x"$SKIP_KNOWN_BUGS" = x"" && {
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed append autoinserts newline" "sed -e '/woot/a woo' -" \
|
|
|
|
"woot\nwoo\n" "" "woot"
|
2009-07-18 19:52:26 +05:30
|
|
|
}
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed insert doesn't autoinsert newline" "sed -e '/woot/i woo' -" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"woo\nwoot" "" "woot"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed print autoinsert newlines" "sed -e 'p' -" "one\none" "" "one"
|
|
|
|
testing "sed print autoinsert newlines two files" "sed -e 'p' input -" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"one\none\ntwo\ntwo" "one" "two"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed noprint, no match, no newline" "sed -ne 's/woo/bang/' input" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"" "no\n" ""
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed selective matches with one nl" "sed -ne 's/woo/bang/p' input -" \
|
2006-02-24 04:43:16 +05:30
|
|
|
"a bang\nc bang\n" "a woo\nb no" "c woo\nd no"
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed selective matches insert newline" \
|
|
|
|
"sed -ne 's/woo/bang/p' input -" "a bang\nb bang\nd bang" \
|
|
|
|
"a woo\nb woo" "c no\nd woo"
|
|
|
|
testing "sed selective matches noinsert newline" \
|
|
|
|
"sed -ne 's/woo/bang/p' input -" "a bang\nb bang" "a woo\nb woo" \
|
|
|
|
"c no\nd no"
|
2009-07-18 19:52:26 +05:30
|
|
|
test x"$SKIP_KNOWN_BUGS" = x"" && {
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed clusternewline" \
|
|
|
|
"sed -e '/one/a 111' -e '/two/i 222' -e p input -" \
|
2006-09-17 21:58:10 +05:30
|
|
|
"one\none\n111\n222\ntwo\ntwo" "one" "two"
|
2009-07-18 19:52:26 +05:30
|
|
|
}
|
2007-01-29 20:01:47 +05:30
|
|
|
testing "sed subst+write" \
|
2010-05-12 19:29:32 +05:30
|
|
|
"sed -e 's/i/z/' -e 'woutputw' input -; $ECHO -n X; cat outputw" \
|
2007-01-29 20:01:47 +05:30
|
|
|
"thzngy\nagaznXthzngy\nagazn" "thingy" "again"
|
|
|
|
rm outputw
|
2007-01-29 22:40:19 +05:30
|
|
|
testing "sed trailing NUL" \
|
|
|
|
"sed 's/i/z/' input -" \
|
|
|
|
"a\0b\0\nc" "a\0b\0" "c"
|
2007-03-17 05:06:58 +05:30
|
|
|
testing "sed escaped newline in command" \
|
|
|
|
"sed 's/a/z\\
|
|
|
|
z/' input" \
|
|
|
|
"z\nz" "a" ""
|
2006-02-24 04:43:16 +05:30
|
|
|
|
2006-03-01 22:02:01 +05:30
|
|
|
# Test end-of-file matching behavior
|
|
|
|
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed match EOF" "sed -e '"'$p'"'" "hello\nthere\nthere" "" \
|
|
|
|
"hello\nthere"
|
|
|
|
testing "sed match EOF two files" "sed -e '"'$p'"' input -" \
|
2006-03-01 22:02:01 +05:30
|
|
|
"one\ntwo\nthree\nfour\nfour" "one\ntwo" "three\nfour"
|
2007-01-29 04:56:15 +05:30
|
|
|
# sed match EOF inline: gnu sed 4.1.5 outputs this:
|
|
|
|
#00000000 6f 6e 65 0a 6f 6f 6b 0a 6f 6f 6b 0a 74 77 6f 0a |one.ook.ook.two.|
|
|
|
|
#00000010 0a 74 68 72 65 65 0a 6f 6f 6b 0a 6f 6f 6b 0a 66 |.three.ook.ook.f|
|
|
|
|
#00000020 6f 75 72 |our|
|
|
|
|
# which looks buggy to me.
|
2008-07-12 03:11:14 +05:30
|
|
|
$ECHO -ne "three\nfour" > input2
|
2006-03-01 22:02:01 +05:30
|
|
|
testing "sed match EOF inline" \
|
2006-03-16 20:50:45 +05:30
|
|
|
"sed -e '"'$i ook'"' -i input input2 && cat input input2" \
|
2006-03-01 22:02:01 +05:30
|
|
|
"one\nook\ntwothree\nook\nfour" "one\ntwo" ""
|
|
|
|
rm input2
|
|
|
|
|
|
|
|
# Test lie-to-autoconf
|
|
|
|
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed lie-to-autoconf" "sed --version | grep -o 'GNU sed version '" \
|
2006-03-01 22:02:01 +05:30
|
|
|
"GNU sed version \n" "" ""
|
|
|
|
|
|
|
|
# Jump to nonexistent label
|
2009-07-18 19:52:26 +05:30
|
|
|
test x"$SKIP_KNOWN_BUGS" = x"" && {
|
|
|
|
# Incompatibility: illegal jump is not detected if input is ""
|
|
|
|
# (that is, no lines at all). GNU sed 4.1.5 complains even in this case
|
|
|
|
testing "sed nonexistent label" "sed -e 'b walrus' 2>/dev/null || echo yes" \
|
2006-03-01 22:02:01 +05:30
|
|
|
"yes\n" "" ""
|
2009-07-18 19:52:26 +05:30
|
|
|
}
|
2006-03-01 22:02:01 +05:30
|
|
|
|
|
|
|
testing "sed backref from empty s uses range regex" \
|
2006-03-16 20:50:45 +05:30
|
|
|
"sed -e '/woot/s//eep \0 eep/'" "eep woot eep" "" "woot"
|
2006-03-01 22:02:01 +05:30
|
|
|
|
|
|
|
testing "sed backref from empty s uses range regex with newline" \
|
2006-03-16 20:50:45 +05:30
|
|
|
"sed -e '/woot/s//eep \0 eep/'" "eep woot eep\n" "" "woot\n"
|
2006-03-01 22:02:01 +05:30
|
|
|
|
|
|
|
# -i with no filename
|
|
|
|
|
|
|
|
touch ./- # Detect gnu failure mode here.
|
2006-03-16 20:50:45 +05:30
|
|
|
testing "sed -i with no arg [GNUFAIL]" "sed -e '' -i 2> /dev/null || echo yes" \
|
2006-03-01 22:02:01 +05:30
|
|
|
"yes\n" "" ""
|
|
|
|
rm ./- # Clean up
|
|
|
|
|
2006-07-26 22:55:08 +05:30
|
|
|
testing "sed s/xxx/[/" "sed -e 's/xxx/[/'" "[\n" "" "xxx\n"
|
|
|
|
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
# Ponder this a bit more, why "woo not found" from gnu version?
|
|
|
|
#testing "sed doesn't substitute in deleted line" \
|
2006-03-16 20:50:45 +05:30
|
|
|
# "sed -e '/ook/d;s/ook//;t woo;a bang;'" "bang" "" "ook\n"
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
|
|
|
|
# This makes both seds very unhappy. Why?
|
|
|
|
#testing "sed -g (exhaustive)" "sed -e 's/[[:space:]]*/,/g'" ",1,2,3,4,5," \
|
|
|
|
# "" "12345"
|
|
|
|
|
2011-08-16 16:59:34 +05:30
|
|
|
# testing "description" "commands" "result" "infile" "stdin"
|
2008-02-28 23:29:01 +05:30
|
|
|
|
|
|
|
testing "sed n command must reset 'substituted' bit" \
|
|
|
|
"sed 's/1/x/;T;n;: next;s/3/y/;t quit;n;b next;: quit;q'" \
|
|
|
|
"0\nx\n2\ny\n" "" "0\n1\n2\n3\n"
|
|
|
|
|
2009-06-30 22:49:37 +05:30
|
|
|
testing "sed d does not break n,m matching" \
|
|
|
|
"sed -n '1d;1,3p'" \
|
|
|
|
"second\nthird\n" "" "first\nsecond\nthird\nfourth\n"
|
|
|
|
|
|
|
|
testing "sed d does not break n,regex matching" \
|
|
|
|
"sed -n '1d;1,/hir/p'" \
|
|
|
|
"second\nthird\n" "" "first\nsecond\nthird\nfourth\n"
|
|
|
|
|
|
|
|
testing "sed d does not break n,regex matching #2" \
|
|
|
|
"sed -n '1,5d;1,/hir/p'" \
|
|
|
|
"second2\nthird2\n" "" \
|
|
|
|
"first\nsecond\nthird\nfourth\n""first2\nsecond2\nthird2\nfourth2\n"
|
|
|
|
|
2009-07-10 15:25:20 +05:30
|
|
|
testing "sed 2d;2,1p (gnu compat)" \
|
|
|
|
"sed -n '2d;2,1p'" \
|
|
|
|
"third\n" "" \
|
|
|
|
"first\nsecond\nthird\nfourth\n"
|
|
|
|
|
2009-08-17 05:05:04 +05:30
|
|
|
# Regex means: "match / at BOL or nothing, then one or more not-slashes".
|
|
|
|
# The bug was that second slash in /usr/lib was treated as "at BOL" too.
|
|
|
|
testing "sed beginning (^) matches only once" \
|
|
|
|
"sed 's,\(^/\|\)[^/][^/]*,>\0<,g'" \
|
|
|
|
">/usr</>lib<\n" "" \
|
|
|
|
"/usr/lib\n"
|
|
|
|
|
2010-04-20 08:06:07 +05:30
|
|
|
testing "sed c" \
|
|
|
|
"sed 'crepl'" \
|
|
|
|
"repl\nrepl\n" "" \
|
|
|
|
"first\nsecond\n"
|
|
|
|
|
2010-04-20 13:30:03 +05:30
|
|
|
testing "sed nested {}s" \
|
|
|
|
"sed '/asd/ { p; /s/ { s/s/c/ }; p; q }'" \
|
|
|
|
"qwe\nasd\nacd\nacd\n" "" \
|
|
|
|
"qwe\nasd\nzxc\n"
|
|
|
|
|
2010-05-12 05:19:04 +05:30
|
|
|
testing "sed a cmd ended by double backslash" \
|
|
|
|
"sed -e '/| one /a \\
|
|
|
|
| three \\\\' -e '/| one-/a \\
|
|
|
|
| three-* \\\\'" \
|
|
|
|
' | one \\
|
|
|
|
| three \\
|
|
|
|
| two \\
|
|
|
|
' '' \
|
|
|
|
' | one \\
|
|
|
|
| two \\
|
|
|
|
'
|
|
|
|
|
2010-08-01 07:44:46 +05:30
|
|
|
# first three lines are deleted; 4th line is matched and printed by "2,3" and by "4" ranges
|
2010-06-04 04:59:52 +05:30
|
|
|
testing "sed with N skipping lines past ranges on next cmds" \
|
|
|
|
"sed -n '1{N;N;d};1p;2,3p;3p;4p'" \
|
|
|
|
"4\n4\n" "" "1\n2\n3\n4\n"
|
|
|
|
|
2010-08-01 07:44:46 +05:30
|
|
|
testing "sed -i with address modifies all files, not only first" \
|
|
|
|
"cp input input2; sed -i -e '1s/foo/bar/' input input2 && cat input input2; rm input2" \
|
2010-08-01 07:49:59 +05:30
|
|
|
"bar\nbar\n" "foo\n" ""
|
2010-08-01 07:44:46 +05:30
|
|
|
|
2011-05-03 04:22:22 +05:30
|
|
|
testing "sed understands \r" \
|
|
|
|
"sed 's/r/\r/'" \
|
|
|
|
"\rrr\n" "" "rrr\n"
|
2010-08-01 07:44:46 +05:30
|
|
|
|
2011-08-16 16:59:34 +05:30
|
|
|
testing "sed -i finishes ranges correctly" \
|
|
|
|
"sed '1,2d' -i input; echo \$?; cat input" \
|
|
|
|
"0\n3\n4\n" "1\n2\n3\n4\n" ""
|
|
|
|
|
|
|
|
# testing "description" "commands" "result" "infile" "stdin"
|
2010-05-12 05:19:04 +05:30
|
|
|
|
Ok, I've converted the contents of the "testing/sed" directory into a
sed.tests file. My brain hurts now. (Lots of boggling at sed minutiae and
corner cases and going "why is gnu giving that output". The behavior of N
and n with regard to EOF are only understandable if you read the Open Group
spec, not if you read the sed info page, by the way...)
Some of the existing sed tests are just nuts. For example, sed-next-line is
testing for our behavior (which is wrong), and would fail if run against gnu
sed (which was getting it right. Again, this was a spec-boggling moment,
with much head scratching. I've got to add a debug mode where the stuff
output by the p command is a different color from the stuff output by normal
end of script printing (when not suppressed by -n).)
As for sed-handles-unsatisifed-backrefs: what is this test trying to _do_? I
ran it against gnu sed and got an error message, and this behavior sounds
perfectly reasonable. (It _is_ an unsatisfied backref.) The fact we
currently ignore this case (and treat \1 as an empty string) isn't really
behavior we should have a test depend on for success.
The remaining one is sed-aic-commands, which is long and complicated. I'm
trying to figure out if I should chop this into a number of smaller tests, or
if having one big "does-many-things" test is a good idea.
In any case, the _next_ step is to go through the Open Group standard and
make tests for every case not yet covered. (And there are plenty. There
are few comments in the file already.) Plus I have notes about corner
cases from development that I need to collate and put into here. This file
is maybe the first 1/3 of a truly comprehensive sed test.
Rob
2005-11-10 11:56:40 +05:30
|
|
|
exit $FAILCOUNT
|