3 ms·

Support for different shells (GLIBC only supports bash). What exactly does this mean? How does a libc "support" a shell? I thought it was the other way aroun

by drewr 17y ago

Support for different shells (GLIBC only supports bash). What exactly does this mean? How does a libc "support" a shell? I thought it was the other way around. Clearly tons (all?) of shells already run on glibc systems. Is this something that's only relevant for embedded systems?

ivank 17y ago
The linked-to bugs just indicate that Ulrich Drepper wasn't interested in making the test suite or ldd work without bash.
- mbrubeck 17y ago
  And that he wouldn't accept already-completed patches to do so, and told their authors to maintain their own fork if they wanted to use other shells.
pc 17y ago
Basically, glibc includes bash-specific shell scripts. You probably can't build glibc without bash, and some glibc components (like ldd, as the blog post points out) require bash.
silentbicycle 17y ago
From the diff (http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/nptl/Makefile?rev=8028&view=diff&r1=8028&r2=8027&p1=trunk/libc/nptl/Makefile&p2=/trunk/libc/nptl/Makefile http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/nptl/Ma...) and this bug (http://sources.redhat.com/bugzilla/show_bug.cgi?id=9901 http://sources.redhat.com/bugzilla/show_bug.cgi?id=9901), it looks like bash is hard-coded as the shell used for the test suite (and possibly other internal behavior, like spawning sub-processes). Speaking as somebody who ports stuff to OpenBSD, it's a surprisingly common assumption in Linux programs that the standard shell is bash, when in fact it's not necessarily present on any other Unix. (sh, the bourne shell, is the default.) While this sounds nitpicky, it's quite annoying to have problems testing a program because every single test case script has #!/usr/bin/bash hardcoded at the top. If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.
- nailer 17y ago
  'If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.' Are you sure? Bash-style functions and arithmetic subshells are pretty common. As long as they don't label the script with the Bourne interpretar (/bin/sh) then Bash scripting is fine.
  - silentbicycle 17y ago
    I'm talking about incidental scripts included with programs for e.g. installation and regression testing, not scripts that encompass a lot of primary functionality. And, yes, it happens periodically enough to be considered a Linux-ism to watch for while porting.

by drewr 17y ago

ivank 17y ago

The linked-to bugs just indicate that Ulrich Drepper wasn't interested in making the test suite or ldd work without bash.

mbrubeck 17y ago
And that he wouldn't accept already-completed patches to do so, and told their authors to maintain their own fork if they wanted to use other shells.

pc 17y ago

Basically, glibc includes bash-specific shell scripts. You probably can't build glibc without bash, and some glibc components (like ldd, as the blog post points out) require bash.

silentbicycle 17y ago

From the diff (http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/nptl/Makefile?rev=8028&view=diff&r1=8028&r2=8027&p1=trunk/libc/nptl/Makefile&p2=/trunk/libc/nptl/Makefile http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/nptl/Ma...) and this bug (http://sources.redhat.com/bugzilla/show_bug.cgi?id=9901 http://sources.redhat.com/bugzilla/show_bug.cgi?id=9901), it looks like bash is hard-coded as the shell used for the test suite (and possibly other internal behavior, like spawning sub-processes). Speaking as somebody who ports stuff to OpenBSD, it's a surprisingly common assumption in Linux programs that the standard shell is bash, when in fact it's not necessarily present on any other Unix. (sh, the bourne shell, is the default.) While this sounds nitpicky, it's quite annoying to have problems testing a program because every single test case script has #!/usr/bin/bash hardcoded at the top. If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.

nailer 17y ago
'If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.' Are you sure? Bash-style functions and arithmetic subshells are pretty common. As long as they don't label the script with the Bourne interpretar (/bin/sh) then Bash scripting is fine.
- silentbicycle 17y ago
  I'm talking about incidental scripts included with programs for e.g. installation and regression testing, not scripts that encompass a lot of primary functionality. And, yes, it happens periodically enough to be considered a Linux-ism to watch for while porting.