GNU bug report logs - #17478
"No such file or directoryn" due to incorrect escaping

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17478 in the body.
You can then email your comments to 17478 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Egmont Koblinger <egmont <at> gmail.com>
To: bug-libtool <at> gnu.org
Subject: "No such file or directoryn" due to incorrect escaping
Date: Mon, 12 May 2014 19:35:24 +0200

Hi,

The following sequence of commands (with basic Gtk+ development
libraries installed):

git clone git://git.gnome.org/vte
cd vte
./autogen.sh
make
git checkout vte-0-36
./autogen.sh
make clean
./src/vte-2.91

gives the following error (it's not the error itself but the formatting):

PROMPT$ ./src/vte-2.91
gcc: error: vte_2_91-app.o: No such file or directory
gcc: error: vte_2_91-appresources.o: No such file or directory
gcc: error: ./.libs/libvte-2.91.so: No such file or directorynPROMPT$

Notice that a literal "n" is printed after the 3rd error message,
rather than a newline.

The libtool-generated src/vte-2.91 script contains:
printf %s\n "$relink_command_output" >&2

where the backslash is swallowed by the shell and it becomes a literal
"n".  It should be either double-backslashed, or enclosed between
quotes.

If you google "No such file or directoryn" with that extra "n" at the
end, you'll see plenty of matches, so probably this is a common
problem.

I think any occurrence of the literal »printf %s\n« is necessarily
buggy, since the space suggests that it has to be processed by the
shell, which will just ignore that backslash.


thx,
egmont

Message #8 received at 17478 <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Egmont Koblinger <egmont <at> gmail.com>
Cc: 17478 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#17478: "No such file or directoryn" due to incorrect escaping
Date: Mon, 12 May 2014 20:49:21 -0500 (CDT)

On Mon, 12 May 2014, Egmont Koblinger wrote:
>
> PROMPT$ ./src/vte-2.91
> gcc: error: vte_2_91-app.o: No such file or directory
> gcc: error: vte_2_91-appresources.o: No such file or directory
> gcc: error: ./.libs/libvte-2.91.so: No such file or directorynPROMPT$
>
> Notice that a literal "n" is printed after the 3rd error message,
> rather than a newline.
>
> The libtool-generated src/vte-2.91 script contains:
> printf %s\n "$relink_command_output" >&2
>
> where the backslash is swallowed by the shell and it becomes a literal
> "n".  It should be either double-backslashed, or enclosed between
> quotes.
>
> If you google "No such file or directoryn" with that extra "n" at the
> end, you'll see plenty of matches, so probably this is a common
> problem.

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).

What operating system is being used (output of 'uname -a')?

What is the output from 'config.guess' in the source tree?

What is the value of $SHELL?

What is the origin of the printf used?

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Egmont Koblinger <egmont <at> gmail.com>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 17478 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#17478: "No such file or directoryn" due to incorrect escaping
Date: Tue, 13 May 2014 10:49:33 +0200

[Message part 1 (text/plain, inline)]

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

[config.guess (application/octet-stream, attachment)]

[libtool.m4 (application/x-m4, attachment)]

[ltmain.sh (application/x-sh, attachment)]

