* [PATCH 1/8] config: use grep -E instead of egrep
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
@ 2022-06-24 6:58 ` Xi Ruoyao
2022-06-24 7:00 ` [PATCH 2/8] fixincludes: use grep -E/-F instead of egrep/fgrep Xi Ruoyao
` (7 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 6:58 UTC (permalink / raw)
To: gcc-patches
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
ChangeLog:
* configure.ac: Use grep -E instead of egrep.
* config.rpath: Likewise.
* configure: Regenerate.
config/ChangeLog:
* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Use grep -E instead of egrep.
(acl_cv_path_LD): Likewise.
gcc/ChangeLog:
* configure: Regenerate.
intl/ChangeLog:
* configure: Regenerate.
libcpp/ChangeLog:
* configure: Regenerate.
libgcc/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
---
config.rpath | 8 ++++----
config/lib-ld.m4 | 4 ++--
configure | 4 ++--
configure.ac | 4 ++--
gcc/configure | 8 ++++----
intl/configure | 4 ++--
libcpp/configure | 4 ++--
libgcc/configure | 2 +-
libstdc++-v3/configure | 4 ++--
9 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/config.rpath b/config.rpath
index 4dea75957c2..20ffc3eb241 100755
--- a/config.rpath
+++ b/config.rpath
@@ -143,7 +143,7 @@ if test "$with_gnu_ld" = yes; then
ld_shlibs=no
;;
beos*)
- if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+ if $LD --help 2>&1 | grep -E ': supported targets:.* elf' > /dev/null; then
:
else
ld_shlibs=no
@@ -162,9 +162,9 @@ if test "$with_gnu_ld" = yes; then
netbsd*)
;;
solaris* | sysv5*)
- if $LD -v 2>&1 | egrep 'BFD 2\.8' > /dev/null; then
+ if $LD -v 2>&1 | grep -E 'BFD 2\.8' > /dev/null; then
ld_shlibs=no
- elif $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+ elif $LD --help 2>&1 | grep -E ': supported targets:.* elf' > /dev/null; then
:
else
ld_shlibs=no
@@ -174,7 +174,7 @@ if test "$with_gnu_ld" = yes; then
hardcode_direct=yes
;;
*)
- if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+ if $LD --help 2>&1 | grep -E ': supported targets:.* elf' > /dev/null; then
:
else
ld_shlibs=no
diff --git a/config/lib-ld.m4 b/config/lib-ld.m4
index 11d0ce77342..e536ff4d115 100644
--- a/config/lib-ld.m4
+++ b/config/lib-ld.m4
@@ -14,7 +14,7 @@ dnl From libtool-1.4. Sets the variable with_gnu_ld to yes or no.
AC_DEFUN([AC_LIB_PROG_LD_GNU],
[AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
[# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then
+if $LD -v 2>&1 </dev/null | grep -E '(GNU|with BFD)' 1>&5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
@@ -88,7 +88,7 @@ AC_CACHE_VAL(acl_cv_path_LD,
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > /dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | grep -E '(GNU|with BFD)' > /dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
diff --git a/configure b/configure
index 5dcaab14ae9..4a22d7ab3f0 100755
--- a/configure
+++ b/configure
@@ -9448,7 +9448,7 @@ if test x${use_gnu_as} = x &&
fi
if test x${use_gnu_ld} = x &&
- echo " ${configdirs} " | egrep " (go)?ld " > /dev/null 2>&1 ; then
+ echo " ${configdirs} " | grep -E " (go)?ld " > /dev/null 2>&1 ; then
with_gnu_ld=yes
extra_host_args="$extra_host_args --with-gnu-ld"
fi
@@ -10620,7 +10620,7 @@ case " $build_configdirs " in
# For an installed makeinfo, we require it to be from texinfo 4.7 or
# higher, else we use the "missing" dummy.
if ${MAKEINFO} --version \
- | egrep 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' >/dev/null 2>&1; then
+ | grep -E 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' >/dev/null 2>&1; then
:
else
MAKEINFO="$MISSING makeinfo"
diff --git a/configure.ac b/configure.ac
index 85977482aee..06ffa5afbe8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2634,7 +2634,7 @@ if test x${use_gnu_as} = x &&
fi
if test x${use_gnu_ld} = x &&
- echo " ${configdirs} " | egrep " (go)?ld " > /dev/null 2>&1 ; then
+ echo " ${configdirs} " | grep -E " (go)?ld " > /dev/null 2>&1 ; then
with_gnu_ld=yes
extra_host_args="$extra_host_args --with-gnu-ld"
fi
@@ -3549,7 +3549,7 @@ changequote(,)
# For an installed makeinfo, we require it to be from texinfo 4.7 or
# higher, else we use the "missing" dummy.
if ${MAKEINFO} --version \
- | egrep 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' >/dev/null 2>&1; then
+ | grep -E 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' >/dev/null 2>&1; then
:
else
MAKEINFO="$MISSING makeinfo"
diff --git a/gcc/configure b/gcc/configure
index f43dc989d02..baeffd79d06 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -11160,7 +11160,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > /dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | grep -E '(GNU|with BFD)' > /dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -11188,7 +11188,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then
+if $LD -v 2>&1 </dev/null | grep -E '(GNU|with BFD)' 1>&5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
@@ -19674,7 +19674,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 19679 "configure"
+#line 19677 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -19780,7 +19780,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 19785 "configure"
+#line 19783 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
diff --git a/intl/configure b/intl/configure
index 03f40487a92..2c5e49839b4 100755
--- a/intl/configure
+++ b/intl/configure
@@ -5090,7 +5090,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > /dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | grep -E '(GNU|with BFD)' > /dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -5118,7 +5118,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then
+if $LD -v 2>&1 </dev/null | grep -E '(GNU|with BFD)' 1>&5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
diff --git a/libcpp/configure b/libcpp/configure
index 75145390215..d3beed1703a 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -6807,7 +6807,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > /dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | grep -E '(GNU|with BFD)' > /dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -6835,7 +6835,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then
+if $LD -v 2>&1 </dev/null | grep -E '(GNU|with BFD)' 1>&5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
diff --git a/libgcc/configure b/libgcc/configure
index 61f3ace2891..a52967804ce 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -5032,7 +5032,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then
+if $LD -v 2>&1 </dev/null | grep -E '(GNU|with BFD)' 1>&5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index eac60392121..e3304dd2605 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -28473,7 +28473,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > /dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | grep -E '(GNU|with BFD)' > /dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -28501,7 +28501,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 </dev/null | egrep '(GNU|with BFD)' 1>&5; then
+if $LD -v 2>&1 </dev/null | grep -E '(GNU|with BFD)' 1>&5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH 2/8] fixincludes: use grep -E/-F instead of egrep/fgrep
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
2022-06-24 6:58 ` [PATCH 1/8] config: use grep -E instead of egrep Xi Ruoyao
@ 2022-06-24 7:00 ` Xi Ruoyao
2022-06-24 7:02 ` [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts Xi Ruoyao
` (6 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:00 UTC (permalink / raw)
To: gcc-patches
egrep/fgrep has been deprecated in favor of grep -E/-F for a long time,
and the next grep release (3.8 or 4.0) will print a warning if egrep or
fgrep is used. Stop using egrep and fgrep so we won't see the warning.
fixincludes/ChangeLog:
* fixinc.in: Use grep -E instead of egrep.
* inclhack.def: Likewise.
* fixincl.x: Regenerate.
* genfixes: Use grep -F instead of fgrep.
---
fixincludes/fixinc.in | 2 +-
fixincludes/fixincl.x | 10 +++++-----
fixincludes/genfixes | 2 +-
fixincludes/inclhack.def | 6 +++---
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index 0bd8027a554..b5395805cce 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -448,7 +448,7 @@ while [ $# != 0 ]; do
chmod a+r $3 2>/dev/null
if test $VERBOSE -gt 2
then echo Copied $2 ; fi
- for include in `egrep '^[ ]*#[ ]*include[ ]*"[^/]' $3 |
+ for include in `grep -E '^[ ]*#[ ]*include[ ]*"[^/]' $3 |
sed -e 's/^[ ]*#[ ]*include[ ]*"\([^"]*\)".*$/\1/'`
do
dir=`echo $2 | sed -e s'|/[^/]*$||'`
diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index bad490453b7..babd83ebd08 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
*
* DO NOT EDIT THIS FILE (fixincl.x)
*
- * It has been AutoGen-ed February 27, 2022 at 07:47:03 PM by AutoGen 5.18.16
+ * It has been AutoGen-ed June 24, 2022 at 01:40:08 PM by AutoGen 5.18.16
* From the definitions inclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Sun Feb 27 19:47:03 UTC 2022
+/* DO NOT SVN-MERGE THIS FILE, EITHER Fri Jun 24 13:40:08 CST 2022
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -6547,7 +6547,7 @@ static tTestDesc aMath_Huge_Val_From_Dbl_MaxTests[] = {
* Fix Command Arguments for Math_Huge_Val_From_Dbl_Max
*/
static const char* apzMath_Huge_Val_From_Dbl_MaxPatch[] = { "sh", "-c",
- "\tdbl_max_def=`egrep 'define[ \t]+DBL_MAX[ \t]+.*' float.h | sed 's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n\
+ "\tdbl_max_def=`grep -E 'define[ \t]+DBL_MAX[ \t]+.*' float.h | sed 's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n\
\tif ( test -n \"${dbl_max_def}\" ) > /dev/null 2>&1\n\
\tthen sed -e '/define[ \t]*HUGE_VAL[ \t]*DBL_MAX/s@DBL_MAX@'\"$dbl_max_def@\"\n\
\telse cat\n\
@@ -10402,9 +10402,9 @@ tSCC zVxworks_Needs_VxworksSelect0[] =
tSCC zVxworks_Needs_VxworksTest0[] =
" -r types/vxTypesOld.h";
tSCC zVxworks_Needs_VxworksTest1[] =
- " -n \"`egrep '#include' $file`\"";
+ " -n \"`grep -E '#include' $file`\"";
tSCC zVxworks_Needs_VxworksTest2[] =
- " -n \"`egrep ULONG $file`\"";
+ " -n \"`grep -E ULONG $file`\"";
#define VXWORKS_NEEDS_VXWORKS_TEST_CT 4
static tTestDesc aVxworks_Needs_VxworksTests[] = {
diff --git a/fixincludes/genfixes b/fixincludes/genfixes
index 47aad01289d..d2cbb50c39b 100755
--- a/fixincludes/genfixes
+++ b/fixincludes/genfixes
@@ -58,7 +58,7 @@ done
AG="autogen $AG"
set -e
-if [ -z "`${AG} -v | fgrep ' 5.'`" ]
+if [ -z "`${AG} -v | grep -F ' 5.'`" ]
then
echo "AutoGen appears to be out of date or not correctly installed."
echo "Please download and install from:"
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 7605ac89aa2..7b0f7cae0b1 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -3274,7 +3274,7 @@ fix = {
* If we do, we will replace the one in math.h with that one.
*/
- "\tdbl_max_def=`egrep 'define[ \t]+DBL_MAX[ \t]+.*' float.h "
+ "\tdbl_max_def=`grep -E 'define[ \t]+DBL_MAX[ \t]+.*' float.h "
"| sed 's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n"
"\tif ( test -n \"${dbl_max_def}\" ) > /dev/null 2>&1\n"
@@ -5266,8 +5266,8 @@ fix = {
hackname = vxworks_needs_vxworks;
files = sys/stat.h;
test = " -r types/vxTypesOld.h";
- test = " -n \"`egrep '#include' $file`\"";
- test = " -n \"`egrep ULONG $file`\"";
+ test = " -n \"`grep -E '#include' $file`\"";
+ test = " -n \"`grep -E ULONG $file`\"";
select = "#[ \t]define[ \t]+__INCstath";
sed = "/#[ \t]define[ \t][ \t]*__INCstath/a\\\n"
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
2022-06-24 6:58 ` [PATCH 1/8] config: use grep -E instead of egrep Xi Ruoyao
2022-06-24 7:00 ` [PATCH 2/8] fixincludes: use grep -E/-F instead of egrep/fgrep Xi Ruoyao
@ 2022-06-24 7:02 ` Xi Ruoyao
2022-06-24 10:00 ` Jonathan Wakely
2022-06-24 7:04 ` [PATCH 4/8] libbacktrace: use grep -F instead of fgrep Xi Ruoyao
` (5 subsequent siblings)
8 siblings, 1 reply; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:02 UTC (permalink / raw)
To: gcc-patches; +Cc: libstdc++
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
libstdc++-v3/ChangeLog:
* scripts/extract_symvers.in: Use grep -E instead of egrep.
* libstdc++-v3/scripts/run_doxygen: Likewise.
---
| 4 ++--
libstdc++-v3/scripts/run_doxygen | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--git a/libstdc++-v3/scripts/extract_symvers.in b/libstdc++-v3/scripts/extract_symvers.in
index dd9f63d4f16..d8ea62355ae 100755
--- a/libstdc++-v3/scripts/extract_symvers.in
+++ b/libstdc++-v3/scripts/extract_symvers.in
@@ -54,8 +54,8 @@ SunOS)
${readelf} ${lib} |\
sed -e 's/ \[<other>: [A-Fa-f0-9]*\] //' -e '/\.dynsym/,/^$/p;d' |\
sed -e 's/ \[<localentry>: [0-9]*\] //' |\
- egrep -v ' (LOCAL|UND) ' |\
- egrep -v ' (_DYNAMIC|_GLOBAL_OFFSET_TABLE_|_PROCEDURE_LINKAGE_TABLE_|_edata|_end|_etext)$' |\
+ grep -E -v ' (LOCAL|UND) ' |\
+ grep -E -v ' (_DYNAMIC|_GLOBAL_OFFSET_TABLE_|_PROCEDURE_LINKAGE_TABLE_|_edata|_end|_etext)$' |\
sed -e 's/ <processor specific>: / <processor_specific>:_/g' |\
sed -e 's/ <OS specific>: / <OS_specific>:_/g' |\
sed -e 's/ <unknown>: / <unknown>:_/g' |\
diff --git a/libstdc++-v3/scripts/run_doxygen b/libstdc++-v3/scripts/run_doxygen
index 86da071d86c..50514c744c9 100644
--- a/libstdc++-v3/scripts/run_doxygen
+++ b/libstdc++-v3/scripts/run_doxygen
@@ -291,7 +291,7 @@ cxxflags="-Og -g -std=gnu++23"
$gxx $cppflags $cxxflags ${srcdir}/doc/doxygen/stdheader.cc -o ./stdheader || exit 1
# Doxygen outputs something like "\fC#include <unique_lock\&.h>\fP" and
# we want that internal header to be replaced with something like <mutex>.
-problematic=`egrep -l '#include <.*h>' [a-z]*.3`
+problematic=`grep -E -l '#include <.*h>' [a-z]*.3`
for f in $problematic; do
# this is also slow, but safe and easy to debug
oldh=`sed -n '/fC#include </s/.*<\(.*\)>.*/\1/p' $f`
@@ -303,7 +303,7 @@ rm stdheader
# Some of the pages for generated modules have text that confuses certain
# implementations of man(1), e.g. on GNU/Linux. We need to have another
# top-level *roff tag to /stop/ the .SH NAME entry.
-problematic=`egrep --files-without-match '^\.SH SYNOPSIS' [A-Z]*.3`
+problematic=`grep -E --files-without-match '^\.SH SYNOPSIS' [A-Z]*.3`
#problematic='Containers.3 Sequences.3 Assoc_containers.3 Iterator_types.3'
for f in $problematic; do
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 7:02 ` [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts Xi Ruoyao
@ 2022-06-24 10:00 ` Jonathan Wakely
2022-06-24 11:08 ` Xi Ruoyao
0 siblings, 1 reply; 32+ messages in thread
From: Jonathan Wakely @ 2022-06-24 10:00 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: gcc-patches, libstdc++
On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> egrep has been deprecated in favor of grep -E for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of egrep is used.
> Stop using egrep so we won't see the warning.
>
> libstdc++-v3/ChangeLog:
>
> * scripts/extract_symvers.in: Use grep -E instead of egrep.
> * libstdc++-v3/scripts/run_doxygen: Likewise.
This should be just scripts/run_doxygen here. You can use the git
gcc-verify alias to check your changelog format.
With that fixed it's OK for trunk and gcc-12 and gcc-11 branches, thanks!
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 10:00 ` Jonathan Wakely
@ 2022-06-24 11:08 ` Xi Ruoyao
2022-06-24 11:18 ` Jonathan Wakely
0 siblings, 1 reply; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 11:08 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-patches, libstdc++, Rainer Orth
On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > egrep has been deprecated in favor of grep -E for a long time, and
> > the
> > next grep release (3.8 or 4.0) will print a warning of egrep is
> > used.
> > Stop using egrep so we won't see the warning.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * scripts/extract_symvers.in: Use grep -E instead of egrep.
> > * libstdc++-v3/scripts/run_doxygen: Likewise.
>
> This should be just scripts/run_doxygen here. You can use the git
> gcc-verify alias to check your changelog format.
>
>
> With that fixed it's OK for trunk and gcc-12 and gcc-11 branches,
> thanks!
I'll need some rework as Rainer told me "grep -E" may not work on some
Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
is exactly for Solaris...
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 11:08 ` Xi Ruoyao
@ 2022-06-24 11:18 ` Jonathan Wakely
2022-06-24 11:35 ` Jonathan Wakely
0 siblings, 1 reply; 32+ messages in thread
From: Jonathan Wakely @ 2022-06-24 11:18 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: Jonathan Wakely, libstdc++, gcc-patches, Rainer Orth
On Fri, 24 Jun 2022 at 12:08, Xi Ruoyao via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> > On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> > <libstdc++@gcc.gnu.org> wrote:
> > >
> > > egrep has been deprecated in favor of grep -E for a long time, and
> > > the
> > > next grep release (3.8 or 4.0) will print a warning of egrep is
> > > used.
> > > Stop using egrep so we won't see the warning.
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > > * scripts/extract_symvers.in: Use grep -E instead of egrep.
> > > * libstdc++-v3/scripts/run_doxygen: Likewise.
> >
> > This should be just scripts/run_doxygen here. You can use the git
> > gcc-verify alias to check your changelog format.
> >
> >
> > With that fixed it's OK for trunk and gcc-12 and gcc-11 branches,
> > thanks!
>
> I'll need some rework as Rainer told me "grep -E" may not work on some
> Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> is exactly for Solaris...
I checked that, and it's not :-)
The egrep uses in extract_symvers.in are for everything *except*
SunOS. For Solaris we use the scripts/extract_symvers.pl script
instead.
Your change might break generation of Doxygen API docs on Solaris, but
maybe we can live with that.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 11:18 ` Jonathan Wakely
@ 2022-06-24 11:35 ` Jonathan Wakely
2022-06-24 11:41 ` Rainer Orth
0 siblings, 1 reply; 32+ messages in thread
From: Jonathan Wakely @ 2022-06-24 11:35 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: Jonathan Wakely, libstdc++, gcc-patches, Rainer Orth
On Fri, 24 Jun 2022 at 12:18, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Fri, 24 Jun 2022 at 12:08, Xi Ruoyao via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> > > On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> > > <libstdc++@gcc.gnu.org> wrote:
> > > >
> > > > egrep has been deprecated in favor of grep -E for a long time, and
> > > > the
> > > > next grep release (3.8 or 4.0) will print a warning of egrep is
> > > > used.
> > > > Stop using egrep so we won't see the warning.
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > * scripts/extract_symvers.in: Use grep -E instead of egrep.
> > > > * libstdc++-v3/scripts/run_doxygen: Likewise.
> > >
> > > This should be just scripts/run_doxygen here. You can use the git
> > > gcc-verify alias to check your changelog format.
> > >
> > >
> > > With that fixed it's OK for trunk and gcc-12 and gcc-11 branches,
> > > thanks!
> >
> > I'll need some rework as Rainer told me "grep -E" may not work on some
> > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> > is exactly for Solaris...
>
> I checked that, and it's not :-)
>
> The egrep uses in extract_symvers.in are for everything *except*
> SunOS. For Solaris we use the scripts/extract_symvers.pl script
> instead.
>
> Your change might break generation of Doxygen API docs on Solaris, but
> maybe we can live with that.
/usr/xpg4/bin/grep supports the -E flag, so I was going to say that
it's acceptable to require that version in the PATH when generating
the API docs with doxygen. But in fact that script already assumes GNU
grep anyway, using egrep --files-without-match and POSIX grep does not
support --files-without-match, or the short form of that option, -L.
And in fact, neither of the uses of egrep in scripts/run_doxygen
actually needs to use extended regular expressions. Plain ol' grep
with Basic Regular Expressions will work fine:
problematic=`egrep -l '#include <.*h>' [a-z]*.3`
problematic=`egrep --files-without-match '^\.SH SYNOPSIS' [A-Z]*.3`
There are no ERE special characters here, so itcould just use 'grep'
not 'egrep'. And it won't work with Solaris grep anyway.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 11:35 ` Jonathan Wakely
@ 2022-06-24 11:41 ` Rainer Orth
2022-06-24 12:37 ` Xi Ruoyao
0 siblings, 1 reply; 32+ messages in thread
From: Rainer Orth @ 2022-06-24 11:41 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Xi Ruoyao, Jonathan Wakely, libstdc++, gcc-patches
Hi Jonathan,
>> > I'll need some rework as Rainer told me "grep -E" may not work on some
>> > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
>> > is exactly for Solaris...
>>
>> I checked that, and it's not :-)
>>
>> The egrep uses in extract_symvers.in are for everything *except*
>> SunOS. For Solaris we use the scripts/extract_symvers.pl script
>> instead.
>>
>> Your change might break generation of Doxygen API docs on Solaris, but
>> maybe we can live with that.
>
> /usr/xpg4/bin/grep supports the -E flag, so I was going to say that
> it's acceptable to require that version in the PATH when generating
> the API docs with doxygen. But in fact that script already assumes GNU
indeed: for a niche/developer-only use, the bar of tool requirements can
be higher IMO. Besides, /usr/gnu/bin/grep is there, too (or could be;
both /usr/xpg4/bin/grep and /usr/gnu/bin/grep live in separate packages
that may or may not be installed).
I just want to make the entry barries for normal builds as low as
possible.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 11:41 ` Rainer Orth
@ 2022-06-24 12:37 ` Xi Ruoyao
2022-06-24 12:38 ` Jonathan Wakely
0 siblings, 1 reply; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 12:37 UTC (permalink / raw)
To: Rainer Orth, Jonathan Wakely; +Cc: Jonathan Wakely, libstdc++, gcc-patches
On Fri, 2022-06-24 at 13:41 +0200, Rainer Orth wrote:
> Hi Jonathan,
>
> > > > I'll need some rework as Rainer told me "grep -E" may not work on some
> > > > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> > > > is exactly for Solaris...
> > >
> > > I checked that, and it's not :-)
> > >
> > > The egrep uses in extract_symvers.in are for everything *except*
> > > SunOS. For Solaris we use the scripts/extract_symvers.pl script
> > > instead.
I misread the case statement :(.
> > > Your change might break generation of Doxygen API docs on Solaris, but
> > > maybe we can live with that.
> >
> > /usr/xpg4/bin/grep supports the -E flag, so I was going to say that
> > it's acceptable to require that version in the PATH when generating
> > the API docs with doxygen. But in fact that script already assumes GNU
>
> indeed: for a niche/developer-only use, the bar of tool requirements can
> be higher IMO. Besides, /usr/gnu/bin/grep is there, too (or could be;
> both /usr/xpg4/bin/grep and /usr/gnu/bin/grep live in separate packages
> that may or may not be installed).
>
> I just want to make the entry barries for normal builds as low as
> possible.
Pushed as r13-1242 with ChangeLog fix, as compatibility-related stuff
"resolved" and this does not depend on other patches in the series.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts
2022-06-24 12:37 ` Xi Ruoyao
@ 2022-06-24 12:38 ` Jonathan Wakely
0 siblings, 0 replies; 32+ messages in thread
From: Jonathan Wakely @ 2022-06-24 12:38 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: Rainer Orth, Jonathan Wakely, libstdc++, gcc-patches
On Fri, 24 Jun 2022 at 13:37, Xi Ruoyao <xry111@xry111.site> wrote:
>
> On Fri, 2022-06-24 at 13:41 +0200, Rainer Orth wrote:
> > Hi Jonathan,
> >
> > > > > I'll need some rework as Rainer told me "grep -E" may not work on some
> > > > > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> > > > > is exactly for Solaris...
> > > >
> > > > I checked that, and it's not :-)
> > > >
> > > > The egrep uses in extract_symvers.in are for everything *except*
> > > > SunOS. For Solaris we use the scripts/extract_symvers.pl script
> > > > instead.
>
> I misread the case statement :(.
>
> > > > Your change might break generation of Doxygen API docs on Solaris, but
> > > > maybe we can live with that.
> > >
> > > /usr/xpg4/bin/grep supports the -E flag, so I was going to say that
> > > it's acceptable to require that version in the PATH when generating
> > > the API docs with doxygen. But in fact that script already assumes GNU
> >
> > indeed: for a niche/developer-only use, the bar of tool requirements can
> > be higher IMO. Besides, /usr/gnu/bin/grep is there, too (or could be;
> > both /usr/xpg4/bin/grep and /usr/gnu/bin/grep live in separate packages
> > that may or may not be installed).
> >
> > I just want to make the entry barries for normal builds as low as
> > possible.
>
> Pushed as r13-1242 with ChangeLog fix, as compatibility-related stuff
> "resolved" and this does not depend on other patches in the series.
Great, thanks!
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 4/8] libbacktrace: use grep -F instead of fgrep
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
` (2 preceding siblings ...)
2022-06-24 7:02 ` [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts Xi Ruoyao
@ 2022-06-24 7:04 ` Xi Ruoyao
2022-06-24 7:05 ` [PATCH 5/8] intl: stop using fgrep for exgettext Xi Ruoyao
` (4 subsequent siblings)
8 siblings, 0 replies; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:04 UTC (permalink / raw)
To: gcc-patches
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.
libbacktrace/ChangeLog:
* configure.ac: Use grep -F instead of fgrep.
* configure: Regenerate.
---
libbacktrace/configure | 2 +-
libbacktrace/configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 17f470a4bec..45173b08fb6 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -13831,7 +13831,7 @@ else
libbacktrace_cv_objcopy_debuglink=no
elif ! test -n "${OBJCOPY}"; then
libbacktrace_cv_objcopy_debuglink=no
-elif ${OBJCOPY} --help | fgrep add-gnu-debuglink >/dev/null 2>&1; then
+elif ${OBJCOPY} --help | grep -F add-gnu-debuglink >/dev/null 2>&1;
then
libbacktrace_cv_objcopy_debuglink=yes
else
libbacktrace_cv_objcopy_debuglink=no
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 597c9705db8..bcce4f31b85 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -500,7 +500,7 @@ AC_CACHE_CHECK([whether objcopy supports debuglink],
libbacktrace_cv_objcopy_debuglink=no
elif ! test -n "${OBJCOPY}"; then
libbacktrace_cv_objcopy_debuglink=no
-elif ${OBJCOPY} --help | fgrep add-gnu-debuglink >/dev/null 2>&1; then
+elif ${OBJCOPY} --help | grep -F add-gnu-debuglink >/dev/null 2>&1;
then
libbacktrace_cv_objcopy_debuglink=yes
else
libbacktrace_cv_objcopy_debuglink=no
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH 5/8] intl: stop using fgrep for exgettext
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
` (3 preceding siblings ...)
2022-06-24 7:04 ` [PATCH 4/8] libbacktrace: use grep -F instead of fgrep Xi Ruoyao
@ 2022-06-24 7:05 ` Xi Ruoyao
2022-06-24 16:06 ` Joseph Myers
2022-06-24 7:06 ` [PATCH 6/8] fortran: use grep -F instead of fgrep Xi Ruoyao
` (3 subsequent siblings)
8 siblings, 1 reply; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:05 UTC (permalink / raw)
To: gcc-patches
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
And, the fgrep command in exgettext is no longer useful after we
migrated from SVN to Git. Remove the fgrep command so we won't see the
warning.
gcc/ChangeLog:
* po/exgettext: Remove unneeded fgrep command.
---
gcc/po/exgettext | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/po/exgettext b/gcc/po/exgettext
index 95cb0e75554..43b2e81bd24 100644
--- a/gcc/po/exgettext
+++ b/gcc/po/exgettext
@@ -99,7 +99,7 @@ echo "scanning for keywords, %e and %n strings..." >&2
lang_subdirs=`echo */config-lang.in */*/config-lang.in | sed -e 's|/config-lang\.in||g'`
{ for dir in "" c-family/ common/ common/config/ common/config/*/ \
config/ config/*/ \
- `find $lang_subdirs -type d -print | fgrep -v .svn | sort | sed -e 's|$|/|'`
+ `find $lang_subdirs -type d -print | sort | sed -e 's|$|/|'`
do for glob in '*.c' '*.cc' '*.h' '*.def'
do eval echo $dir$glob
done
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 5/8] intl: stop using fgrep for exgettext
2022-06-24 7:05 ` [PATCH 5/8] intl: stop using fgrep for exgettext Xi Ruoyao
@ 2022-06-24 16:06 ` Joseph Myers
2022-06-25 4:00 ` Xi Ruoyao
0 siblings, 1 reply; 32+ messages in thread
From: Joseph Myers @ 2022-06-24 16:06 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: gcc-patches
On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches wrote:
> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> And, the fgrep command in exgettext is no longer useful after we
> migrated from SVN to Git. Remove the fgrep command so we won't see the
> warning.
>
> gcc/ChangeLog:
>
> * po/exgettext: Remove unneeded fgrep command.
OK.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 5/8] intl: stop using fgrep for exgettext
2022-06-24 16:06 ` Joseph Myers
@ 2022-06-25 4:00 ` Xi Ruoyao
0 siblings, 0 replies; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-25 4:00 UTC (permalink / raw)
To: Joseph Myers; +Cc: gcc-patches
On Fri, 2022-06-24 at 16:06 +0000, Joseph Myers wrote:
> On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches wrote:
>
> > fgrep has been deprecated in favor of grep -F for a long time, and
> > the
> > next grep release (3.8 or 4.0) will print a warning of fgrep is
> > used.
> > And, the fgrep command in exgettext is no longer useful after we
> > migrated from SVN to Git. Remove the fgrep command so we won't see
> > the
> > warning.
> >
> > gcc/ChangeLog:
> >
> > * po/exgettext: Remove unneeded fgrep command.
>
> OK.
Pushed as r13-1264 with ChangeLog fix (gcc/po/ChangeLog should be used),
as it does not depend on other parts in the series.
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 6/8] fortran: use grep -F instead of fgrep
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
` (4 preceding siblings ...)
2022-06-24 7:05 ` [PATCH 5/8] intl: stop using fgrep for exgettext Xi Ruoyao
@ 2022-06-24 7:06 ` Xi Ruoyao
2022-06-24 11:13 ` Bernhard Reutner-Fischer
2022-06-24 7:09 ` [PATCH 7/8] testsuite: use grep -E instead of egrep Xi Ruoyao
` (2 subsequent siblings)
8 siblings, 1 reply; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:06 UTC (permalink / raw)
To: gcc-patches
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.
gcc/ChangeLog:
* fortran/Make-lang.in: Use grep -F instead of fgrep.
---
gcc/fortran/Make-lang.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
index 1cb47cb1a52..51279b03aad 100644
--- a/gcc/fortran/Make-lang.in
+++ b/gcc/fortran/Make-lang.in
@@ -278,7 +278,7 @@ $(DESTDIR)$(man1dir)/$(GFORTRAN_INSTALL_NAME)$(man1ext): doc/gfortran.1 \
-chmod a-x $@
fortran.uninstall:
- if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
+ if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' >/dev/null 2>&1; then \
echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info"; \
install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info || : ; \
else : ; fi; \
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
2022-06-24 7:06 ` [PATCH 6/8] fortran: use grep -F instead of fgrep Xi Ruoyao
@ 2022-06-24 11:13 ` Bernhard Reutner-Fischer
2022-06-24 12:22 ` Xi Ruoyao
0 siblings, 1 reply; 32+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-06-24 11:13 UTC (permalink / raw)
To: Xi Ruoyao via Gcc-patches; +Cc: rep.dot.nop, Xi Ruoyao, fortran
On Fri, 24 Jun 2022 15:06:32 +0800
Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> Stop using fgrep so we won't see the warning.
>
> gcc/ChangeLog:
>
> * fortran/Make-lang.in: Use grep -F instead of fgrep.
> ---
> gcc/fortran/Make-lang.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
> index 1cb47cb1a52..51279b03aad 100644
> --- a/gcc/fortran/Make-lang.in
> +++ b/gcc/fortran/Make-lang.in
> @@ -278,7 +278,7 @@ $(DESTDIR)$(man1dir)/$(GFORTRAN_INSTALL_NAME)$(man1ext): doc/gfortran.1 \
> -chmod a-x $@
>
> fortran.uninstall:
> - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
> + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' >/dev/null 2>&1; then \
> echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info"; \
> install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info || : ; \
> else : ; fi; \
I'd replace -s >/dev/null 2>&1 with -q while at it.
But why is -F used here in the first place?
I do not see much in debian that can be interpreted as a regex?
thanks,
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
2022-06-24 11:13 ` Bernhard Reutner-Fischer
@ 2022-06-24 12:22 ` Xi Ruoyao
2022-06-24 12:35 ` Rainer Orth
2022-06-24 13:58 ` Thomas Koenig
0 siblings, 2 replies; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 12:22 UTC (permalink / raw)
To: Bernhard Reutner-Fischer, Rainer Orth; +Cc: fortran, gcc-patches
On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
> > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' >/dev/null 2>&1; then \
> > echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info"; \
> > install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info || : ; \
> > else : ; fi; \
>
> I'd replace -s >/dev/null 2>&1 with -q while at it.
>
> But why is -F used here in the first place?
> I do not see much in debian that can be interpreted as a regex?
I'm not sure. It was there since 2004. Perhaps the author thinks fgrep
may save several CPU cycles :). I'll just use a plain grep in PATCH v2.
Rainer: do you have some idea about the availability of "-q" on
different hosts? If you agree I'll use it instead of -s > /dev/null
too.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
2022-06-24 12:22 ` Xi Ruoyao
@ 2022-06-24 12:35 ` Rainer Orth
2022-06-24 18:30 ` Bernhard Reutner-Fischer
2022-06-24 13:58 ` Thomas Koenig
1 sibling, 1 reply; 32+ messages in thread
From: Rainer Orth @ 2022-06-24 12:35 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: Bernhard Reutner-Fischer, fortran, gcc-patches
Hi Xi,
> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>
>> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>> > -i debian' >/dev/null 2>&1; then \
>> > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v
>> > -i debian' >/dev/null 2>&1; then \
>> > echo " install-info --delete --info-dir=$(DESTDIR)$(infodir)
>> > $(DESTDIR)$(infodir)/gfortran.info"; \
>> > install-info --delete --info-dir=$(DESTDIR)$(infodir)
>> > $(DESTDIR)$(infodir)/gfortran.info || : ; \
>> > else : ; fi; \
>>
>> I'd replace -s >/dev/null 2>&1 with -q while at it.
>>
>> But why is -F used here in the first place?
>> I do not see much in debian that can be interpreted as a regex?
>
> I'm not sure. It was there since 2004. Perhaps the author thinks fgrep
> may save several CPU cycles :). I'll just use a plain grep in PATCH v2.
>
> Rainer: do you have some idea about the availability of "-q" on
> different hosts? If you agree I'll use it instead of -s > /dev/null
> too.
again, the autoconf manual warns agains it, even more so against -s.
That's the first reference for portability issues and shouldn't be
ignored without good reason.
In the GCC and Solaris context, /bin/grep supports both -q and -s in
Solaris 11.3 and 11.4. It doesn't support -q on Solaris 10, though
(again, no longer relevant for GCC).
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
2022-06-24 12:35 ` Rainer Orth
@ 2022-06-24 18:30 ` Bernhard Reutner-Fischer
0 siblings, 0 replies; 32+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-06-24 18:30 UTC (permalink / raw)
To: Rainer Orth, Xi Ruoyao; +Cc: fortran, gcc-patches
On 24 June 2022 14:35:20 CEST, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>Hi Xi,
>
>> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>>
>>> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>>> > -i debian' >/dev/null 2>&1; then \
>>> > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v
>>> > -i debian' >/dev/null 2>&1; then \
>>> > echo " install-info --delete --info-dir=$(DESTDIR)$(infodir)
>>> > $(DESTDIR)$(infodir)/gfortran.info"; \
>>> > install-info --delete --info-dir=$(DESTDIR)$(infodir)
>>> > $(DESTDIR)$(infodir)/gfortran.info || : ; \
>>> > else : ; fi; \
>>>
>>> I'd replace -s >/dev/null 2>&1 with -q while at it.
>>>
>>> But why is -F used here in the first place?
>>> I do not see much in debian that can be interpreted as a regex?
>>
>> I'm not sure. It was there since 2004. Perhaps the author thinks fgrep
>> may save several CPU cycles :). I'll just use a plain grep in PATCH v2.
>>
>> Rainer: do you have some idea about the availability of "-q" on
>> different hosts? If you agree I'll use it instead of -s > /dev/null
>> too.
>
>again, the autoconf manual warns agains it, even more so against -s.
>That's the first reference for portability issues and shouldn't be
>ignored without good reason.
>
>In the GCC and Solaris context, /bin/grep supports both -q and -s in
>Solaris 11.3 and 11.4. It doesn't support -q on Solaris 10, though
>(again, no longer relevant for GCC).
The good reason I would bring forward is that the systems mentioned in the autoconf docs are all not supported anymore (IRIX, ancient or old Solaris etc).
Furthermore, grep(1) is required by POSIX to support -q since at least 1997; see https://pubs.opengroup.org/onlinepubs/007908799/xcu/grep.html
That's about 25 years now, so everybody had plenty of time to implement this specific part, which is even trivial to implement for this particular case of grep -q.
All in all i think that we should not be held hostage by such systems any longer, at least for such cases that are trivial to fix to conformance. Of course that may be just /me.
Iff fixing egrep or fgrep occurrences though, we should use plain grep where applicable, like in this case, IMO.
thanks,
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
2022-06-24 12:22 ` Xi Ruoyao
2022-06-24 12:35 ` Rainer Orth
@ 2022-06-24 13:58 ` Thomas Koenig
1 sibling, 0 replies; 32+ messages in thread
From: Thomas Koenig @ 2022-06-24 13:58 UTC (permalink / raw)
To: Xi Ruoyao, Bernhard Reutner-Fischer, Rainer Orth; +Cc: gcc-patches, fortran
Hi,
> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>
>>> - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
>>> + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' >/dev/null 2>&1; then \
>>> echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info"; \
>>> install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info || : ; \
>>> else : ; fi; \
>>
>> I'd replace -s >/dev/null 2>&1 with -q while at it.
>>
>> But why is -F used here in the first place?
>> I do not see much in debian that can be interpreted as a regex?
>
> I'm not sure. It was there since 2004. Perhaps the author thinks fgrep
> may save several CPU cycles :). I'll just use a plain grep in PATCH v2.
>
> Rainer: do you have some idea about the availability of "-q" on
> different hosts? If you agree I'll use it instead of -s > /dev/null
> too.
Is there any particular reason why we should not use the result of
AC_PROG_FGREP ? AC_PROG_GREP should also work.
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 7/8] testsuite: use grep -E instead of egrep
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
` (5 preceding siblings ...)
2022-06-24 7:06 ` [PATCH 6/8] fortran: use grep -F instead of fgrep Xi Ruoyao
@ 2022-06-24 7:09 ` Xi Ruoyao
2022-06-24 10:57 ` Arnaud Charlet
2022-06-24 7:10 ` [PATCH 8/8] contrib: " Xi Ruoyao
2022-06-24 7:24 ` [PATCH 0/8] Stop using obsoleted egrep/fgrep Rainer Orth
8 siblings, 1 reply; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:09 UTC (permalink / raw)
To: gcc-patches
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
gcc/testsuite/ChangeLog:
* ada/acats/run_all.sh: Use grep -E instead of egrep.
* go.test/go-test.exp: Likewise.
---
gcc/testsuite/ada/acats/run_all.sh | 2 +-
gcc/testsuite/go.test/go-test.exp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/ada/acats/run_all.sh b/gcc/testsuite/ada/acats/run_all.sh
index ac2a86bea6c..a48b492711b 100755
--- a/gcc/testsuite/ada/acats/run_all.sh
+++ b/gcc/testsuite/ada/acats/run_all.sh
@@ -367,7 +367,7 @@ for chapter in $chapters; do
target_run $dir/tests/$chapter/$i/$binmain > $dir/tests/$chapter/$i/${i}.log 2>&1
cd $dir/tests/$chapter/$i
cat ${i}.log >> $dir/acats.log
- egrep -e '(==== |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
+ grep -E -e '(==== |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
if [ $? -ne 0 ]; then
grep 'tasking not implemented' ${i}.log > /dev/null 2>&1
diff --git a/gcc/testsuite/go.test/go-test.exp b/gcc/testsuite/go.test/go-test.exp
index 11c178ad7ec..5699d3d248d 100644
--- a/gcc/testsuite/go.test/go-test.exp
+++ b/gcc/testsuite/go.test/go-test.exp
@@ -1207,7 +1207,7 @@ proc go-gc-tests { } {
|| $test_line == "// \$G \$D/empty.go && errchk \$G \$D/\$F.go" } {
# These tests import the same package under two different
# names, which gccgo does not support.
- } elseif { $test_line == "// \$G -S \$D/\$F.go | egrep initdone >/dev/null && echo BUG sinit || true" } {
+ } elseif { $test_line == "// \$G -S \$D/\$F.go | grep -E initdone >/dev/null && echo BUG sinit || true" } {
# This tests whether initializers are written out
# statically. gccgo does not provide a way to test that,
# as an initializer will be generated for any code which
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 7/8] testsuite: use grep -E instead of egrep
2022-06-24 7:09 ` [PATCH 7/8] testsuite: use grep -E instead of egrep Xi Ruoyao
@ 2022-06-24 10:57 ` Arnaud Charlet
0 siblings, 0 replies; 32+ messages in thread
From: Arnaud Charlet @ 2022-06-24 10:57 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: gcc-patches
> egrep has been deprecated in favor of grep -E for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of egrep is used.
> Stop using egrep so we won't see the warning.
Ada part is OK, thanks.
> gcc/testsuite/ChangeLog:
>
> * ada/acats/run_all.sh: Use grep -E instead of egrep.
> * go.test/go-test.exp: Likewise.
> ---
> gcc/testsuite/ada/acats/run_all.sh | 2 +-
> gcc/testsuite/go.test/go-test.exp | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/ada/acats/run_all.sh b/gcc/testsuite/ada/acats/run_all.sh
> index ac2a86bea6c..a48b492711b 100755
> --- a/gcc/testsuite/ada/acats/run_all.sh
> +++ b/gcc/testsuite/ada/acats/run_all.sh
> @@ -367,7 +367,7 @@ for chapter in $chapters; do
> target_run $dir/tests/$chapter/$i/$binmain > $dir/tests/$chapter/$i/${i}.log 2>&1
> cd $dir/tests/$chapter/$i
> cat ${i}.log >> $dir/acats.log
> - egrep -e '(==== |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
> + grep -E -e '(==== |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
> if [ $? -ne 0 ]; then
> grep 'tasking not implemented' ${i}.log > /dev/null 2>&1
>
> diff --git a/gcc/testsuite/go.test/go-test.exp b/gcc/testsuite/go.test/go-test.exp
> index 11c178ad7ec..5699d3d248d 100644
> --- a/gcc/testsuite/go.test/go-test.exp
> +++ b/gcc/testsuite/go.test/go-test.exp
> @@ -1207,7 +1207,7 @@ proc go-gc-tests { } {
> || $test_line == "// \$G \$D/empty.go && errchk \$G \$D/\$F.go" } {
> # These tests import the same package under two different
> # names, which gccgo does not support.
> - } elseif { $test_line == "// \$G -S \$D/\$F.go | egrep initdone >/dev/null && echo BUG sinit || true" } {
> + } elseif { $test_line == "// \$G -S \$D/\$F.go | grep -E initdone >/dev/null && echo BUG sinit || true" } {
> # This tests whether initializers are written out
> # statically. gccgo does not provide a way to test that,
> # as an initializer will be generated for any code which
> --
> 2.36.1
>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 8/8] contrib: use grep -E instead of egrep
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
` (6 preceding siblings ...)
2022-06-24 7:09 ` [PATCH 7/8] testsuite: use grep -E instead of egrep Xi Ruoyao
@ 2022-06-24 7:10 ` Xi Ruoyao
2022-06-24 7:24 ` [PATCH 0/8] Stop using obsoleted egrep/fgrep Rainer Orth
8 siblings, 0 replies; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:10 UTC (permalink / raw)
To: gcc-patches
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
contrib/ChangeLog:
* check_GNU_style.sh: Use grep -E instead of egrep.
* test_summary: Likewise.
* warn_summary: Likewise.
---
contrib/check_GNU_style.sh | 10 +++++-----
contrib/test_summary | 2 +-
contrib/warn_summary | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/check_GNU_style.sh b/contrib/check_GNU_style.sh
index fb7494661ee..535be65f063 100755
--- a/contrib/check_GNU_style.sh
+++ b/contrib/check_GNU_style.sh
@@ -113,7 +113,7 @@ g (){
local found=false
cat $inp \
- | egrep $color -- "$arg" \
+ | grep -E $color -- "$arg" \
> "$tmp" && found=true
if $found; then
@@ -130,8 +130,8 @@ ag (){
local found=false
cat $inp \
- | egrep $color -- "$arg1" \
- | egrep $color -- "$arg2" \
+ | grep -E $color -- "$arg1" \
+ | grep -E $color -- "$arg2" \
> "$tmp" && found=true
if $found; then
@@ -148,8 +148,8 @@ vg (){
local found=false
cat $inp \
- | egrep -v -- "$varg" \
- | egrep $color -- "$arg" \
+ | grep -E -v -- "$varg" \
+ | grep -E $color -- "$arg" \
> "$tmp" && found=true
if $found; then
diff --git a/contrib/test_summary b/contrib/test_summary
index 5760b053ec2..30494077aaa 100755
--- a/contrib/test_summary
+++ b/contrib/test_summary
@@ -77,7 +77,7 @@ for file in $files; do
{ $anychange ||
anychange=`diff $file.sent $file 2>/dev/null |
if test ! -f $file.sent ||
- egrep '^[<>] (XPASS|FAIL)' >/dev/null; then
+ grep -E '^[<>] (XPASS|FAIL)' >/dev/null; then
echo true
else
echo false
diff --git a/contrib/warn_summary b/contrib/warn_summary
index d4c8b6cdb19..eb88437e79d 100755
--- a/contrib/warn_summary
+++ b/contrib/warn_summary
@@ -57,7 +57,7 @@ subdirectoryFilter()
else
if test "$filter" = nosub ; then
# Omit all subdirectories.
- egrep -v '/gcc/(ch|cp|f|fortran|ada|intl|fixinc)/'
+ grep -E -v '/gcc/(ch|cp|f|fortran|ada|intl|fixinc)/'
else
# Pass through only subdir $filter.
grep "/gcc/$filter/"
--
2.36.1
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 6:57 [PATCH 0/8] Stop using obsoleted egrep/fgrep Xi Ruoyao
` (7 preceding siblings ...)
2022-06-24 7:10 ` [PATCH 8/8] contrib: " Xi Ruoyao
@ 2022-06-24 7:24 ` Rainer Orth
2022-06-24 7:27 ` Xi Ruoyao
8 siblings, 1 reply; 32+ messages in thread
From: Rainer Orth @ 2022-06-24 7:24 UTC (permalink / raw)
To: Xi Ruoyao via Gcc-patches
Hi Xi,
> egrep and fgrep have been deprecated for a long time, and the next grep
> release will emit a warning if egrep or fgrep is invoked:
>
> https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a951562
>
> To prevent us from a lot of these warnings in the future, we should stop
> using egrep and fgrep. These patches will remove most of the use of
> egrep or fgrep from GCC building system. The remaining:
please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several places is likely
to break at least the Solaris build.
Please see the autoconf manual for details. I suspect you'll have to
rework the patch set to use AC_PROG_EGREP and $EGREP instead.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 7:24 ` [PATCH 0/8] Stop using obsoleted egrep/fgrep Rainer Orth
@ 2022-06-24 7:27 ` Xi Ruoyao
2022-06-24 7:50 ` Rainer Orth
0 siblings, 1 reply; 32+ messages in thread
From: Xi Ruoyao @ 2022-06-24 7:27 UTC (permalink / raw)
To: Rainer Orth; +Cc: gcc-patches
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
> please remember that there's a world outside of GNU grep: e.g. Solaris
> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> unconditionally replacing egrep with grep -E in several places is
> likely
> to break at least the Solaris build.
>
> Please see the autoconf manual for details. I suspect you'll have to
> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
Thanks for the advice. I'll rework on it.
Is there some way to access a Solaris and do some test?
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 7:27 ` Xi Ruoyao
@ 2022-06-24 7:50 ` Rainer Orth
2022-06-24 8:26 ` Fangrui Song
0 siblings, 1 reply; 32+ messages in thread
From: Rainer Orth @ 2022-06-24 7:50 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: gcc-patches
Hi Xi,
> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
>
>> please remember that there's a world outside of GNU grep: e.g. Solaris
>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
>> unconditionally replacing egrep with grep -E in several places is
>> likely
>> to break at least the Solaris build.
>>
>> Please see the autoconf manual for details. I suspect you'll have to
>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
>
> Thanks for the advice. I'll rework on it.
>
> Is there some way to access a Solaris and do some test?
Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
farm (https://gcc.gnu.org/wiki/CompileFarm).
Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
moment, but those don't differ in this regard.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 7:50 ` Rainer Orth
@ 2022-06-24 8:26 ` Fangrui Song
2022-06-24 8:33 ` Andrew Pinski
2022-06-24 8:45 ` Rainer Orth
0 siblings, 2 replies; 32+ messages in thread
From: Fangrui Song @ 2022-06-24 8:26 UTC (permalink / raw)
To: Rainer Orth; +Cc: Xi Ruoyao, gcc-patches
On 2022-06-24, Rainer Orth wrote:
>Hi Xi,
>
>> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
>>
>>> please remember that there's a world outside of GNU grep: e.g. Solaris
>>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
>>> unconditionally replacing egrep with grep -E in several places is
>>> likely
>>> to break at least the Solaris build.
>>>
>>> Please see the autoconf manual for details. I suspect you'll have to
>>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
>>
>> Thanks for the advice. I'll rework on it.
>>
>> Is there some way to access a Solaris and do some test?
>
>Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
>farm (https://gcc.gnu.org/wiki/CompileFarm).
>
>Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
>moment, but those don't differ in this regard.
>
> Rainer
FWIW: glibc recently got the grep -E change and the solution is to use
plain grep -E, without $EGREP things.
Isn't setting PATH a good workaround if Solaris has the problem?
https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html
> Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only
> vendor-supported platform I know of where '/usr/bin/grep -E' does not
> work is Solaris 10 (end-of-life January 2024), and that's easily fixed
> by prepending /usr/xpg4/bin to PATH.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 8:26 ` Fangrui Song
@ 2022-06-24 8:33 ` Andrew Pinski
2022-06-24 16:09 ` Joseph Myers
2022-06-24 8:45 ` Rainer Orth
1 sibling, 1 reply; 32+ messages in thread
From: Andrew Pinski @ 2022-06-24 8:33 UTC (permalink / raw)
To: Fangrui Song; +Cc: Rainer Orth, GCC Patches
On Fri, Jun 24, 2022 at 1:27 AM Fangrui Song via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On 2022-06-24, Rainer Orth wrote:
> >Hi Xi,
> >
> >> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
> >>
> >>> please remember that there's a world outside of GNU grep: e.g. Solaris
> >>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> >>> unconditionally replacing egrep with grep -E in several places is
> >>> likely
> >>> to break at least the Solaris build.
> >>>
> >>> Please see the autoconf manual for details. I suspect you'll have to
> >>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
> >>
> >> Thanks for the advice. I'll rework on it.
> >>
> >> Is there some way to access a Solaris and do some test?
> >
> >Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
> >farm (https://gcc.gnu.org/wiki/CompileFarm).
> >
> >Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
> >moment, but those don't differ in this regard.
> >
> > Rainer
>
> FWIW: glibc recently got the grep -E change and the solution is to use
> plain grep -E, without $EGREP things.
> Isn't setting PATH a good workaround if Solaris has the problem?
glibc is a different story partly but I think GCC should go down the
EGREP route. glibc is not as friendly to non-GNU based systems
compared to GCC really.
Though I do find that -E/-F have been part of the POSIX standard since
at least 2004 which is interesting.
https://pubs.opengroup.org/onlinepubs/009696899/utilities/grep.html
Though GCC host/build targets can be older and some non-supported ones still.
Thanks,
Andrew Pinski
>
> https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html
>
> > Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only
> > vendor-supported platform I know of where '/usr/bin/grep -E' does not
> > work is Solaris 10 (end-of-life January 2024), and that's easily fixed
> > by prepending /usr/xpg4/bin to PATH.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 8:33 ` Andrew Pinski
@ 2022-06-24 16:09 ` Joseph Myers
2022-06-24 16:21 ` Iain Sandoe
0 siblings, 1 reply; 32+ messages in thread
From: Joseph Myers @ 2022-06-24 16:09 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Fangrui Song, GCC Patches
On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:
> Though I do find that -E/-F have been part of the POSIX standard since
> at least 2004 which is interesting.
grep -E and -F are already defined, and egrep and fgrep marked as
obsolescent, in the 1992/1993 edition of POSIX.2.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 16:09 ` Joseph Myers
@ 2022-06-24 16:21 ` Iain Sandoe
0 siblings, 0 replies; 32+ messages in thread
From: Iain Sandoe @ 2022-06-24 16:21 UTC (permalink / raw)
To: GCC Patches
> On 24 Jun 2022, at 17:09, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:
>
>> Though I do find that -E/-F have been part of the POSIX standard since
>> at least 2004 which is interesting.
>
> grep -E and -F are already defined, and egrep and fgrep marked as
> obsolescent, in the 1992/1993 edition of POSIX.2.
FWIW, grep -E/F is supported by the oldest Darwin versions I care about
so, I have no objections to these changes.
Iain
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 0/8] Stop using obsoleted egrep/fgrep
2022-06-24 8:26 ` Fangrui Song
2022-06-24 8:33 ` Andrew Pinski
@ 2022-06-24 8:45 ` Rainer Orth
1 sibling, 0 replies; 32+ messages in thread
From: Rainer Orth @ 2022-06-24 8:45 UTC (permalink / raw)
To: Fangrui Song; +Cc: Xi Ruoyao, gcc-patches
Hi Fangrui,
> FWIW: glibc recently got the grep -E change and the solution is to use
> plain grep -E, without $EGREP things.
> Isn't setting PATH a good workaround if Solaris has the problem?
>
> https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html
while it's possible, the $PATH solution is fragile and I fear the errors
that one gets all over the place when it's missed are highly unintuitive
and hard to diagnose.
>> Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only
>> vendor-supported platform I know of where '/usr/bin/grep -E' does not
>> work is Solaris 10 (end-of-life January 2024), and that's easily fixed by
>> prepending /usr/xpg4/bin to PATH.
I'm not concerned about Solaris 10 at all: it's no longer supported by
GCC and GDB and while binutils formally still does, there's not much
value in having current binutils with older gcc etc.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 32+ messages in thread