Re: fix for fugly autoconf 2.62 bug

[Ralf Wildenhues]

Hello world,

thanks for the bug report, Per.

* Eric Blake wrote on Mon, Apr 21, 2008 at 02:25:24PM CEST:
> According to Per Øyvind Karlsen on 4/20/2008 6:01 AM:
> |>> Oh, I'm mixing up bugzilla entries, I actually meant
> |>> http://bugs.gentoo.org/show_bug.cgi?id=217976.
> |> thanks, the patch you posted does fix this.  i wonder why it doesnt fail
> |> with 2.61 though since the code in question is the same ...
> | The change resulting in this is the following:

> (http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=ce429ecdc03698025176d3003e113e6e003b429f)
>
> Thanks for the details.  This commit was made by Ralf, not me, so it gives
> further argument to the rule of reporting to the bug list rather than a
> private developer (particularly since I didn't have access to my email
> over the weekend, leading to this lag in reading your complete thread).

Can we see the complete thread somewhere?

This bug does not happen with

AC_CONFIG_FILES([foo
                 bar])

It can happen with

f='foo
bar'
AC_CONFIG_FILES([$f])

or with obsolete:

CONFIG_FILES="foo
bar" ./config.status

which is not fixed by your patch.  So I'd like to see more information
on how you triggered this issue, maybe I overlooked something, before
venturing into a fix.

> | eval will threat the $CONFIG_FILES variable and friends as multiple lines if
> | the variables contains newlines. Example:
> | CONFIG_FILES="foo
> | bar"
> | eval set X ":F $CONFIG_FILES"
> |
> | This will be processed as:
> | set X :F foo
> | bar
> | Where 'set X :F foo' will be one command on the first line and 'bar' a new
> | command on second line.
>
> Ah.  So the old behavior allowed arbitrary whitespace, but the new
> behavior drops support for newlines.  I think a nicer patch would use a
> shell case statement to only do the extra fork to convert newlines into
> spaces only when newlines are present.  But I'll let Ralf have first crack
> at this problem.

Well, the echo may also kill backslashes; not that it's likely to matter
here, though.  A bigger issue is how to also fix the obsolete usage case
without killing support for --file=... with interesting names.

> |>>> dont autoconf bug reports normally go to the autoconf mailing list
> |>>> rather than specific people ?
> |>> Sure, but I don't maintain autoconf on a regular basis and don't want to
> |>> sign up on yet another mailing list, therefore I'm sending it to upstream
> |>> maintainer and you. :)
> |> i think the autoconf patches list is open ... or at least, you'll get
> |> moderated through

Yes, you will.

Cheers,
Ralf