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

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

[Junio C Hamano]

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
 "
 

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> 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 <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 ;-)

> 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
>  "
>  

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

[Ramsay Jones]

On 11/03/2026 9:41 pm, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> 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 <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

>>  	/\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
>>  "
>>  
> 

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

[Junio C Hamano]

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.

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

[Junio C Hamano]

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

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

[Patrick Steinhardt]

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 <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.

> 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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

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 <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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Junio C Hamano]

"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.

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

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]