From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Torsten Bögershausen" <tboegi@web.de>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH v2] t: allow use of "sed -E"
Date: Thu, 12 Mar 2026 07:41:37 +0100 [thread overview]
Message-ID: <abJgGapdAIQXIsNy@pks.im> (raw)
In-Reply-To: <xmqq3425lvtq.fsf@gitster.g>
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
next prev parent reply other threads:[~2026-03-12 6: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
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 [this message]
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=abJgGapdAIQXIsNy@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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