[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge

From: Jim Meyering
Subject: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug
Date: Mon, 12 May 2014 10:56:56 -0700

On Sun, May 11, 2014 at 1:48 PM, Paul Eggert <address@hidden> wrote:
> Following up to the grep snapshot announcement in:
> http://lists.gnu.org/archive/html/platform-testers/2014-05/msg00000.html
> That snapshot failed to build the shell scripts egrep and fgrep properly on
> Solaris 10, because it set "SHELL = /bin/sh" in src/Makefile, which caused
> the makefile to put "#!/bin/sh" at the top of the shell scripts, which
> breaks because the shell scripts use a construct '${0%/*}' that Solaris 10
> /bin/sh doesn't grok.  The build should have used SHELL = /bin/bash, which
> is what grep does with my test builds.
> We could work around the problem by avoiding that shell construct, but I'd
> rather fix the build machinery because this bug could affect any package
> that uses POSIX shell scripts.  The snapshot was built with an experimental
> version of Autoconf (2.69.117-1717), whereas I had tested with the latest
> stable version (2.69 as shipped with Fedora 20).  The two versions differ in
> how they compute the name of a working shell, so it appears that there's a
> bug in the experimental version of Autoconf.
> A quick workaround for grep is to build the next snapshot with Autoconf
> 2.69.  In the long run, though, we should fix the Autoconf bug.  I'll CC:
> this to bug-autoconf to give them a heads-up.

Hi Paul,
Thanks for reporting that.
I would like our egrep and fgrep scripts to work even on systems with
an old shell and no "bash" to fall back on. Our tests/init.sh code
tries hard to find a sufficiently functional shell (including a test
for the ${VAR%GLOB} construct), and making it work in spite of
Solaris's /bin/sh was tricky... plus, we had to be willing to give up
and skip tests altogether, in the event that no sufficiently
functional shell is found.  Here, we don't have that luxury.

Ideally, these wrapper shell scripts would not have to fork an extra
process to perform this trivial string manipulation, but I can live
with the extra overhead, especially for scripts like these that merely
provide support for obsolescent programs.

I think the attached patch is sufficiently portable to work everywhere.
Does anyone see a (simple+clean) way to make it more efficient for the
common case in which @SHELL@ is a more functional shell?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]