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