The use of Extended Regular Expressions and in-place editing was removed
by commit 83e8b90e1d2c ("scripts/config: use sed's POSIX interface").

Before that, the script used `-r' to enable ERE, which is indeed
non-portable. However, POSIX.1-2024 [1][2] has accepted `-E' as a
standard option to use ERE for matching, and major sed implementations
(GNU, FreeBSD, OpenBSD, NetBSD, macOS) have supported `-E' for over two
decades, so it makes no sense to use Basic Regular Expressions any more.
Hence, we can safely take the advantage of ERE and merge chained calls
to sed.

Before the said commit, the script used bare `-i' to skip creating a
backup file. In fact, major sed implementations have supported `-i' for
over a decade. It's really doubtful if anyone would still build Linux on
a Unix system without it. The issue is more about how we use it:

FreeBSD and macOS disallow bare `-i'. To skip creating a backup, an
empty string ("zero-length extension") must be passed as a separate
argument following `-i'.

GNU and other BSDs accept bare `-i' to skip creating a backup, but
disallow passing a zero-length extension.

That being said, when thinking about it optimistically, using `-i' is
portable as long as a backup is created. Hence, creating a backup file
with a .swp extension (the same name as the current temporary file)
anyway makes it portable. The backup file will be deleted on exit.

A rough benchmark with ~1000 editions showed a 48.6% speedup (8.78s =>
4.51s, GNU sed) in total. The FreeBSD sed showed a similar speedup.

I split the series into two patches so that PATCH 2 can be dropped if
strict POSIX compliance is desired.

Link: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html [1]
Link: https://austingroupbugs.net/view.php?id=528 [2]
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v2:
- Fix a typo in commit message (thanks Nicolas Schier)
- Do not delete .swp file when sed is not invoked, e.g., `--state'
  - In my test, unnecessarily deleting .swp file makes `--state' 10%
    slower due to the overhead of extra fork() and execve()
  - Unnecessarily deleting .swp file may corrupt Vim even if no editing
    command is passed
- Link to v1: https://patch.msgid.link/20260607-config-sed-v1-0-2ff7e35de271@rong.moe

---
Rong Zhang (2):
      scripts/config: Use POSIX standard ERE (-E) in sed
      scripts/config: Use in-place editing (-i) in sed portably

 scripts/config | 42 +++++++++++++++++++++++-------------------
 1 file changed, 23 insertions(+), 19 deletions(-)
---
base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
change-id: b2d6414d-config-sed-633649d7b0de

Thanks,
Rong

On Wed, 22 Jul 2026 01:50:47 +0800, Rong Zhang wrote:
> scripts/config: Use ERE (-E) and in-place editing (-i) in sed portably
> 
> The use of Extended Regular Expressions and in-place editing was removed
> by commit 83e8b90e1d2c ("scripts/config: use sed's POSIX interface").
> 
> Before that, the script used `-r' to enable ERE, which is indeed
> non-portable. However, POSIX.1-2024 [1][2] has accepted `-E' as a
> standard option to use ERE for matching, and major sed implementations
> (GNU, FreeBSD, OpenBSD, NetBSD, macOS) have supported `-E' for over two
> decades, so it makes no sense to use Basic Regular Expressions any more.
> Hence, we can safely take the advantage of ERE and merge chained calls
> to sed.
> 
> [...]

Applied to kbuild/linux.git (kbuild-next-unstable), thanks!

[1/2] scripts/config: Use POSIX standard ERE (-E) in sed
      https://git.kernel.org/kbuild/c/1d553517
[2/2] scripts/config: Use in-place editing (-i) in sed portably
      https://git.kernel.org/kbuild/c/005d6382

Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers).

Patches applied to the kbuild-next-unstable branch are accepted pending
wider testing in linux-next and any post-commit review; they will
generally be moved to the kbuild-next branch in about a week if no
issues are found.

Best regards,
-- 
Nicolas