[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a couple of bugs
From: |
Benoit Sigoure |
Subject: |
Re: a couple of bugs |
Date: |
Mon, 17 Dec 2007 09:04:27 +0100 |
On Dec 17, 2007, at 12:27 AM, Benoit Sigoure wrote:
119: AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS FAILED
(torture.at:271)
I attached its testsuite.log (didn't have time to read it, I must
leave right now).
<testsuite.log>
./torture.at:241: ./config.status --file=-:input </dev/null >/dev/full
stderr:
/tmp/autoconf/tests/testsuite.dir/at-test-source: line 893: /dev/
full: Operation not supported
This looks like a tpyo but I checked in the source and it's not, why
not use something like /nonexistent/whatever? If someone runs the
testsuite with elevated privileged (even though that's not something
recommendable) the test will probably fail and create /dev/full :/
whereas with /nonexistent/whatever we are 100% sure it will not have
any unwanted side effect.
./torture.at:271: ./config.status "--file=$file:$file.in"
--- /dev/null Mon Dec 17 00:13:46 2007
+++ /tmp/autoconf/tests/testsuite.dir/at-stderr Mon Dec 17 00:13:46 2007
@@ -0,0 +1,2 @@
+sed: 12: "/^[ ]*VPATH[ ]*=/{
+s/ ...": bad flag in substitute command: '#'
Blah, it's the failure that Eric reported on OpenBSD, it looks like
it's not OpenBSD specific but rather BSD-sed specific. The problem
lies in the fact that BSD-sed has troubles parsing comments:
$ echo a | /usr/bin/sed 's/a/b/ # comment'
sed: 1: "s/a/b/ # comment": bad flag in substitute command: '#'
$ echo a | /opt/local/bin/gnused 's/a/b/ # comment'
b
(on MacOSX where /usr/bin/sed is BSD-sed)
And what happens in our case is that we're trying to test whether
config.status plays nicely with funny file names:
file='file with funny \ '\'' \'\'' $ & #!*? name'
(notice the `&' in the file name)
config.status does this:
s&@configure_input@&$configure_input&;t t
which basically expands to:
s&@configure_input@&file with funny \ ' \' $ & #!*? name.
Generated from file with funny \ ' \' $ & #!*? name.in by
configure.&;t t
and the `&' expanded from $configure_input terminates the replacement
string. GNU sed fails to fail (:D) here because it skips the
remaining stuff on the line (because of the #). BSD-sed fails to
recognize the comment, hence the error message.
This raises the question, why are the `&' not escaped in
$configure_input in the first place?
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
- a couple of bugs, Ralf Wildenhues, 2007/12/16
- Re: a couple of bugs, Benoit Sigoure, 2007/12/16
- Re: a couple of bugs, Eric Blake, 2007/12/17
- Re: a couple of bugs, Benoit Sigoure, 2007/12/17
- Re: a couple of bugs, Eric Blake, 2007/12/17
- Re: a couple of bugs, Thomas Schwinge, 2007/12/20