[vte-2.91 (application/octet-stream, attachment)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Egmont Koblinger <egmont <at> gmail.com>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 17478 <17478 <at> debbugs.gnu.org>, bug-libtool <at> gnu.org
Subject: Re: bug#17478: "No such file or directoryn" due to incorrect escaping
Date: Tue, 13 May 2014 10:57:30 +0200

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 <egmont <at> gmail.com> 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

Message #26 received at 17478 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Egmont Koblinger <egmont <at> gmail.com>, 
 Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 17478 <at> debbugs.gnu.org
Subject: Re: bug#17478: "No such file or directoryn" due to incorrect escaping
Date: Tue, 13 May 2014 11:36:54 +0200

On 2014-05-13 10:57, Egmont Koblinger wrote:
>> 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

Looks likely.

I think you should try to prepend \ to that $ECHO, I'll send a patch
for libtool proper shortly. Not sure how you should test this though,
when you are using the system libtool...

I.e. try to change that line to:
      \$ECHO \"\$relink_command_output\" >&2

Hope that helps!

Cheers,
Peter

Message #29 received at 17478 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Egmont Koblinger <egmont <at> gmail.com>, 
 Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 17478 <at> debbugs.gnu.org
Subject: Re: bug#17478: "No such file or directoryn" due to incorrect escaping
Date: Tue, 13 May 2014 11:50:42 +0200

[Message part 1 (text/plain, inline)]

On 2014-05-13 11:36, Peter Rosin wrote:
> On 2014-05-13 10:57, Egmont Koblinger wrote:
>>> 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
> 
> Looks likely.
> 
> I think you should try to prepend \ to that $ECHO, I'll send a patch
> for libtool proper shortly. Not sure how you should test this though,
> when you are using the system libtool...
> 
> I.e. try to change that line to:
>       \$ECHO \"\$relink_command_output\" >&2

Patch attached, as promised.

I'll hold of pushing this until I get some feedback.

Cheers,
Peter

[0001-libtool-delay-expansion-of-ECHO-until-the-wrapper-sc.patch (text/x-patch, attachment)]

Message #32 received at 17478 <at> debbugs.gnu.org (full text, mbox):

From: Egmont Koblinger <egmont <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 17478 <at> debbugs.gnu.org, Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Subject: Re: bug#17478: "No such file or directoryn" due to incorrect escaping
Date: Tue, 13 May 2014 12:59:43 +0200

Hi,

Thanks very much, it works as expected.

I've applied the patch to the system-wide /usr/share/libtool/config/ltmain.sh.

The only change in the generated vte-2.91 script is:
-    printf %s\n "$relink_command_output" >&2
+    $ECHO "$relink_command_output" >&2

Given that the script contains a couple more $ECHO's here and there to
print stuff, I assume this is the desired result.

Running the script produces the proper error message formatted
correctly, with newline instead of 'n':

PROMPT$ ./src/vte-2.91
gcc: error: vte_2_91-app.o: No such file or directory
gcc: error: vte_2_91-appresources.o: No such file or directory
gcc: error: ./.libs/libvte-2.91.so: No such file or directory
PROMPT$


thx again,
egmont

On Tue, May 13, 2014 at 11:50 AM, Peter Rosin <peda <at> lysator.liu.se> wrote:
> On 2014-05-13 11:36, Peter Rosin wrote:
>> On 2014-05-13 10:57, Egmont Koblinger wrote:
>>>> 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
>>
>> Looks likely.
>>
>> I think you should try to prepend \ to that $ECHO, I'll send a patch
>> for libtool proper shortly. Not sure how you should test this though,
>> when you are using the system libtool...
>>
>> I.e. try to change that line to:
>>       \$ECHO \"\$relink_command_output\" >&2
>
> Patch attached, as promised.
>
> I'll hold of pushing this until I get some feedback.
>
> Cheers,
> Peter
>

Message #35 received at 17478 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Egmont Koblinger <egmont <at> gmail.com>
Cc: 17478 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Re: bug#17478: "No such file or directoryn" due to incorrect escaping
Date: Tue, 13 May 2014 14:26:28 +0200

close 17478
stop

On 2014-05-13 12:59, Egmont Koblinger wrote:
> Thanks very much, it works as expected.

Glad to hear it!

> I've applied the patch to the system-wide /usr/share/libtool/config/ltmain.sh.

I suppose that would work, yes.

> The only change in the generated vte-2.91 script is:
> -    printf %s\n "$relink_command_output" >&2
> +    $ECHO "$relink_command_output" >&2
> 
> Given that the script contains a couple more $ECHO's here and there to
> print stuff, I assume this is the desired result.

Indeed.

> Running the script produces the proper error message formatted
> correctly, with newline instead of 'n':
> 
> PROMPT$ ./src/vte-2.91
> gcc: error: vte_2_91-app.o: No such file or directory
> gcc: error: vte_2_91-appresources.o: No such file or directory
> gcc: error: ./.libs/libvte-2.91.so: No such file or directory
> PROMPT$

Thanks for verifying that! I have now pushed the patch, and I'm
closing this bug.

Cheers,
Peter

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.