sed - 使用 sed 删除文件的行 - 意外行为

Question

我在玩 sed 时发现了一些奇怪的东西。如果您尝试从文件中删除多个行间隔(按编号)，但列表中后面指定的任何间隔都完全包含在列表中较早的间隔内，则在指定的(较大)间隔后删除一个额外的单行。

seq 10 > foo.txt

sed '2,7d;3,6d' foo.txt
1
9
10

这种行为对我来说是一个令人讨厌的错误背后的问题，因为在我的脚本中我即时生成了间隔端点，并且在某些情况下产生的间隔是多余的。我可以解决这个问题，但我想不出一个很好的理由为什么 sed 会故意这样做。

Answer 1

由于这个问题在 2015-02-24 的 Stack Overflow Weekly Newsletter 电子邮件中被强调为需要答案，所以我将上面的评论(提供答案)转换为正式答案。此处未注明出处的评论是我以基本等效的形式发表的。

感谢您提出简洁、完整的问题。结果很有趣。我可以用你的脚本重现它。有趣的是，sed '3,6d;2,7d' foo.txt (删除操作以相反的顺序)产生预期的答案，输出中包含 8。这使它看起来像是 (GNU) sed 中的一个可报告的错误。 ，尤其是作为 BSD sed (在 Mac OS X 10.10.2 Yosemite 上)按任一顺序正确操作。我使用来自 Ubuntu 14.04 衍生产品的 'sed (GNU sed) 4.2.2' 进行了测试。

为您/他们提供更多数据点。这两个都在输出中包含 8:

sed -e '/2/,/7/d' -e '/3/,/6/d' foo.txt
sed -e '2,7d' -e '/3/,/6/d' foo.txt

相比之下，这不会:

sed -e '/2/,/7/d' -e '3,6d' foo.txt

后者让我感到惊讶(甚至接受了基本的错误)。

Beats me. I thought given some of sed's arcane constructs that you might be missing the batman symbol or something from the middle of your command but sed -e '2,7d' -e '3,6d' foo.txt behaves the same way and swapping the order produces the expected results (GNU sed 4.2.2 on Cygwin). /bin/sed on Solaris always produces the expected result and interestingly so does GNU sed 3.02. Ed Morton

More data: it only seems to happen with sed 4.2.2 if the 2nd range is a subset of the first: sed '2,5d;2,5d' shows the bug, sed '2,5d;1,5d' and sed '2,5d;2,6d' do not. glenn jackman

GNU sed 主页上写着“请将错误报告发送到 gnu.org 上的 bug-sed”(除非它用 @ 代替“at ”)。你有一个很好的复制品；明确说明您期望的输出与您得到的输出(他们会明白这一点，但最好确保他们不会误解)。指出命令的相反顺序按预期工作，并给出各种其他命令作为工作或不工作的示例。 (您甚至可以将此问答 URL 作为交叉引用，但请确保错误报告是自包含的，以便即使没有人跟随该 URL 也可以理解它。)

您也可以指向 BSD sed (以及 Solaris 版本，以及较旧的 GNU 3.02 sed )按预期运行。随着旧版本的 GNU sed 工作，这意味着这可以说是一种回归。 […经过一些实验…] 4.1 版本中发生了破坏； 4.0.9 版本是可以的。 (我还检查了 4.1.5 和 4.2.1；两者都坏了。)如果维护人员想通过查看更改的内容来查找问题，这将有助于他们。

OP指出:

• Thanks everyone for comments and additional tests. I'll submit a bug report to GNU sed and post their response. santayana