Volume XXII, number 280Wednesday, October 7, 2026Latest message 1 hour ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

[RFC] t: allow use of "sed -E"

9 messages between Mar 11, 2026 and Mar 14, 2026, from Junio C Hamano, Ramsay Jones, Patrick Steinhardt, brian m. carlson, Todd Zullinger.

Plain Markdown or JSON for tools and agents.

Junio C HamanoMar 11, 2026, 21:35 UTC on lore

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 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 <gitster@pobox.com>
---
 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 HamanoMar 11, 2026, 21:41 UTC in reply to Junio C Hamano on lore

Re: [RFC] t: allow use of "sed -E"

Junio C Hamano <gitster@pobox.com> writes:
Show 34 quoted lines
> 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 unwated option undetected by the test lint.  And at
"unwated" -> "unwanted", of course ;-)
Show 36 quoted lines
> the same time, loosen the pattern to allow "-E" the same way we
> allow "-n" and friends.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>  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 JonesMar 11, 2026, 23:12 UTC in reply to Junio C Hamano on lore

Re: [RFC] t: allow use of "sed -E"

On 11/03/2026 9:41 pm, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
[snip]
Show 29 quoted lines
>>
>> 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 <gitster@pobox.com>
>> ---
>>
>>  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

Show 17 quoted lines
>>  	/\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 HamanoMar 12, 2026, 00:33 UTC in reply to Ramsay Jones on lore

Re: [RFC] t: allow use of "sed -E"

Ramsay Jones <ramsay@ramsayjones.plus.com> 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 HamanoMar 12, 2026, 00:45 UTC in reply to Junio C Hamano on lore

[PATCH v2] t: allow use of "sed -E"

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.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 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 SteinhardtMar 12, 2026, 06:41 UTC in reply to Junio C Hamano on lore

Re: [PATCH v2] t: allow use of "sed -E"

On Wed, Mar 11, 2026 at 05:45:21PM -0700, Junio C Hamano wrote:
Show 28 quoted lines
> 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.

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.

Show 7 quoted lines
> 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. carlsonMar 12, 2026, 09:26 UTC in reply to Junio C Hamano on lore

Re: [PATCH v2] t: allow use of "sed -E"

On 2026-03-12 at 00:45:21, Junio C Hamano wrote:
Show 14 quoted lines
> 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.

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.

Show 5 quoted lines
> 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 HamanoMar 12, 2026, 13:43 UTC in reply to brian m. carlson on lore

Re: [PATCH v2] t: allow use of "sed -E"

"brian m. carlson" <sandals@crustytoothpaste.net> 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 ZullingerMar 14, 2026, 23:16 UTC in reply to brian m. carlson on lore

Re: [PATCH v2] t: allow use of "sed -E"

brian m. carlson wrote:
Show 6 quoted lines
> 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

Back to recent threads