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?

It's a non-issue.

[mindstrm]

You are looking for a solution to a problem that does not exist.

bash is backward compatable to sh. Period.

Yes, you can do things in bash you can't do in sh, but not vice-versa.

If you write your scripts for stock Bourne, they will run fine under bash.

Did you even read the complaint?

[Wakko Warner]

The guy writes installer scripts for a living. Every other unix has a Bourne shell implementation except Linux, and Linux's /bin/bash has incompatibilities. Telling the guy to fuck off and use something else has got to be the most ignorant thing I've ever heard. I'm sure he can tell his boss the same thing, right? "Fuck this, I'm gonna use ksh so it works on... AIX only!"

Ask Slashdot becomes less helpful by the nanosecond.

- A.P.

Ash

[runswithd6s]

Ever try ash [debian.org]? Here's a size comparison just to intrigue you a bit.

(82780) /bin/ash*

(407356) /bin/bash*

Re:And which "real Bourne shell" would that be?

[psamuels]

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.

The Linux packaging system? There are several, at least three of which (rpm, deb, tgz) are in common use.

It's a valid question, but there are a lot of packaging systems out there - the ones for AIX, HP-UX and IRIX don't resemble each other in the least. Besides, while I don't mind installing packages on AIX or IRIX, the HP-UX 'depot' format and supporting tools are so clumsy that I'd rather run a vendor install script, and worry about uninstalling "manually", any day of the week. (In practice, vendors like Dassault, PTC and MSC never use the native install format - they always supply a script. And that script always seems to assume POSIX shell features. It is also always poorly-written, but that's a different rant.)

Which direction are you worried about?

[MarkusQ]

I think that there is some confusion here. The_code_poet clearly asked about compatibility going from sh to bash (i.e., he wants to write standard sh scripts and have them work on linux, and therefore bash). But the incompatibilities everyone is discussing (e.g. initialized export syntax) are all going the other way; things that you can write under bash that won't work under sh. So what?

The things that matter are first, the things sh has that bash does not (from the FAQ):

* uses variable SHACCT to do shell accounting
* includes `stop' builtin (bash can use alias stop='kill -s STOP')
* `newgrp' builtin
* turns on job control if called as `jsh'
* $TIMEOUT (like bash $TMOUT)
* `^' is a synonym for `|' * new SVR4.2 sh builtins: mldmode, priv

...and the implementation differences:

* redirection to/from compound commands causes sh to create a subshell
* bash does not allow unbalanced quotes; sh silently inserts them at EOF
* bash does not mess with signal 11
* sh sets (euid, egid) to (uid, gid) if -p not supplied and uid < 100
* bash splits only the results of expansions on IFS, using POSIX.2 field splitting rules; sh splits all words on IFS
* sh does not allow MAILCHECK to be unset (?)
* sh does not allow traps on SIGALRM or SIGCHLD
* bash allows multiple option arguments when invoked (e.g. -x -v); sh allows only a single option argument (`sh -x -v' attempts to open a file named `-v', and, on SunOS 4.1.4, dumps core. On Solaris 2.4 and earlier versions, sh goes into an infinite loop.)
* sh exits a script if any builtin fails; bash exits only if one of the POSIX.2 `special' builtins fails

None of these seem to me to be show-stoppers if you are writing the script from scratch (or even porting a reasonably written one)--I mean really, are you counting on it to dump core if you use multiple option arguments? Is there some reason you can't ballane your quotes? So my question to the_code_poet is, what exactly are you trying to do in sh that won't work in bash?

--MarkusQ

Re:No other OS?

[green pizza]

1. There is no such thing as Solaris 2.8, and 2.7 only exists in some places. I assume you meant 7 and 8.

Bah, "Solaris" is the marketing name. It's SunOS 5.8. Do a 'uname -a' if you don't belive me. Besides, it fits perfectly with SunOS history... versions prior to 5.0 were BSD based, version 5.0 and newer are heavily SysV based. The whole "Solaris" name just confused everyone.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Example bash bug

[kevinank]

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.

The following works in UNIX sh, but not in bash:

/sbin/ls -l | while read bits links user group size junk ; do
echo $user $group
done

To work around the bug you can either put the output of ls into a file and redirect input to read from the file, or you can use an immediate mode file (EOF) in the script, but pipes are broken with respect to read.

Re:Example bash bug

[wayne]

You don't say what the results from using bash are, but your code worked just as I would expect on my Debian system using bash. That is, it prints out the user and group of each file in the current directory. Well, I had to change /sbin/ls to ls (or /bin/ls), but that doesn't seem to be a problem with bash...

Re:As to distro startup scripts...

[kaisyain]

Strange, I remember complaining on debian devel about four or five years ago about this -- about how debian assumed that /bin/sh was bash. Everyone told me to shut up and go away because it was obvious that /bin/sh was bash on linux. I'm glad to hear they've finally decided I was right :-)

Re:Too much history

[Evangelion]

There is some room for improvement in the art here. It bothers me that the first goal is to be compatible with something that ran in 1971.


That "goal" is to provide people on Linux with a shell with which they can develop portable sh scripts. One that, by being written to, allow you to write scripts that will run on all the other POSIXish sh's out there on other Unicies. Because, well, those things are nessecary in the real world.

Why does giving system administrators and developers what they need to make thier lives easier bother you?

Check for bash during configure

[Charlotte]

The problem is that Linux programmers don't stop to think about whether the shell they use e.g. during installation or with wrappers, is actually present on the system.

Being a solaris admin I regularly have to edit shell scripts to put the right path for bash in (/opt/local/bin/bash).

Software programmers should make their code more portable. In other words, fix configure to look for bash in the path and use that at the top of installation/wrapper scripts. In normal circumstances making the fixes isn't that much work, but you can see that it becomes much more of a problem when compiling something as humungous as Gnome because you can't automate the compiles/installs.

Re:Easy.

[prog-guru]

Would this compile? I tried building the FreeBSD telnetd source on other systems when the telnetd exploit came out, and it wouldn't build.

FreeBSD seems to favor csh anyway, root's shell is csh, they say don't every never change root's shell or your scripts will break (although they are sh scripts), bash is not installed in the base system, the package manager installs it in /usr/local, and bash 1.x isn't statically linked, so you can't use it in single user mode (bash 2.x is).

I still prefer bash, despite FreeBSD's objections :)