3266 2006-09-26 16:02:00 +0000 ldd doesn't work when /bin/sh is dash 2010-08-09 18:38:47 +0000 1 1 1 Unclassified glibc libc 2.3.6 All All RESOLVED WONTFIX P2 normal --- 1 sqweek drepper.fsp glibc-bugs richardvoigt oldest_to_newest 12394 0 sqweek 2006-09-26 16:02:42 +0000 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 <http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_01>, 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). 12422 1 drepper.fsp 2006-09-27 17:00:16 +0000 Then don't use dash. bash is the only supported shell. 12517 2 1342 sqweek 2006-10-02 08:38:39 +0000 Created attachment 1342 Fix ldd to rely on its proper interpreter Works for me, so long as ldd stops claiming to be POSIX compatible. 17793 3 richardvoigt 2007-07-04 15:44:13 +0000 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. 17794 4 richardvoigt 2007-07-04 15:47:08 +0000 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 } 17796 5 drepper.fsp 2007-07-04 16:46:51 +0000 Stop reopening. bash is the only supported shell. Maintain your own changes if you must but stop burdening others. 17798 6 richardvoigt 2007-07-04 17:53:29 +0000 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. 44277 7 a4239214 2010-07-30 11:56:39 +0000 This is stupid. 44278 8 jakub 2010-07-30 12:02:14 +0000 See #c5. 44491 9 sqweek 2010-08-09 18:38:47 +0000 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. 1342 2006-10-02 08:38:00 +0000 2006-10-02 08:38:39 +0000 Fix ldd to rely on its proper interpreter ldd.patch text/plain 251 sqweek LS0tIGxkZC1zaAkyMDA2LTEwLTAyIDE2OjUwOjAwLjAwMDAwMDAwMCArMDgwMAorKysgL3Vzci9i aW4vbGRkCTIwMDYtMTAtMDIgMTY6NTA6MTIuMDAwMDAwMDAwICswODAwCkBAIC0xLDQgKzEsNCBA QAotIyEgL2Jpbi9zaAorIyEgL2Jpbi9iYXNoCiAjIENvcHlyaWdodCAoQykgMTk5Ni0yMDA0LCAy MDA1IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgogIyBUaGlzIGZpbGUgaXMgcGFydCBv ZiB0aGUgR05VIEMgTGlicmFyeS4KIAo=