Bug 3266 - ldd doesn't work when /bin/sh is dash
Summary: ldd doesn't work when /bin/sh is dash
Status: RESOLVED DUPLICATE of bug 832
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.6
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
Depends on:
Reported: 2006-09-26 16:02 UTC by sqweek
Modified: 2023-10-28 17:11 UTC (History)
5 users (show)

See Also:
Last reconfirmed:
fweimer: security-

Fix ldd to rely on its proper interpreter (184 bytes, patch)
2006-10-02 08:38 UTC, sqweek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description sqweek 2006-09-26 16:02:42 UTC
The problem is in line 122:
122:if set -o pipefail 2> /dev/null; then

 When dash hits the unknown pipefail option, it prints a diagnostic (which is
suppressed of course) and then exits. This appears to be well within the rights
of a compliant shell
though it's arguable whether the specific case of "set -o foo" is covered
(especially since the table entries aren't exactly explicit about their
meaning). Anyway, I mean to contact dash about this aswell but I didn't find a
mailing list or bug database - only got as far as here tonight.

 As an aside, ldd also uses bash style $"" strings all over the place despite
claiming to be bourne compatible via #!/bin/sh (of course this still works in
dash you just get random $ signs in the output).
Comment 1 Ulrich Drepper 2006-09-27 17:00:16 UTC
Then don't use dash.  bash is the only supported shell.
Comment 2 sqweek 2006-10-02 08:38:39 UTC
Created attachment 1342 [details]
Fix ldd to rely on its proper interpreter

 Works for me, so long as ldd stops claiming to be POSIX compatible.
Comment 3 Ben Voigt 2007-07-04 15:44:13 UTC
Do you really think it is appropriate for the C runtime library to dictate which
shells need to be installed?  That kind of dependency seems very backwards.

Note that one effect of this decision is to make ldd worthless on a busybox system.
Comment 4 Ben Voigt 2007-07-04 15:47:08 UTC
Anyway, I have a much shorter, much cleaner patch:

 # environments where the executed program might not have permissions
 # to write to the console/tty.  But only bash 3.x supports the pipefail
 # option, and we don't bother to handle the case for older bash versions.
-if set -o pipefail 2> /dev/null; then
+if (set -o pipefail) 2> /dev/null; then
+  set -o pipefail
   try_trace() {
     eval $add_env '"$@"' | cat
Comment 5 Ulrich Drepper 2007-07-04 16:46:51 UTC
Stop reopening.  bash is the only supported shell.  Maintain your own changes if
you must but stop burdening others.
Comment 6 Ben Voigt 2007-07-04 17:53:29 UTC
Just FYI -- I've never before reopened this bug.  If you are finding that the
bug keeps being opened, then it is something that a lot of your users care
about, not the same user bugging you continually.
Comment 7 Henk Stubbe 2010-07-30 11:56:39 UTC
This is stupid.
Comment 8 Jakub Jelinek 2010-07-30 12:02:14 UTC
See #c5.
Comment 9 sqweek 2010-08-09 18:38:47 UTC
i agree, that the assumption /bin/sh is bash continues to be deemed correct IS 
incredibly stupid. "all the world's a vax" -> "all the shs are bash".

if you don't want to support other shells, that is FINE and understandable. just 
ask the kernel for what you actually want, /bin/bash.
Comment 10 P. J. McDermott 2013-09-07 15:45:02 UTC
Reopening, with a patch on the way to the mailing list.
Comment 11 Mike Frysinger 2013-10-14 06:01:01 UTC

*** This bug has been marked as a duplicate of bug 832 ***
Comment 12 Jackie Rosen 2014-02-16 18:27:16 UTC Comment hidden (spam)