Slashdot Mirror


A Real Bourne Shell for Linux?

the_code_poet asks: "I'm a lead developer for a software development company, and one of my responsibilities has been writing an installer for our product (of which Linux is one of the platforms). In keeping with UNIX tradition, the installer is written in shell (thats /bin/sh), but as many of you know there is no Bourne shell for Linux - only bash. This has caused inconsistencies (mostly bugs in bash) when writing a generic UNIX sh script that works fine on commerical *NIX's." For a semi-complete list of differences between bash and sh, you will want to check out section C1 of the Bourne Again Shell FAQ. To be honest, I have yet to run into much trouble with a script starting with #!/bin/sh with /bin/bash, and I've been using the latter for years. If any of you have had problems related to this, please tell us what the problem was and how you solved it. Also: would anyone out there be interested in writing a real Bourne Shell for Linux?

"On every distro I've ever seen /bin/sh is just a soft link to /bin/bash. If bash is invoked with sh as its name (argv[0]) then its supposed to act like Bourne - but that just doesnt happen (for example: export FOO=bar is *not* valid Bourne shell syntax, you must say FOO=bar; export FOO)

Do you think that the startup scripts for most distributions would break because, even though they say
#!/bin/sh at the top, they REALLY mean #!/bin/bash?

Given that there is no real Bourne shell for Linux, and that bash has an exhorbitant file size. Quoting bash's man page, here: '...it's too big and too slow' for something that is to be used as the defacto-standard shell for scripting, do you think its a worthy venture to set out to write a small, tight, pure Bourne shell?

*asbestos disclaimer*: This has nothing to with Bash as an interactive user shell and has nothing to do with a holy war over who's favorite shell is better than whomever's."

While doing a small bit of research on this question, I noted there was another Bourn-compatible shell out there called "ash", yet it's billed as doing "some things better and some things worse than bash". Does anyone use it, and find it better than bash for their shell scripting needs?

3 of 388 comments (clear)

  1. use ash by raulmazda · · Score: 0, Redundant

    ~% apt-cache show ash
    Package: ash
    Priority: optional
    Section: shells
    Installed-Size: 180
    Maintainer: Herbert Xu <herbert@debian.org>
    Architecture: i386
    Version: 0.3.8-29
    Pre-Depends: libc6 (>= 2.2.4-2)
    Filename: pool/main/a/ash/ash_0.3.8-29_i386.deb
    Size: 70564
    MD5sum: a9ec33985be6e3a4c350ef19d377c43a
    Description: NetBSD /bin/sh
    "ash" is a POSIX compliant shell that is much smaller than "bash".
    We take advantage of that by making it the shell on the installation
    root floppy, where space is at a premium.
    .
    It can be usefully installed as /bin/sh (because it executes scripts
    somewhat faster than "bash"), or as the default shell either of root
    or of a second user with a userid of 0 (because it depends on fewer
    libraries, and is therefore less likely to be affected by an upgrade
    problem or a disk failure). It is also useful for checking that a
    script uses only POSIX syntax.
    .
    "bash" is a better shell for most users, since it has some nice
    features absent from "ash", and is a required part of the system.

  2. You know what they say by Man+of+E · · Score: 1, Redundant

    Bourne a shell, always a shell...

    --
    Ceci n'est pas une sig
  3. Re:Which direction are you worried about? by Crag · · Score: 0, Redundant

    Did you even read the post you replied to?

    "The_code_poet clearly asked about compatibility going from sh to bash."

    You replied "Having things work under bash that won't work under sh is exactly what makes it hard to test sh scripts in an environment that only has bash."

    That's exactly the opposite of what the original question was about AND what the response you replied to was about.

    The point is not "how we can write scripts .. when we're developing on linux", it's how to be sure a /bin/sh script written outside of linux will work on linux, and the answer is not to depend on any of the sh-isms listed in the parent.

    Pay more attention next time, AC.