autoconf-patches
[Top][All Lists]
Advanced

[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






reply via email to

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