[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Update of sr #110657 (project autoconf):

  Status: Wont Do => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #12:

[comment #11 comment #11:]

> As attached, it works.

OK, I installed a patch along those lines into savannah master. Closing the
bug report.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Alain Knaff]

Follow-up Comment #11, sr #110657 (project autoconf):


[comment #10 comment #10:]
> This patch works great, thanks :-)
> 

Sorry, I misspoke. The patch actually fails to set the variable
EGREP_TRADITIONAL (it only sets ac_cv_path_EGREP_TRADITIONAL), so all egrep
checks later fail, just as if the search expression was not found.

As attached, it works.

(file #53286)

___

Additional Item Attachment:

File name: autoconf-egrep-traditional.diff Size:2 KB
   




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Alain Knaff]

Follow-up Comment #10, sr #110657 (project autoconf):

[comment #9 comment #9:]
> [comment #8 comment #8:]
[...]
> > egrep '(-z)'  
> That won't work if the pattern contains back-references, since it'll mess up
the numbering.

Indeed, forgot about that.

> However, we can prepend '.?' to the pattern; this should work. How about the
attached patch instead?
> 
> (file #53284)

This patch works great, thanks :-)



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Follow-up Comment #9, sr #110657 (project autoconf):

[comment #8 comment #8:]
> there is another way than -e to escape that dash: simply put a pair of
parenthesis around the search string:
> 
> egrep '(-z)' https://file.savannah.gnu.org/file/0001-Fix-bug-AC_EGREP_CPP-with-leading-in-pattern.patch?file_id=53284>



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Alain Knaff]

Follow-up Comment #8, sr #110657 (project autoconf):

[comment #6 comment #6:]
> How about the attached patch instead?

Unfortunately, this patch doesn't work ... due to another peculiarity of
UnixPC's egrep which had escaped earlier: for some weird reason, if -e is
used, egrep doesn't support grepping in stdin, but only in files given on
command line.

i.e. egrep -e root https://savannah.gnu.org/support/?110657>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Follow-up Comment #7, sr #110657 (project autoconf):

[comment #6 comment #6:]
> How about the attached patch instead?
Oops, that patch had a stray -E so I removed it. Revised patch attached.

(file #53277)

___

Additional Item Attachment:

File name: 0001-Fix-bug-AC_EGREP_CPP-with-leading-in-pattern.patch Size:3 KB
   




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Follow-up Comment #6, sr #110657 (project autoconf):

[comment #5 comment #5:]
> the only reason why AC_PROG_EGREP is brought in (in my case) is due to the
macro AC_EGREP_CPP, which does not ever use the -e option
AC_EGREP_CPP should use -e though, since it should work even if the pattern
begins with '-'.

How about the attached patch instead? It fixes that bug with '-', it defines a
new macro _AC_PROG_EGREP_TRADITIONAL which I hopes works as well on the AT
UnixPC as it does on today's platforms, and it avoids messing with
AC_PROG_EGREP due to the usual worries about breaking old stuff. This macro
name begins with underscore so it's private (I don't want users relying on
it).

> So this should also work on platforms were egrep doesn't support -e either.
We don't know of any such platforms so it should be OK to not worry about
that.


(file #53276)

___

Additional Item Attachment:

File name: 0001-Fix-bug-AC_EGREP_CPP-with-leading-in-pattern.patch Size:3 KB
   




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Alain Knaff]

Follow-up Comment #5, sr #110657 (project autoconf):


[comment #4 comment #4:]
> For the record, despite this having been marked "won't do", I _would_
consider and review a patch (against current development trunk) that would
make configure scripgs set $EGREP and $GREP to `egrep` on systems where `egrep
-e` works but `grep -E -e` doesn't work.  It's just that neither Paul nor I
have the time, nor the necessary test environment, to develop such a patch.

Hi,

Thanks for "opening the way" for a patch :-)

Attached is a patch which addresses the issue (the patch is against 2.71, as
available in Debian testing).

It removes the dependency of AC_PROG_EGREP on AC_PROG_GREP , and does the
"acceptable" check itself instead. If no acceptable grep is found (for use
with -E), it falls back on searching for an acceptable egrep.

Moreover, I noticed that the only reason why AC_PROG_EGREP is brought in (in
my case) is due to the macro AC_EGREP_CPP, which does not ever use the -e
option (to supply multiple pattern, or pattern that start with a dash).

So the patch has an additional fix, by defining an AC_PROG_EGREP_SIMPLE which
relaxes the requirements. It now only needs to conform to extended regexp
syntax, and work with long lines, but doesn't need to support -e.

So this should also work on platforms were egrep doesn't support -e either.

Then, in my example, AC_EGREP_CPP is only needed by AC_EGREP_HEADER, itself
only needed by AC_TYPE_UID_T.
And AC_TYPE_UID_T has a FIXME comment at the top saying "Rewrite using
AC_CHECK_TYPE" :-)

(file #53274)

___

Additional Item Attachment:

File name: autoconf-grep.diff Size:2 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[pluto--- via Bug reports for autoconf]

A related data point:  the grep and egrep supplied with SunOS 4.1.1_U1
(which IIRC is somewhere between 4.2 and 4.3 BSD) both accept -e.
However, if -e is specified more than once, they appear to use only
the last occurrence.  (I had expected that egrep, at least, would
report all input lines that match any of multiple -e specifications.)

BTW they are separate executables, neither of which accepts -E.

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Update of sr #110657 (project autoconf):

Priority: 3 - Low => 1 - Later  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Zack Weinberg]

Follow-up Comment #4, sr #110657 (project autoconf):

For the record, despite this having been marked "won't do", I _would_ consider
and review a patch (against current development trunk) that would make
configure scripgs set $EGREP and $GREP to `egrep` on systems where `egrep -e`
works but `grep -E -e` doesn't work.  It's just that neither Paul nor I have
the time, nor the necessary test environment, to develop such a patch.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Update of sr #110657 (project autoconf):

  Status:   Need Info => Wont Do

___

Follow-up Comment #3:

OK, I think I see what's happening now; you have an egrep that's good enough,
but you also want to test for header files and Autoconf's header-file tests
insist on robust 'grep' because they prefer to use 'grep -E', as egrep was
removed from POSIX a long time ago.

For this sort of thing, I suggest either (a) installing and using a better
'grep' like GNU grep, or (b) running something like './configure
ac_cv_path_GREP=/usr/bin/grep ac_cv_path_egrep=/usr/bin/egrep' in the hopes
that your system grep and egrep are good enough for 'configure'. (a) should be
much better in the long run.

I doubt whether we should modify Autoconf to work around this problem, as it
should occur only on nonstandard platforms that are no longer supported even
by their own suppliers.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Alain Knaff]

Follow-up Comment #2, sr #110657 (project autoconf):

>> For example, grep does not support -e , but egrep does.
> AC_PROG_GREP looks for a grep that does support -e, so a configure script
that uses that should have a $GREP that works, assuming you have one somewhere
in your $PATH. (If not, you'll need to get one.)

Unfortunately, my configure script does not use AC_PROG_GREP directly.

Instead, this is brought in via AC_REQUIRE by AC_PROG_EGREP, which itself is
required by AC_EGREP_CPP which is required by lots of tests for header files
etc.

However, as said in my initial report, grep is actually not used further down
in the script (AC_PROG_CPP only needs egrep, not grep). And strangely enough,
egrep *does* support the -e flag on UnixPC.

>> This lack of support of -e makes the configure script fail, although there
is a usable egrep.
> Autoconf's 'configure' script doesn't use 'grep -e' anywhere that I can
see.

And that is exactly my point. Absence of a feature which is not being used
anywhere shouldn't be a fatal error.

> Are you debugging some other 'configure' script that uses 'grep -e'?

No, I've only been debugging the mtools configure script (generated by
autoconf) as well as another configure script generated by autoconf from a
mostly empty configure.in

> If so,it should use AC_PROG_GREP

I'm not really sure how adding an explicit AC_PROG_GREP would solve the
problem brough by the implicit usage (due to AC_REQUIRE, see above)

> and "$GREP -e" and you should have a grep in your $PATH that works.

Unfortunately, this museum piece :-) doesn't have a grep where -e works, but
it *does* haven an egrep that supports -e. The issue I have is that the
configure script *doesn't* actually *need* a grep that supports -e (apart from
this test itself), and only needs egrep with -e. Neither does my own
compilation need grep -e.

(I just hope you didn't get confused by the existence of an -E (capital E)
option that makes grep behave like egrep (i.e. uses extended regexp syntax).
The -e that I am talking about here is lower case -e that makes allows to use
regular expressions that start with a dash (-), or to use multiple regular
expressions)



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Update of sr #110657 (project autoconf):

Priority:  5 - Normal => 3 - Low
  Status:None => Need Info  

___

Follow-up Comment #1:

> For example, grep does not support -e , but egrep does.
AC_PROG_GREP looks for a grep that does support -e, so a configure script that
uses that should have a $GREP that works, assuming you have one somewhere in
your $PATH. (If not, you'll need to get one.)

> This lack of support of -e makes the configure script fail, although there
is a usable egrep.
Autoconf's 'configure' script doesn't use 'grep -e' anywhere that I can see.
Are you debugging some other 'configure' script that uses 'grep -e'? If so,it
should use AC_PROG_GREP and "$GREP -e" and you should have a grep in your
$PATH that works.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Alain Knaff]

URL:
  

 Summary: Autoconf configure script considers absence of
usable grep a fatal error, although it only uses egrep thereafter
 Project: Autoconf
Submitted by: alainknaff
Submitted on: Sun 15 May 2022 08:11:13 PM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Configure scripts generated by autoconf first test for a "usable" grep (i.e.
one which understands the -e option, and supports multiple -e options), and
then after that looks for an egrep candidate.

By default it tries to use grep -E for egrep, or if that doesn't work, it
tries actual egrep.

During the rest of the script (most scripts in any case, not sure about some
exotic tests), $EGREP is only ever used, not $GREP.

This works fine on most platforms, where grep an egrep are the same binary
anyways, and change regular expression syntax depending on how they are
called.

Not so on AT UnixPC, where they are largely independent of each other. Grep
seems to be generally the older binary, and generally supports less command
line options than egrep.
For example, grep does not support -e , but egrep does.

This lack of support of -e makes the configure script fail, although there is
a usable egrep.

Fix: make lack of "usable" grep on non-fatal error (and only try to use egrep
directly in that case, rather than grep -E)






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/