bug#17478: "No such file or directoryn" due to incorrect escaping

[Egmont Koblinger]

Sorry, I was stupid attaching config.guess :)

Its output is x86_64-unknown-linux-gnu.

On Tue, May 13, 2014 at 10:49 AM, Egmont Koblinger <address@hidden> wrote:
> Hi,
>
>> I am not seeing this on any of my systems here.
>>
>> What version of libtool is being used (output of './libtool --version' in
>> build tree).
>
> There's no ./libtool in the git source, the system version is copied
> there upon running ./autogen.sh. (I'm not familiar with libtool at
> all, can't tell if this is correct.)  It says version 2.4.2.
>
>> What operating system is being used (output of 'uname -a')?
>
> This is an Ubuntu Trusty:
> Linux foo 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
>
>> What is the output from 'config.guess' in the source tree?
>
> Attached.
>
> I also attach the generated vte-2.91 shell script where line 204 is
> clearly buggy:
>         printf %s\n "$relink_command_output" >&2
> I think it's obvious that it prints a literal 'n' instead of a
> newline. Adding one more backslash here solves the problem.
>
> I believe this line is generated from these lines of libtool.m4 and
> ltmain.sh (attaching these too):
> libtool.m4:1183:   ECHO='printf %s\n'
> ltmain.sh:4069:      $ECHO \"\$relink_command_output\" >&2
>
>> What is the value of $SHELL?
>
> It's /bin/bash, this is the shell I'm running.
>
> Note: on Ubuntu, /bin/sh is a symlink to dash. But I've changed it to
> point to bash and the same problem persists.
>
>> What is the origin of the printf used?
>
> I'm not sure I understand this question, could you please clarify?
> printf is a builtin for both dash and bash. I believe the origin of
> this faulty printf command is the lines in libtool.m4 and ltmain.sh
> that I quoted above.
>
>
> thanks,
> egmont