この質問は2012年3月にオースティングループメーリングリストに提出されました。この問題の最後の言葉は次のとおりです（この問題を最初に提起したAustinグループ（POSIXを維持する組織）のGeoff Clareが提起しました）。以下はgmane NNTPインターフェイスからコピーされました。

Date: Fri, 16 Mar 2012 17:09:42 +0000
From: Geoff Clare <gwc-7882/[email protected]>
To: austin-group-l-7882/[email protected]
Newsgroups: gmane.comp.standards.posix.austin.general
Subject: Re: Strange addressing issue in sed

Stephane Chazelas <[email protected]> wrote, on 16 Mar 2012:
>
> 2012-03-16 15:44:35 +0000, Geoff Clare:
> > I've been alerted to an odd behaviour of sed on certified UNIX
> > systems that doesn't seem to match the requirements of the
> > standard.  It concerns an interaction between the 'n' command
> > and address matching.
> > 
> > According to the standard, this command:
> > 
> > printf 'A\nB\nC\nD\n' | sed '1,3s/A/B/;1,3n;1,3s/B/C/'
> > 
> > should produce the output:
> > 
> > B
> > C
> > C
> > D
> > 
> > GNU sed does produce this, but certified UNIX systems produce this:
> > 
> > B
> > B
> > C
> > D
> > 
> > However, if I change the 1,3s/B/C/ to 2,3s/B/C/ then they produce
> > the expected output (tested on Solaris and HP-UX).
> > 
> > Is this just an obscure bug from common ancestor code, or is there
> > some legitimate reason why this address change alters the behaviour?
> [...]
> 
> I suppose the idea is that for the second 1,3cmd, line "1" has
> not been seen, so the 1,3 range is not entered.

Ah yes, now it makes sense, and it looks like the standard does
require this slightly strange behaviour, given how the processing
of the "two addresses" case is specified:

    An editing command with two addresses shall select the inclusive
    range from the first pattern space that matches the first address
    through the next pattern space that matches the second.  (If the
    second address is a number less than or equal to the line number
    first selected, only one line shall be selected.) Starting at the
    first line following the selected range, sed shall look again for
    the first address. Thereafter, the process shall be repeated.

It's specified this way because the addresses can be BREs, but if
the same matching process is applied to the line numbers (even though
they can only match at most once), then the 1,3 range on that last
command is never entered.

-- 
Geoff Clare <g.clare-7882/[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Jeffが（私から）引用したメッセージの残りの部分の関連部分は次のとおりです。

I suppose the idea is that for the second 1,3cmd, line "1" has
not been seen, so the 1,3 range is not entered.

Same idea as in

printf '%s\n' A B C | sed -n '1d;1,2p'

whose behavior differ in traditional (heirloom toolchest at
least) and GNU.

It's unclear to me whether POSIX wants one behavior or the
other.

したがって（Geoffによると）POSIXは明らかGNUは違法に行動します。

実際には、一貫性が少ないseq 10 | sed -n '1d;1,2p'（seq 10 | sed -n '1d;/^1$/,2p'「奇妙な」）。

誰もこれをGNUの人々にバグとして報告したくありません。これをバグだと思うべきかわかりません。おそらく最良の選択は、両方の動作を許可するようにPOSIX仕様を更新して、どちらにも依存できないことを明らかにすることです。

編集する。 1970年代後半のUnix V7の元の実装を見てみると、sed数値アドレスの動作が意図されていないか、少なくとも完全に考慮されていないようです。

代わりに、Geoffが仕様を読んだ後（そしてそれが起こった理由の元の説明）、次の場所にあります。

seq 5 | sed -n '3d;1,3p'

ライン1、2、4、5は、今回は1,3prangedコマンドが一度も会ったことのないエンドアドレスであるため、出力する必要があります。seq 5 | sed -n '3d;/1/,/3/p'

しかし、これは元の実装では発生せず、私が試した他の実装では発生しません（busyboxはバグのようsedに見える行1、2、および4を返します）。

見たらUNIX v7コード、現在の行番号が次であることを確認します。大きい(番号) 終了アドレスより範囲外です。実は開始アドレスについてはこれを行いません。意図したデザインというよりは間違いに見えます。

これは、現在の実装が実際にこの側面のPOSIX仕様の解釈に従わないことを意味します。

GNU実装の別の混乱した動作は次のとおりです。

$ seq 5 | sed -n '2d;2,/3/p'
3
4
5

2行目はスキップしたので、3行目2,/3/に入力してください（数字が2より大きい最初の行）。しかし、私たちを作るのはこのラインです。入力する範囲、未確認終わり住所状況がさらに悪化しますbusybox sed。

$ seq 10 | busybox sed -n '2,7d; 2,3p'
8

2〜7行が削除されたため、8行は最初の行> = 2なので、2,3の範囲は次のようになります。入力するそれから！