# [RFC] t: allow use of "sed -E" 9 messages from 2026-03-11 to 2026-03-14. Participants: Junio C Hamano, Ramsay Jones, Patrick Steinhardt, brian m. carlson, Todd Zullinger. Thread: https://gitlist.dev/t/65216 ## Junio C Hamano, 2026-03-11 21:35 Subject: [RFC] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/xmqq5x72m4lu.fsf%40gitster.g ``` 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 ", "-n", and "-f ". 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 unwated 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. Signed-off-by: Junio C Hamano --- t/check-non-portable-shell.pl | 2 +- t/t6030-bisect-porcelain.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git c/t/check-non-portable-shell.pl w/t/check-non-portable-shell.pl index 6ee7700eb4..dd8af6d08f 100755 --- c/t/check-non-portable-shell.pl +++ w/t/check-non-portable-shell.pl @@ -36,7 +36,7 @@ sub err { $_ = $line; /\bcp\s+-a/ and err 'cp -a is not portable'; - /\bsed\s+-[^efn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; + /\bsed\s+-[^Eefn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; /\becho\s+-[neE]/ and err 'echo with option is not portable (use printf)'; /^\s*declare\s+/ and err 'arrays/declare not portable'; /^\s*[^#]\s*which\s/ and err 'which is not portable (use type)'; diff --git c/t/t6030-bisect-porcelain.sh w/t/t6030-bisect-porcelain.sh index cdc0270640..1ba9ca219e 100755 --- c/t/t6030-bisect-porcelain.sh +++ w/t/t6030-bisect-porcelain.sh @@ -402,7 +402,7 @@ test_expect_success 'git bisect run: negative exit code' " git bisect good $HASH1 && git bisect bad $HASH4 && ! git bisect run ./fail.sh 2>err && - sed -En 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && + sed -E -n 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && test_cmp expect actual " ``` ## Junio C Hamano, 2026-03-11 21:41 Subject: Re: [RFC] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/xmqq1phqm4ca.fsf%40gitster.g In-Reply-To: ``` Junio C Hamano writes: > 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 ", > "-n", and "-f ". > > 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 unwated option undetected by the test lint. And at "unwated" -> "unwanted", of course ;-) > the same time, loosen the pattern to allow "-E" the same way we > allow "-n" and friends. > > Signed-off-by: Junio C Hamano > --- > > t/check-non-portable-shell.pl | 2 +- > t/t6030-bisect-porcelain.sh | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git c/t/check-non-portable-shell.pl w/t/check-non-portable-shell.pl > index 6ee7700eb4..dd8af6d08f 100755 > --- c/t/check-non-portable-shell.pl > +++ w/t/check-non-portable-shell.pl > @@ -36,7 +36,7 @@ sub err { > > $_ = $line; > /\bcp\s+-a/ and err 'cp -a is not portable'; > - /\bsed\s+-[^efn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; > + /\bsed\s+-[^Eefn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; > /\becho\s+-[neE]/ and err 'echo with option is not portable (use printf)'; > /^\s*declare\s+/ and err 'arrays/declare not portable'; > /^\s*[^#]\s*which\s/ and err 'which is not portable (use type)'; > diff --git c/t/t6030-bisect-porcelain.sh w/t/t6030-bisect-porcelain.sh > index cdc0270640..1ba9ca219e 100755 > --- c/t/t6030-bisect-porcelain.sh > +++ w/t/t6030-bisect-porcelain.sh > @@ -402,7 +402,7 @@ test_expect_success 'git bisect run: negative exit code' " > git bisect good $HASH1 && > git bisect bad $HASH4 && > ! git bisect run ./fail.sh 2>err && > - sed -En 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && > + sed -E -n 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && > test_cmp expect actual > " > ``` ## Ramsay Jones, 2026-03-11 23:12 Subject: Re: [RFC] t: allow use of "sed -E" Message-ID: <77fce76d-07e2-4586-bb6c-f0043d171591@ramsayjones.plus.com> URL: https://gitlist.dev/e/77fce76d-07e2-4586-bb6c-f0043d171591%40ramsayjones.plus.com In-Reply-To: ``` On 11/03/2026 9:41 pm, Junio C Hamano wrote: > Junio C Hamano writes: > [snip] >> >> 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 unwated option undetected by the test lint. And at > > "unwated" -> "unwanted", of course ;-) > >> the same time, loosen the pattern to allow "-E" the same way we >> allow "-n" and friends. >> >> Signed-off-by: Junio C Hamano >> --- >> >> t/check-non-portable-shell.pl | 2 +- >> t/t6030-bisect-porcelain.sh | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git c/t/check-non-portable-shell.pl w/t/check-non-portable-shell.pl >> index 6ee7700eb4..dd8af6d08f 100755 >> --- c/t/check-non-portable-shell.pl >> +++ w/t/check-non-portable-shell.pl >> @@ -36,7 +36,7 @@ sub err { >> >> $_ = $line; >> /\bcp\s+-a/ and err 'cp -a is not portable'; >> - /\bsed\s+-[^efn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; >> + /\bsed\s+-[^Eefn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; .. and, perhaps, add -E to the error message? ATB, Ramsay Jones >> /\becho\s+-[neE]/ and err 'echo with option is not portable (use printf)'; >> /^\s*declare\s+/ and err 'arrays/declare not portable'; >> /^\s*[^#]\s*which\s/ and err 'which is not portable (use type)'; >> diff --git c/t/t6030-bisect-porcelain.sh w/t/t6030-bisect-porcelain.sh >> index cdc0270640..1ba9ca219e 100755 >> --- c/t/t6030-bisect-porcelain.sh >> +++ w/t/t6030-bisect-porcelain.sh >> @@ -402,7 +402,7 @@ test_expect_success 'git bisect run: negative exit code' " >> git bisect good $HASH1 && >> git bisect bad $HASH4 && >> ! git bisect run ./fail.sh 2>err && >> - sed -En 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && >> + sed -E -n 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && >> test_cmp expect actual >> " >> > ``` ## Junio C Hamano, 2026-03-12 00:33 Subject: Re: [RFC] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/xmqq7brhlwdd.fsf%40gitster.g In-Reply-To: <77fce76d-07e2-4586-bb6c-f0043d171591@ramsayjones.plus.com> ``` Ramsay Jones writes: >>> - /\bsed\s+-[^efn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; >>> + /\bsed\s+-[^Eefn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; > > .. and, perhaps, add -E to the error message? Yes, indeed. Thanks. ``` ## Junio C Hamano, 2026-03-12 00:45 Subject: [PATCH v2] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/xmqq3425lvtq.fsf%40gitster.g In-Reply-To: ``` 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 ", "-n", and "-f ". 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. Signed-off-by: Junio C Hamano --- t/check-non-portable-shell.pl | 2 +- t/t6030-bisect-porcelain.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/t/check-non-portable-shell.pl b/t/check-non-portable-shell.pl index 6ee7700eb4..18d944b810 100755 --- a/t/check-non-portable-shell.pl +++ b/t/check-non-portable-shell.pl @@ -36,7 +36,7 @@ sub err { $_ = $line; /\bcp\s+-a/ and err 'cp -a is not portable'; - /\bsed\s+-[^efn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; + /\bsed\s+-[^Eefn]\s+/ and err 'sed option not portable (use only -E, -n, -e, -f)'; /\becho\s+-[neE]/ and err 'echo with option is not portable (use printf)'; /^\s*declare\s+/ and err 'arrays/declare not portable'; /^\s*[^#]\s*which\s/ and err 'which is not portable (use type)'; diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh index cdc0270640..1ba9ca219e 100755 --- a/t/t6030-bisect-porcelain.sh +++ b/t/t6030-bisect-porcelain.sh @@ -402,7 +402,7 @@ test_expect_success 'git bisect run: negative exit code' " git bisect good $HASH1 && git bisect bad $HASH4 && ! git bisect run ./fail.sh 2>err && - sed -En 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && + sed -E -n 's/.*(bisect.*code) (-?[0-9]+) (from.*)/\1 -1 \3/p' err >actual && test_cmp expect actual " Range-diff: 1: 43a56fa521 ! 1: be430f4eaa t: allow use of "sed -E" @@ Commit message 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 unwated option undetected by the test lint. And at + 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. @@ t/check-non-portable-shell.pl: sub err { $_ = $line; /\bcp\s+-a/ and err 'cp -a is not portable'; - /\bsed\s+-[^efn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; -+ /\bsed\s+-[^Eefn]\s+/ and err 'sed option not portable (use only -n, -e, -f)'; ++ /\bsed\s+-[^Eefn]\s+/ and err 'sed option not portable (use only -E, -n, -e, -f)'; /\becho\s+-[neE]/ and err 'echo with option is not portable (use printf)'; /^\s*declare\s+/ and err 'arrays/declare not portable'; /^\s*[^#]\s*which\s/ and err 'which is not portable (use type)'; -- 2.53.0-698-g1cc7e6b802 ``` ## Patrick Steinhardt, 2026-03-12 06:41 Subject: Re: [PATCH v2] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/abJgGapdAIQXIsNy%40pks.im In-Reply-To: ``` On Wed, Mar 11, 2026 at 05:45:21PM -0700, Junio C Hamano wrote: > 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 ", > "-n", and "-f ". > > 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. Makes me wonder whether we also want to harden this regex. But even if we started to understand that multiple single-letter options can be squished together it wouldn't be sufficient, as we don't know to process multiple arugments, either. And I guess it doesn't make sense to grow a full command line parser here. > 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. Feels reasonable to me. Patrick ``` ## brian m. carlson, 2026-03-12 09:26 Subject: Re: [PATCH v2] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/abKG1U3fVuNV1w_9%40fruit.crustytoothpaste.net In-Reply-To: ``` On 2026-03-12 at 00:45:21, Junio C Hamano wrote: > 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 ", > "-n", and "-f ". > > 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. I think this seems reasonable. I know this works on both reasonably new Linux machines and on macOS, and I did some spot checking with the FreeBSD manual page viewer[0] and it's present in the following: * at least FreeBSD 9.0 (current is 15.0) * at least NetBSD 7.0 (current is 10.1) * at least OpenBSD 6.0 (current is 7.8) * Ubuntu 18.04 so this appears to be reasonably well supported across major open source distributions. The irony is that Linux is most likely the OS holding us back here, since older versions labeled this `-r` and the newer `-E` wasn't available in Ubuntu 16.04. I myself only recently learned about the fact that `-E` had been officially standardized, since I'd been using `-r` for a long time. And, for the record, I agree with you that `-i` is totally non-portable because it _requires_ an argument on BSD sed and the argument is optional on GNU sed (and cannot be specified as ''). I have a testsuite at work where I gave up and just used `perl -i` instead. > 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. Yes, I think if nobody has complained about it in three years, we should be fine. [0] https://man.freebsd.org/cgi/man.cgi -- brian m. carlson (they/them) Toronto, Ontario, CA ``` ## Junio C Hamano, 2026-03-12 13:43 Subject: Re: [PATCH v2] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/xmqqtsuli2ni.fsf%40gitster.g In-Reply-To: ``` "brian m. carlson" writes: > Yes, I think if nobody has complained about it in three years, we should > be fine. This actually started when I noticed a recent rewrite of a test that turned "grep -E ... | sed -e ..." into "sed -E -e ..." was flagged by the test-lint. It is not a huge deal to rewrite the resulting sed script again to use BRE instead of ERE and it may not be a bad idea doing so anyway (and rewrite the existing t6030). That can be done independently. ``` ## Todd Zullinger, 2026-03-14 23:16 Subject: Re: [PATCH v2] t: allow use of "sed -E" Message-ID: URL: https://gitlist.dev/e/abXsWp5gYbxdHbkz%40teonanacatl.net In-Reply-To: ``` brian m. carlson wrote: > so this appears to be reasonably well supported across major open source > distributions. The irony is that Linux is most likely the OS holding us > back here, since older versions labeled this `-r` and the newer `-E` > wasn't available in Ubuntu 16.04. I myself only recently learned about > the fact that `-E` had been officially standardized, since I'd been > using `-r` for a long time. IIRC, GNU sed supported -E for a very long time before it was documented. In a quick search, I see it added in v4.1a, in commit 3a8e165 (treat cygwin CR/LF correctly (and by design, not by chance), 2006-08-07). https://cgit.git.savannah.gnu.org/cgit/sed.git/diff/sed/sed.c?id=3a8e165 -- Todd ```