A Real Bourne Shell for Linux? 388
"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?
Easy. (Score:5, Informative)
- Download FreeBSD source.
- cd
/usr/src/bin/sh; make; make install
AFAIK the BSD Bourne shell is more or less the same as the real Bourne shell.2nd hit on Google (Score:0, Informative)
Try this out! (Score:1, Informative)
Say the following:
File 1: Shell script to determine what *nix you are running
File 2: Bourne shell script
File 3: bash shell script
File 1 determines whether to use Bourne shell script of bash shel script and passes it onto decided shell.
Just a thought... hope I could be helpful!
-theKGB 8)
Slackware uses ash for toolset (Score:5, Informative)
Basically, Slackware uses ash for development for the exact reasons you're looking for a Bourne-compatible shell.
Have fun.
bash as /bin/sh (Score:4, Informative)
You haven't seen Polished Linux Distribution [pld.org.pl]. PLD's
(Plus, PLD is fully IPV6 ready
Bourne shell or POSIX shell? (Score:5, Informative)
Many would. However, note that POSIX requires /bin/sh to be a POSIX shell, whose specs are derived mostly from the Korn Shell - so ksh is a valid POSIX shell, as is Bash, modulo a few features. Plain-vanilla Bourne shell is not.
AIX has the same dilemma: to be POSIX-compliant they have /bin/sh -> ksh and /bin/bsh is the real Bourne. HP-UX 11 has /bin/sh distinct from ksh, but it too allows things like 'export FOO=BAR'. I don't know if a real Bourne shell exists on HP-UX.
For a POSIX shell without the bash overhead, use ash, which is distributed with many (most?) Linux distributions. ash is the NetBSD /bin/sh, and at least on Debian the installation gives you the /bin/sh symlink option as well. Let me tell you, ash is much faster than bash in the autoconf-generated-configure "benchmark".
Since many Debian people use ash for /bin/sh, packages regularly have bugs filed -- and fixed -- vis-a-vis #!/bin/sh vs. #!/bin/bash. I don't know how careful other distros are about this sort of thing. Note that even many Debian scripts would fail if you found a real Bourne shell for /bin/sh rather than a POSIX-compliant shell.
As to distro startup scripts... (Score:3, Informative)
I couldn't say for other distros, but Debian policy [debian.org] says that /bin/sh can be any POSIX-compatible shell, with the one extension that 'echo -n' must not generate a newline. If any script uses /bin/sh assuming bash features, it's considered a serious-level bug.
Re:It's a non-issue. (Score:5, Informative)
Even if every valid bourne script runs perfectly under bash there is still a problem.
That problem is that an interpreter enforces valid syntax. It would be nice if everyone who wanted to write a portable (read bourne) script spent a month studying and was totally zen-ed out on the subject. But that 'aint the real world.
I personally could benefit from a real sh on Linux, since it is the only *NIX I have, and I can't test scripts for sh compatibility without it.
To be more specific, I wrote a bash script that was included in an OSS project. The maintainer wanted me to change the first line from "#!/bin/bash" to "#!/bin/sh" "for compatibility." I told him that I wasn't comfortable with this since the script wasn't tested on sh. He said he tested it and it worked fine. I asked him if he really tested it with sh or with "/bin/sh ->
A while later we got a bug report on the list to the effect "your script is not a valid sh script." Luckily the guy sent a diff, and I tested it with bash. I guess it works with sh now too, but I still don't know for sure.
See how it isn't a non-issue, at least for me?
-Peter
Re:2nd hit on Google (Score:2, Informative)
Here is the source to what is very close to "the real thing"
ftp://ftp.freebsd.org/pub/FreeBSD/branches/4.0-
So the answer is still, "Use the real bourne sh" and here is how you do it. Download, compile (on linux) and install to some place that won't effect linux. Have your install script call the newly made "real" shell.
Wasn't hard eh?
Portable Shell Programming (Score:2, Informative)
As an aside, there has been a lot of extensive research on making portable shell scripts. Bruce Blinn's book Portable Shell Programming: An Extensive Collection of Bourne Shell Examples [amazon.com] is a good resource that might help as well as GNU Autotools documentation [huji.ac.il], which is the definitive guide on this sort of thing. Another useful jumping off point that has some good materials and a lot of useful links is Shell Script Porting Guidelines [raycosoft.com]
Re:bash SUCKS, csh ROCKS! (Score:2, Informative)
This reads like a troll, but it could be sincere, so I'll treat it seriously. How do you open more than two output file or more than one input file concurrently? csh has no primitives for opening and closing files beyond redirecting a single command or pipeline. Even for something as simple as redirecting stdout to one file and stderr to another, you have to jump through hoops.
I won't read back to you the famous Considered Harmful [perl.com] file, but the above point is probably the main reason I would never program with csh scripts. Sure, csh has some programming features Bourne shell lacks, but ksh/bash/POSIX have those same features. Opening and closing arbitrary files is something I do in my scripts all the time.
Re:Did you even read the complaint? (Score:1, Informative)
> Yes. I did.
> And it was nonsensical.
It just appeared that way because you didn't understand it. Read it again and concentreate
The poster wasn't complaining of POSIX things not working in bash, he was complaining of non-POSIX things working.
If you don't understand why this is important, you shouldn't be posting in this thread: Good software engineering requires the ability to QA software in an environment similar to that of your target platform. If your target platform has bourne shell only, and your development environment is linux, where the closest thing to sh is a bit different, then you're missing an element that's usually required to produce good software.
Ironically, you yourself prove this point by complaining about the problems that come up when
IMHO the solution to this real problem is to submit bugs to bash for any behavior that's incompatible with plain bourne when it's invoked as
Re:It's a non-issue. (Score:2, Informative)
Actually, what he says is not even valid. If anyone had bothered to read the link that Cliff helpfully posted, they would see that there are several things bash does not do, and several things that are 'implemented differently'. The following is taken from that page:
Things sh has that bash does not:
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
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
Re:Which direction are you worried about? (Score:1, Informative)
Indeed there is. In fact, you seem quite confused
> Things that you can write under bash that
> won't work under sh. So what?
So what? Some people like to test their software. I know, it's an old fashioned idea, but let's try to humor those quaint folks in this thread.
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.
Moderators, you might want to mark down messages like the parent that miss the point entirely.
Now back to the point, which is discussing how we can write scripts to be run on environments with bourne shell only when we're developing on linux, which doesn't have a fully compatible bourne shell.
Linux Standard Base (Score:5, Informative)
Others have addressed the various issues about what is a "real" Bourne shell and bash extensions and all that. Anyway, the Linux Standard Base has a section [linuxbase.org] on shells. In a nutshell, bash 2.x was the most POSIX-compliant of the shells that the LSB tested (and no, I don't know exactly what versions or which shells or the like), with pdksh getting an honorable mention. And there were two ways in which bash was not POSIX-compliant and concerning which the LSB therefore diverges from POSIX (whether $0 is the full pathname or just the basename, and what happens if you try to use "." to run a script without the read bit set). I don't know whether a future version of POSIX is planning to change the specification, or whether this is likely to remain a divergence for the foreseeable future or what. In any event, these two issues shouldn't be hard to deal with in writing scripts.
Re:Easy. (Score:2, Informative)
Also, recent FreeBSD 4.x releases have replaced 4.4BSD csh with tcsh (original csh being available as a port).
Re:bash SUCKS, csh ROCKS! (Score:2, Informative)
I had to port a 1500 line csh script from Ultrix to SunOS, Solaris, Dec OSF, HP-UX, and SGI Irix.
After getting it to work on Ultrix and SunOS, I tried to get it going on Solaris. csh wasn't even portable from SunOS to Solaris!
The solution was to use
Re:Too much history (Score:2, Informative)
Circa 1971 Algol68 was a 'state of the art launguage', mind you it was one that proved to be a bit too hard to implement well. Most of the easy stuff ended up in Pascal (and some in pascal).
C's 'struct' and 'union' keywords for example almost surely came from (or via) algol68
Re:Not "sh" for Linux... (Score:2, Informative)
Granted, not really Linux-related answer, however it does answer the question. Also, note last para of the question -- this is not about interactivityportability.
Re:Easy. (Score:0, Informative)