With GNU sed: $ echo foo | sed -e 's/f.*/line1\nline2/' line1 line2
Even in strict POSIX mode: $ echo foo | POSIXLY_CORRECT=1 sed --posix -e 's/f.*/line1\nline2/' line1 line2 Whereas with OpenBSD sed and Solaris 11.4 sed: $ echo foo | sed -e 's/f.*/line1\nline2/' line1nline2 Here's a proposed patch to update the Autoconf documentation. Note: I think POSIX [1] mandates the behaviour of OpenBSD and Solaris sed. But that is not immediately relevant for the Autoconf manual: The portability problem exists regardless of how we might interpret POSIX. Bruno [1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html
>From 8b043c4d205620687b7635d40a599c9bc16c6e2f Mon Sep 17 00:00:00 2001 From: Bruno Haible <[email protected]> Date: Mon, 23 Jun 2025 23:29:29 +0200 Subject: [PATCH] doc: Document another portability pitfall of sed. * doc/autoconf.texi (Limitations of Usual Tools): Mention escape sequences in the replacement text of sed 's' commands. --- doc/autoconf.texi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/doc/autoconf.texi b/doc/autoconf.texi index 12734446..70217a7f 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -19743,6 +19743,10 @@ Avoid empty patterns within parentheses (i.e., @samp{\(\)}). POSIX does not require support for empty patterns, and Unicos 9 @command{sed} rejects them. +In the replacement text of an @samp{s}, it is not portable to use +escape sequences like @samp{\n}. While GNU @command{sed} interprets +them, the @command{sed} commands of OpenBSD and Solaris don't. + Unicos 9 @command{sed} loops endlessly on patterns like @samp{.*\n.*}. Sed scripts should not use branch labels longer than 7 characters and -- 2.43.0
