> Since early 2019 with e62e225f (test-lint: only use only sed [-n]
> [-e command] [-f command_file], 2019-01-20), we have been trying to
> limit the options of "sed" we use in our tests to "-e <pattern>",
> "-n", and "-f <file>".
> 
> Before the commit, we were trying to reject only "-i" (which is one
> of the really-not-portable options), but the commit explicitly
> wanted to reject use of "-E" (use ERE instead of BRE).  The commit
> cites the then-current POSIX.1 (Issue 7, 2018 edition) to show that
> "even recent POSIX does not have it!", but the latest edition (Issue
> 8) documents "-E" as an option to use ERE.
> 
> But that was 7 years ago, and that is a long time for many things to
> happen.
> 
> Besides, we have been using "sed -E" without the check in question
> triggering in one of the scripts since 2022, with 461fec41 (bisect
> run: keep some of the post-v2.30.0 output, 2022-11-10).  It was
> hidden because the 'E' was squished with another single letter
> option.
> 
> t/t6030-bisect-porcelain.sh:	sed -En 's/.*(bisect...
> 
> This escaped the rather simple pattern used in the checker
> 
>     /\bsed\s+-[^efn]\s+/ and err 'sed option not portable...';
> 
> because -E did not appear as a singleton.

> Let's change the rule to allow the "-E" option, which nobody has
> complained against for the past 3 years.  We rewrite our first use
> of the "-E" option so that it is caught by the old rule, primarily
> because we do not want to teach our mischievous developers how to
> smuggle in an unwanted option undetected by the test lint.  And at
> the same time, loosen the pattern to allow "-E" the same way we
> allow "-n" and friends.