Subject: egrep is obsolescent

From: Tom Lane <[email-masked]>
Date: Wed, 13 May 2026 11:24:30 -0400

While running pgperltidy just now on my recently-updated
Linux workstation, I got

$ src/tools/pgindent/pgperltidy .
egrep: warning: egrep is obsolescent; using grep -E

OK, that's a bit in-your-face, but it's not inaccurate.
AFAICT, "egrep" has never been in POSIX, while "grep -E"
has been there at least since POSIX 2008.

So I propose the attached patch, which is just s/egrep/grep -E/g.

I did not touch the two usages in port/aix/mkldexport.sh, though.
I'm not sure what the standardization situation is in AIX, and
this warning doesn't seem like something they'd do anyway.

There is also a reference in configure, which is not a problem
because it tries "grep -E" first.

			regards, tom lane

diff --git a/doc/src/sgml/func/func-matching.sgml b/doc/src/sgml/func/func-matching.sgml
index af60e9898de..ae1dff66722 100644
--- a/doc/src/sgml/func/func-matching.sgml
+++ b/doc/src/sgml/func/func-matching.sgml
@@ -505,7 +505,7 @@ substring('foobar' SIMILAR '#"o_b#"%' ESCAPE '#')    <lineannotation>NULL</linea
      <acronym>POSIX</acronym> regular expressions provide a more
      powerful means for pattern matching than the <function>LIKE</function> and
      <function>SIMILAR TO</function> operators.
-     Many Unix tools such as <command>egrep</command>,
+     Many Unix tools such as <command>grep -E</command>,
      <command>sed</command>, or <command>awk</command> use a pattern
      matching language that is similar to the one described here.
     </para>
@@ -1065,7 +1065,7 @@ regexp_substr('ABCDEFGHI', '(c..)(...)', 1, 1, 'i', 2)
     Regular expressions (<acronym>RE</acronym>s), as defined in
     <acronym>POSIX</acronym> 1003.2, come in two forms:
     <firstterm>extended</firstterm> <acronym>RE</acronym>s or <acronym>ERE</acronym>s
-    (roughly those of <command>egrep</command>), and
+    (roughly those of <command>grep -E</command>), and
     <firstterm>basic</firstterm> <acronym>RE</acronym>s or <acronym>BRE</acronym>s
     (roughly those of <command>ed</command>).
     <productname>PostgreSQL</productname> supports both forms, and
diff --git a/src/tools/find_typedef b/src/tools/find_typedef
index 24e9b76651d..fec0520c32e 100755
--- a/src/tools/find_typedef
+++ b/src/tools/find_typedef
@@ -36,12 +36,12 @@ do	# if objdump -W is recognized, only one line of error should appear
 	if [ `objdump -W 2>&1 | wc -l` -eq 1 ]
 	then	# Linux
 		objdump -W "$DIR"/* |
-		egrep -A3 '\(DW_TAG_typedef\)' |
+		grep -E -A3 '\(DW_TAG_typedef\)' |
 		awk ' $2 == "DW_AT_name" {print $NF}'
 	elif [ `readelf -w 2>&1 | wc -l` -gt 1 ]
 	then	# FreeBSD, similar output to Linux
 		readelf -w "$DIR"/* |
-		egrep -A3 '\(DW_TAG_typedef\)' |
+		grep -E -A3 '\(DW_TAG_typedef\)' |
 		awk ' $1 == "DW_AT_name" {print $NF}'
 	fi
 done |
@@ -50,4 +50,4 @@ sort |
 uniq |
 # these are used both for typedefs and variable names
 # so do not include them
-egrep -v '^(date|interval|timestamp|ANY)$'
+grep -E -v '^(date|interval|timestamp|ANY)$'
diff --git a/src/tools/perlcheck/find_perl_files b/src/tools/perlcheck/find_perl_files
index 20dceb800d0..406ec7f3a08 100644
--- a/src/tools/perlcheck/find_perl_files
+++ b/src/tools/perlcheck/find_perl_files
@@ -12,7 +12,7 @@ find_perl_files () {
 		find "$@" -type f -name '*.p[lm]' -print
 		# take executable files that file(1) thinks are perl files
 		find "$@" -type f -perm -100 -exec file {} \; -print |
-		egrep -i ':.*perl[0-9]*\>' |
+		grep -E -i ':.*perl[0-9]*\>' |
 		cut -d: -f1
 	} | sort -u | grep -v '^\./\.git/'
 }

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 13 May 2026 17:32:28 +0200

> So I propose the attached patch, which is just s/egrep/grep -E/g.

Looks good to me.

> this warning doesn't seem like something they'd do anyway.

It appears that those invocations don't actually need the "e" part of 
egrep, so they could just be grep?

> because it tries "grep -E" first.

Yeah, Autoconf addressed this some decades ago, so it should be fine.

---

From: Tom Lane <[email-masked]>
Date: Wed, 13 May 2026 11:55:43 -0400

> egrep, so they could just be grep?

Oh, good point.  I'll make it so, just for cleanliness.

			regards, tom lane