GNU bug report logs -
#17471
On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Sun, 11 May 2014 20:50:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17471 in the body.
You can then email your comments to 17471 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-grep <at> gnu.org:
bug#17471; Package
grep.
(Sun, 11 May 2014 20:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
New bug report received and forwarded. Copy sent to
bug-grep <at> gnu.org.
(Sun, 11 May 2014 20:50:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-grep <at> gnu.org:
bug#17471; Package
grep.
(Mon, 12 May 2014 12:16:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/11/2014 02:48 PM, Paul Eggert 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.
In autoconf.git, there are zero hits for:
git grep -F '0%/*'
However, in grep.git, there is:
src/egrep.sh: if test -x "${0%/*}/@grep@"; then
src/egrep.sh: PATH=${0%/*}:$PATH
The culprit is grep itself, not autoconf.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#17471; Package
grep.
(Mon, 12 May 2014 17:35:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 17471 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, May 11, 2014 at 1:48 PM, Paul Eggert <eggert <at> cs.ucla.edu> 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
a non-POSIX 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, and we had to be willing to give up and
skip tests altogether, in the event that no sufficiently featureful
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, expecially for scripts like these that merely
provide support for obsolescent-named programs.
I think the attach patch is sufficiently portable to do what I want.
Does anyone see a way to make it more efficient with a POSIX shell?
[0001-egrep-fgrep-make-wrappers-portable-to-non-POSIX-shel.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#17471; Package
grep.
(Mon, 12 May 2014 17:58:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 17471 <at> debbugs.gnu.org (full text, mbox):
On Sun, May 11, 2014 at 1:48 PM, Paul Eggert <eggert <at> cs.ucla.edu> 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?
Information forwarded
to
bug-grep <at> gnu.org:
bug#17471; Package
grep.
(Mon, 12 May 2014 18:04:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 17471 <at> debbugs.gnu.org (full text, mbox):
On 2014-05-12 10:33 -0700, Jim Meyering wrote:
[...]
> I think the attach patch is sufficiently portable to do what I want.
> Does anyone see a way to make it more efficient with a POSIX shell?
>
> From e2a305bff2be376f6dd29e52a1d32636e0c22706 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyering <at> fb.com>
> Date: Mon, 12 May 2014 10:33:09 -0700
> Subject: [PATCH] egrep, fgrep: make wrappers portable to non-POSIX shells
>
> * src/egrep.sh (grep): Use sed in a subshell in place of the
> POSIX sh construct, ${0%/*}. The latter is not portable to
> Solaris 10. Reported by Paul Eggert in http://debbugs.gnu.org/17471
> ---
> src/egrep.sh | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/egrep.sh b/src/egrep.sh
> index f1b4146..0a374aa 100644
> --- a/src/egrep.sh
> +++ b/src/egrep.sh
> @@ -2,9 +2,10 @@
> grep=grep
> case $0 in
> */*)
> - if test -x "${0%/*}/@grep@"; then
> - PATH=${0%/*}:$PATH
> - grep=@grep@
> + dirname=`echo "$0"|sed 's,//*[^/]*$,,'`
I'd write
dirname=`expr x"$0" : x'\(.*\)/'`
but mainly for style reasons...
> + if test -x "$dirname"/'@grep@'; then
> + PATH="$dirname:$PATH"
> + grep='@grep@'
> fi;;
> esac
> exec $grep @option@ "$@"
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Mon, 12 May 2014 18:46:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
bug acknowledged by developer.
(Mon, 12 May 2014 18:46:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 17471-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/12/2014 10:33 AM, Jim Meyering wrote:
> Does anyone see a way to make it more efficient with a POSIX shell?
Yes. Eric's earlier message convinced me that grep shouldn't rely on
Autoconf guaranteeing a shell that supports substrings in parameter
expansion, so I came up with the attached patch (which keeps the shell
efficient with a POSIX shell) and pushed it before I got around to
reading your message. I tested on Solaris 10 with the shell
artificially set to /bin/sh, so I'm marking this as done.
From an Autoconf point of view it might be nice to have a good way to
say "I need a POSIX shell" or at least "I need a shell that does
substrings", but that's merely a wishlist item.
[0001-egrep-fgrep-port-to-Solaris-10-bin-sh.patch (text/x-patch, attachment)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#17471; Package
grep.
(Tue, 13 May 2014 01:35:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 17471-done <at> debbugs.gnu.org (full text, mbox):
Thanks for dealing with that.
The only potential problem I see with your patch would be when
one runs configure with a perverse program name transformation,
e.g., --program-transform-name='s/^/$/', introducing a shell
metacharacter (or leading/trailing white space!) in the resulting
name. In that case, the lack of single quotes around @grep@
would be fatal.
Fixing that is not high priority. Anyone who does that to
grep deserves the result :-)
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 10 Jun 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 323 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.