Slashdot Mirror
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?
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.
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.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Ever try ash? Here's a size comparison just to intrigue you a bit.
assert(expired(knowledge));
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.)
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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
* 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
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 based on user account deletion
The following works in UNIX sh, but not in bash:
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.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
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 :-)
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?
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.
Would this compile? I tried building the FreeBSD telnetd source on other systems when the telnetd exploit came out, and it wouldn't build.
/usr/local, and bash 1.x isn't statically linked, so you can't use it in single user mode (bash 2.x is).
:)
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
I still prefer bash, despite FreeBSD's objections
chris@xanadu:~$ whatis /.
/.: nothing appropriate.