GNU bug report logs -
#14196
Problem with invoking "missing" in directory with "(" in name (Automake 1.11.6, Autoconf 2.68)
Previous Next
Reported by: Jeff Johnston <jjohnstn <at> redhat.com>
Date: Fri, 12 Apr 2013 21:57:01 UTC
Severity: normal
Tags: patch
Done: Karl Berry <karl <at> freefriends.org>
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 14196 in the body.
You can then email your comments to 14196 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#14196
; Package
automake
.
(Fri, 12 Apr 2013 21:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jeff Johnston <jjohnstn <at> redhat.com>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Fri, 12 Apr 2013 21:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I am using automake 1.11.6 and autoconf 2.68 on Fedora 17 and cannot
configure a simple hello world program if it is placed into a directory
with "(" and ")".
To reproduce:
1. Create a directory: mkdir test\(1\)
2. Take the attached tar file and untar it:
cd test\(1\)
tar -xzvf helloworld.tar.gz
3. autoreconf -i
4. now try and configure the project using ./configure or absolutely
using sh -c '~/test\(1\)/configure'
In either case, you will get a failure trying to invoke "missing" due to
the unexpected '(' token in the directory name.
bash $ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
./configure: eval: line 2084: syntax error near unexpected token `('
./configure: eval: line 2084: `${SHELL}
/home/cygnus/jjohnstn/test(1)/missing --run true'
-- Jeff J.
[helloworld.tar.gz (application/x-tar, attachment)]
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14196
; Package
automake
.
(Wed, 02 Sep 2020 01:08:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 14196 <at> debbugs.gnu.org (full text, mbox):
Hi - thanks for this bug report (from seven years ago, sorry).
4. now try and configure the project using ./configure or absolutely
using sh -c '~/test\(1\)/configure'
...
./configure: eval: line 2084: syntax error near unexpected token `('
./configure: eval: line 2084: `${SHELL}
It still happens with your supplied tarball (thanks much for that). As
far as I know this is a bug in autoconf, not automake. I have attempted
to reassign the bug. Zack, can you check please?
In the meantime, the failing line number has changed to 2126.
The relevant bit in the generated configure script is
2117 if test x"${MISSING+set}" != xset; then
2118 case $am_aux_dir in
2119 *\ * | *\ *)
2120 MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
2121 *)
2122 MISSING="\${SHELL} $am_aux_dir/missing" ;;
2123 esac
2124 fi
2125 # Use eval to expand $SHELL
2126 if eval "$MISSING --is-lightweight"; then
2127 am_missing_run="$MISSING "
2128 else
I tried manually changing the condition on line 2119 to check for lparen:
2119 *\ * | *\ * | *\(* )
and it went through ok. I suppose all shell metacharacters should be
checked for. Maybe always use the quoted version?
Thanks again for the report. --karl
bug reassigned from package 'automake' to 'autoconf'.
Request was from
Karl Berry <karl <at> freefriends.org>
to
control <at> debbugs.gnu.org
.
(Wed, 02 Sep 2020 01:08:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#14196
; Package
autoconf
.
(Fri, 04 Sep 2020 13:45:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 14196 <at> debbugs.gnu.org (full text, mbox):
reassign -1 automake
tags -1 + patch
quit
OK, after a quick investigation, the failure happens at configure time
but the problem code belongs to automake. Specifically,
AM_MISSING_HAS_RUN. I think the tidiest fix is to quote the value of
$am_aux_dir/missing unconditionally:
diff --git a/m4/missing.m4 b/m4/missing.m4
index 6f742fb20..56c84fbf5 100644
--- a/m4/missing.m4
+++ b/m4/missing.m4
@@ -21,12 +21,7 @@ AC_DEFUN([AM_MISSING_HAS_RUN],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
AC_REQUIRE_AUX_FILE([missing])dnl
if test x"${MISSING+set}" != xset; then
- case $am_aux_dir in
- *\ * | *\ *)
- MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
- *)
- MISSING="\${SHELL} $am_aux_dir/missing" ;;
- esac
+ MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
fi
# Use eval to expand $SHELL
if eval "$MISSING --is-lightweight"; then
This doesn't handle the possibility of $am_aux_dir containing
backslash or double quote characters, but that's ok because
AM_SANITY_CHECK will already have refused to run configure with either
the current working directory or the source directory named like that.
(An alternative patch would be to add ( ) to the set of characters
rejected by AM_SANITY_CHECK.)
If m4sugar included a version of AS_ESCAPE that worked at configure
time, instead of m4 expansion time, I'd suggest using that, but it
doesn't.
zw
bug reassigned from package 'autoconf' to 'automake'.
Request was from
Zack Weinberg <zackw <at> panix.com>
to
control <at> debbugs.gnu.org
.
(Fri, 04 Sep 2020 14:04:02 GMT)
Full text and
rfc822 format available.
Added tag(s) patch.
Request was from
Zack Weinberg <zackw <at> panix.com>
to
control <at> debbugs.gnu.org
.
(Fri, 04 Sep 2020 14:04:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14196
; Package
automake
.
(Fri, 04 Sep 2020 14:08:01 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
It looks like this didn't go through to bug-automake because the bug
was still considered to be assigned to autoconf at the time.
---------- Forwarded message ---------
From: Zack Weinberg <zackw <at> panix.com>
Date: Fri, Sep 4, 2020 at 9:44 AM
Subject: Re: bug#14196: Problem with invoking "missing" in directory
with "(" in name (Automake 1.11.6, Autoconf 2.68
To: <14196 <at> debbugs.gnu.org>, <control <at> debbugs.gnu.org>
reassign -1 automake
tags -1 + patch
quit
OK, after a quick investigation, the failure happens at configure time
but the problem code belongs to automake. Specifically,
AM_MISSING_HAS_RUN. I think the tidiest fix is to quote the value of
$am_aux_dir/missing unconditionally:
diff --git a/m4/missing.m4 b/m4/missing.m4
index 6f742fb20..56c84fbf5 100644
--- a/m4/missing.m4
+++ b/m4/missing.m4
@@ -21,12 +21,7 @@ AC_DEFUN([AM_MISSING_HAS_RUN],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
AC_REQUIRE_AUX_FILE([missing])dnl
if test x"${MISSING+set}" != xset; then
- case $am_aux_dir in
- *\ * | *\ *)
- MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
- *)
- MISSING="\${SHELL} $am_aux_dir/missing" ;;
- esac
+ MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
fi
# Use eval to expand $SHELL
if eval "$MISSING --is-lightweight"; then
This doesn't handle the possibility of $am_aux_dir containing
backslash or double quote characters, but that's ok because
AM_SANITY_CHECK will already have refused to run configure with either
the current working directory or the source directory named like that.
(An alternative patch would be to add ( ) to the set of characters
rejected by AM_SANITY_CHECK.)
If m4sugar included a version of AS_ESCAPE that worked at configure
time, instead of m4 expansion time, I'd suggest using that, but it
doesn't.
zw
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14196
; Package
automake
.
(Fri, 04 Sep 2020 22:16:01 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
AM_MISSING_HAS_RUN
Whoops, sorry for not realizing that. Thanks for fixing my/our bug :).
- case $am_aux_dir in
- *\ * | *\ *)
- MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
- *)
- MISSING="\${SHELL} $am_aux_dir/missing" ;;
- esac
+ MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
I wondered about that too. But then why did the nonquoted case ever exist?
Just oversight when originally written and then patched to support
spaces? Seems weird. Can't find anything in ChangeLog about it.
Jim/Paul/anyone? Else I'll go ahead and apply. --thanks, karl.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14196
; Package
automake
.
(Sat, 05 Sep 2020 10:12:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 14196 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 4, 2020 at 4:38 PM Zack Weinberg <zackw <at> panix.com> wrote:
> OK, after a quick investigation, the failure happens at configure time
> but the problem code belongs to automake. Specifically,
> AM_MISSING_HAS_RUN. I think the tidiest fix is to quote the value of
> $am_aux_dir/missing unconditionally:
>
> diff --git a/m4/missing.m4 b/m4/missing.m4
> index 6f742fb20..56c84fbf5 100644
> --- a/m4/missing.m4
> +++ b/m4/missing.m4
> @@ -21,12 +21,7 @@ AC_DEFUN([AM_MISSING_HAS_RUN],
> [AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
> AC_REQUIRE_AUX_FILE([missing])dnl
> if test x"${MISSING+set}" != xset; then
> - case $am_aux_dir in
> - *\ * | *\ *)
> - MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
> - *)
> - MISSING="\${SHELL} $am_aux_dir/missing" ;;
> - esac
> + MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
> fi
> # Use eval to expand $SHELL
> if eval "$MISSING --is-lightweight"; then
>
> This doesn't handle the possibility of $am_aux_dir containing
> backslash or double quote characters, but that's ok because
> AM_SANITY_CHECK will already have refused to run configure with either
> the current working directory or the source directory named like that.
> (An alternative patch would be to add ( ) to the set of characters
> rejected by AM_SANITY_CHECK.)
Thanks for investigating and patching.
I think this patch is the right way to go.
Otherwise, I suspect we'd have to make AM_SANITY_CHECK disallow not
only parentheses, but also at least these !?*[]
While looking at this, I wondered... why are the inner quotes double quotes?
I.e., we might as well use single quotes. Slightly cleaner, too, since
no backslash is required for them:
+ MISSING="\${SHELL} '$am_aux_dir/missing'" ;;
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14196
; Package
automake
.
(Sun, 06 Sep 2020 01:15:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 14196 <at> debbugs.gnu.org (full text, mbox):
+ MISSING="\${SHELL} '$am_aux_dir/missing'" ;;
I made this change. Two tests (man6 and am-missing-prog) that were
grepping for the path to missing needed adjusting for the quotes being
present now.
Closing this one. Thanks all. -k
Reply sent
to
Karl Berry <karl <at> freefriends.org>
:
You have taken responsibility.
(Sun, 06 Sep 2020 01:15:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jeff Johnston <jjohnstn <at> redhat.com>
:
bug acknowledged by developer.
(Sun, 06 Sep 2020 01:15:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 04 Oct 2020 11:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 198 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.