public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [RFC] t: allow use of "sed -E"
Date: Wed, 11 Mar 2026 14:41:25 -0700	[thread overview]
Message-ID: <xmqq1phqm4ca.fsf@gitster.g> (raw)
In-Reply-To: <xmqq5x72m4lu.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 11 Mar 2026 14:35:41 -0700")

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

  reply	other threads:[~2026-03-11 21:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 21:35 [RFC] t: allow use of "sed -E" Junio C Hamano
2026-03-11 21:41 ` Junio C Hamano [this message]
2026-03-11 23:12   ` Ramsay Jones
2026-03-12  0:33     ` Junio C Hamano
2026-03-12  0:45 ` [PATCH v2] " Junio C Hamano
2026-03-12  6:41   ` Patrick Steinhardt
2026-03-12  9:26   ` brian m. carlson
2026-03-12 13:43     ` Junio C Hamano
2026-03-14 23:16     ` Todd Zullinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq1phqm4ca.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.com \
    --cc=szeder.dev@gmail.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox