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?
Re:It's a non-issue. (Score:2, Insightful)
If you want to use sh, start with #!/bin/sh rather than #!/bin/bash - the executable notes which name you invoke it with and adjusts a couple of minor details of behaviour accordingly.
Re:Try this out! (Score:2, Insightful)
first, what's the first script to be written in, that it'll run on any unix? i guess this is easier than the general case, but still not an issue to ignore.
also, this more than duplicates the work of writing and maintaining these scripts. you've got the install scripts twice, plus the selector script.
And which "real Bourne shell" would that be? (Score:4, Insightful)
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:Easy. (Score:1, Insightful)
He just gave a valid solution.
Include the FreeBSD source to
I am hoping it was just accidentally marked down with the thought: "Oh no, someone is telling him to install FreeBSD, better mark it down"
This is not what the parent was suggesting. Read carefully before blindly modding down based on seeing something you don't like...
Re:Did you even read the complaint? (Score:4, Insightful)
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
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
...
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.
Re:How linux is still an inferior desktop OS (Score:1, Insightful)
Face it, gnome is dead. all of the gnome developers should switch to KDE or else their work will be at loss.
(Sorry, a little clarification) (Score:3, Insightful)
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
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:It's a non-issue. (Score:5, Insightful)
Re:Not "sh" for Linux... (Score:1, Insightful)
bash is not 100% compatible. If I want bash, I use #!/bin/bash, but if I use #!/bin/sh and write Bourne shell code, I expect it to not break.
If bash is used as
/bin/sh is the Bourne shell,
Re: (Sorry, a little clarification) (Score:4, Insightful)
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.
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:Did you even read the complaint? (Score:2, Insightful)
In that case, the question should have been more like "(a) why didn't someone open-source the real Bourne shell many years ago so we could have had a mature implementation of /bin/sh, or (b) why didn't Red Hat license the real Bourne shell, or (c) why did Chet not squash all the bash bugs by the time he released 1.14, so when Red Hat went to use it with RH Linux 6.1 they would have a solid sh implementation?"
The answers are easy enough: (a) the owner of the Bourne shell didn't release it as open source for ... well, whatever reason, it's not important. The important thing is, they didn't, so what are you gonna do about it? Answer: write a new implementation. And that's what Chet and co. did for the GNU project with bash, only it was started many many years after the original sh, so until a few years ago it still had weird bugs in it. The answer to (b) is that Red Hat chose to use only open-source software for ... again, the reasons are not important here.
As for (c), whose fault is it that a buggy bash was shipped with Red Hat Linux 6.1? Dunno - I think bash 2.0 was out and in active use by the time it shipped, but I'm not sure. And I'm not sure ash wasn't just as bad, at the time, so you can't blame Red Hat for that either.
In summary, he (and you) are griping about what someone released a couple years ago and they (and you) are still forced to support. Nothing much can be done about it now - it's a solved problem, bash 2.x has been out for quite awhile, but you can't really make people upgrade to it. (Same goes for alternative shells like ash - they're available and they work fine, but you can't make people install them either.)
More Details, Please (Score:1, Insightful)
What exactly were the "inconsistencies"? How many were there? What features did they involve? I've been in the business long enough to recognize situations where my own unfamiliarity with a particular technology spanks me hard. Perhaps the original poster is finding him/herself in a similarly humbling situation?