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?

Comments

And which "real Bourne shell" would that be?

[mj6798]

There have been lots of different versions of the "real Bourne shell" over the years. From a practical point of view, you should have no problem writing scripts that run in bash and in whatever shell you consider "real". Stick to the POSIX specs where possible.

However, why are you writing "installer scripts" anyway? If you want to deliver on Linux, please use the Linux packaging system. If you deliver on Solaris, please use the Solaris packaging system. Etc.

Re:Did you even read the complaint?

[aheitner]

Yes. I did.

And it was nonsensical.

If he's going to complain about bash being not exactly POSIX, he's got to show an example of an incompatibility (as a decent sometime bash and ksh hacker, I can't think of one -- and I can think of one subtlety that ksh and zsh do differently than POSIX: word splitting).

Ok. "export FOO=bar" doesn't work on a strictly-POSIX shell. But why is it bad for that to work in bash (and ksh and zsh)? How does that hurt you?

Instead, why doesn't the article's poster come up with an example of a valid POSIX statement that breaks in bash -- that way he actually has a complaint: he did something POSIX (i.e., the standard), and bash did the wrong thing. As it stands, he's just griping.

I mean, I agree with him -- bash is bloated and not a good choice for scripting. But that just means that scripts should be written in a shell optimized for scripting -- ksh. Or at least a minimalist straightforward POSIX shell (ash).

But if a system wants to provide just one POSIX shell (to save space, or whatever), and if bash is going to be used by 95% of users anyhow (so is likely to be loaded anyhow), making the one POSIX shell available on the system be bash isn't a bad call. Now that doesn't excuse scripts using non-POSIX features under the name of /bin/sh. But I'd hazard to guess that 99% of the time those scripts are distro-specific in many other ways, so it doesn't really matter.

I still have yet to see how (from anything but an efficiency perspective), this guy is finding that bash somehow makes his life harder.

(side-point: it is annoying that you can't solve the efficiency problem by relinking /bin/sh to ksh or ash, since all the system scripts will do slightly-non-POSIX things and therefore should be specifying /bin/bash).

...

I apologize for my confrontational tone. It really irks me when people propose writing things without bothering to check if the work has been done for them. I mean, come on, guys, it's Free Software. Avoiding duplication is the name of the game.

(Sorry, a little clarification)

[aheitner]

I apologize if my tone comes off confrontatively :-).

I'm reacting negatively to the idiotic suggestion that people need to waste time "writing a real Bourne shell for Linux".

If you don't like bash, there are several other shells which attempt to be POSIX. Some of them are quite strict (ash). Some are optimized for scripting (ksh).

If you want to argue that bash sucks and should be replaced as the default system scripting shell, I totally agree. If you want to say that it sucks when scripts request /bin/sh but use bash-specific features, I agree.

But for goodness sake, give some respect to the work that's been done.

...

I did see one good post noting the bash specifics that are missing, as a POSIX shell. They really are quite minor...

Re: (Sorry, a little clarification)

[psamuels]

In bash you cannot do this:
test -d "$dir" || ( echo "$dir doesn't exists"; exit 1)

That's buggy, isn't it? The () force the 'exit 1' to occur in a subshell, so the main script doesn't exit anyway. Use {...;} instead of (...) for what you want.

Thus, autoconf creates this kind of exit:

What you are seeing in autoconf macros is an attempt to support every single Unix vendor shell ever released, including old versions of bash that had weird bugs since bash had not yet matured ... but also weird bugs in old versions of other shells. Are you sure the above workaround is for bash, specifically?

[As an aside, note that the autoconf macro also directs output to two separate files, adding to its complexity. Apples to apples, etc.]

If you are trying to do that, certainly you will have to jump through hoops.

If you can assume bash 2.0 or above, you shouldn't really need any bash workarounds.

Depends on what your requirements are, I guess.

Re:It's a non-issue.

[seebs]

Embrace and extend. There is no way to write a script in bash and have bash warn you if you're using an extension, so they tend to creep into scripts. Embrace and extend is evil; the compatability mode should be *pure* sh, with no extensions.