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?
- 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."The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
Starting your scripts with #!/bin/bash shows that you live in a Linux-centric world. No other OS puts bash under /bin. Since there's normally a link from bash to sh, it really makes sense for compatibility reasons to use #!/bin/sh. Of course, if you use bash-specific features in your scripts, your scripts won't be portable anyway and it doesn't really matter, I suppose.
You had me at "dicks fuck assholes".
Why couldn't you just write a small script that chooses what shell to use at the beginning?
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)
Eric... You suck...
You can easily compile and install bash on HP-UX.
(I've done it in under 2 minutes.)
Also, there are people committed to distribution of most popular GNU tools in binary for HP-UX and other commercial *NIXes, even though most compile and install from source without problems.
(with the notable exception of gcc of course. Sheeesh -- try and get THAT to compile cleanly!)
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.
hash bang slash bin slash bash
Basically, Slackware uses ash for development for the exact reasons you're looking for a Bourne-compatible shell.
Have fun.
"On every distro I've ever seen /bin/sh is just a soft link to /bin/bash." /bin/sh is not bash, and all 'bashisms' are removed from distribution's scripts - it's all plain /bin/sh.
:)
You haven't seen Polished Linux Distribution. PLD's
(Plus, PLD is fully IPV6 ready
:wq
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.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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));
On the other hand, sometimes you just don't care, and you can make full use of bash or ksh or whatever.
I couldn't say for other distros, but Debian policy 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.
--
perl -e'$_=shift;die eval' '"$^X $0\047\$_=shift;die eval\047 \047$_\047"' at -e line 1.
How is that helpful? It suggests "download[ing] the real thing and use[ing] that" with no link or even indication of where to get the real thing.
I was excited when I saw this story, and again when I saw your post, because I had the same question in the past and was never able to find a satisfactory answer.
Still haven't.
-Peter
For information on Korn shell, see http://www.kornshell.com/
With ksh, you can more easily interoperate with commercial UNIX systems, which now a days all come with ksh.
I've read the list of differences in the FAQ. It's just a big list of extensions to the Bourne shell. It doesn't list any incompatibilities (except for a couple of obscure missing features which you probably shouldn't use anyway). If you write something in standard Bourne syntax, there should be no problems with Bash.
:)
If you, on the other hand, test it with Bash, and then assume it will run under any other Unix... Well, you shouldn't do that with GNU software
not to mention the fact that your "suggestion" totally ignore the guys problem: writing a cross-platform install script. zsh is totally non-standard, so that's out. ksh is pretty common, but not totally common, and is installed as different things in different places. there's definatly a place for a standard (you linux guys remember those, don't you?), and, for the time being, bourne shell's it. so either linux gets with the standard program, or it continues to be a pain.
i speak for myself and those who like what i say.
It suggests
/.
Ksh93 may be had, precompiled for Linux, via www.kornshell.com
Which another poster in the thread has said works.
Also, it shows that lots and lots of people have asked the same question already - and got similar answers to the answers posted here. Doing a bit of research is quicker than submitting an ask
---
http://slashdot.org/moderation.shtml
I don't know the exact reason why... I barely know anything about shell scripting... but some shells that say /bin/sh will only work on my system if they use bash. Ash fails due to some difference in how it handles parentheses or file names or something... hopefully someone who knows shell scripting can elaborate ;)
-- Is "Sig" copyrighted by www.sig.com?
"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)" Not quite right. the syntax export VAR=VALUE is a shorthand method. It is still perfectly alright to VAR=VALUE and then export VAR. I've not run into a comptability problem running scripts under bash, but that does not mean they exist. You can of course recompile bash to function differently ie, for statements can act more like C for statements then their bash versions. Still, tinkering with your shell nulls all warranties, in a sense anyway. Bash has a huge install base and is most likely the shell you will find on most linux systems. If you are really interested in supporting it, you will most likely have to code around its problems. ie, doing a revision check and using X function instead of Y.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Debian kernels are now compiled with initrd support. They use ash for their kernel boot scripts. I'm guessing this is because of it's size.
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.
You have to use /bin/sh and test on all platforms. There isn't anything else you can rely rely on finding on all distributions. Yes, there are probably slight differences between what purports to be /bin/sh on various platforms, but I can't imagine it will be very hard to write a script that runs fine under all of them---just avoid the dark corners.
Suggestions for other shells (ash or whatever) that might be better are pointless for your purposes because you can't rely on them being there.
I know from experience that (some?) 1.x Bash versions have a bug in the getopt builtin. The bug seems to be fixed in 2.x versions (not sure what version fixed it). There is a workaround for the bug, but it breaks portability of the script. The workaround also causes the script to break for fixed versions of Bash.
From what I can tell from the documentation and man page, ash is just BSD's /bin/sh. Do the BSDs use GNU Bash, assuming the admin wants Bash on the system at all?
No other OS puts bash under /bin.
Except for Solaris 2.7 and 2.8. Ahem.
News for Nerds. Stuff that Matters? Like hell.
...been to thinkgeek lately?
Use the source, Luke!
Use The Source, Luke!
except on the *NIX that is growing the fastest, Linux, KDE is still include as default in every major distrobution except for RedHat. It is also default in the second largest *NIX, FreeBSD.
Face it, gnome is dead. all of the gnome developers should switch to KDE or else their work will be at loss.
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
The one requirement you forgot was "and get it noticed by the media so that people will even know it exists". There are scores of Linux distributions, and more than a few were created with exactly these goals (SEUL for one), but you'll never hear about them on CNET.
Use Debian, they actually have a "delete/backspace policy" that covers this. Of course, all bets are off when you use said terminal to telnet to a non-Debian system - that's a problem you just can't solve without cooperation from vendors....
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
I even submitted a story about it, but it was rejected:
This sig under construction. Please check back later.
Ok guess its never going to get modded up because it has FreeBSD in it...
s ta ble/src/bin/sh/
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?
VANBO
bashing microsoft, I believe.
But bashing bash?
As a current tcsh user under OS X I feel the need to be Bourne again.
i wonder if there is a bashdot.org..I'll go look.
(j/k)
If it is not on fire, it is a software problem.
I apologize if my tone comes off confrontatively :-).
/bin/sh but use bash-specific features, I agree.
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...
Simple bash -- A phrase I'd never expect to hear!
On my system:
131072 sh
688128 bash
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
"would anyone out there be interested in writing a real Bourne Shell for Linux?"
First you will have to tell us what a "real" Bourne shell is. It's not as if there is a standard.
You might or might not like ash. It is much smaller than bash, but on the other hand it tries even harder than bash to be POSIX compliant.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I can understand the reason for this when writing an install script - specifically it is desirable to write to the lowest common denominator and thus make it compatible with everything.
However, I can't think of a single shell which actually implements just POSIX, or Bourne syntax for that matter. There are dozens of shells out there which all will chew on a real POSIX or Bourne script and spit out something which is pretty close to what the script author intended. However it seems that all of the shell authors have done stuff a little differently than each other so if you've only written and tested on one shell, you might have problems running on any one (or all) of the other shell(s).
The best thing to do is to pick something small which is as close to just POSIX implementation as you can get (ash perhaps?) and write/develop in that shell and then thouroughly test it on things like bash, ksh and other POSIX shells.
I always like to through out the fact that most systems now have perl available on them and in some cases it is probably just as appropriate if not more so to script install stuff in perl.
The problem is that "/bin/sh" SHOULD be the Bourne shell, or at least a 100% Bourne-compatible shell, on UNIX systems.
/bin/sh, some scripts written for Bourne shell (= /bin/sh) do not work, and that's a big problem.
/bin/bash (or /usr/bin/bash, or whatever) is bash. Asking vendors to replace /bin/sh with bash is not reasonable since bash isn't fully compatible with the Bourne shell. Asking them to include bash and install it as /usr/bin/bash however, is quite reasonable.
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,
I have encountered errors with the built-in test with -e tests, eg::
[ -e file.foo ] && something
The problem is really hard to reproduce. It has occurred on both the bash delivered with Solaris 8 and HPUX 11i, but not under Linux. Strange.
Has anyone else seen this?
I personally don't like bash. For one thing, I don't like its syntax. Well, actually, that's pretty much the only thing. I like csh a lot better because it's easier to configure, easier to use, and has a syntax that I like a lot better. (Hey, I figure UNIX is programmed in C; why shouldn't it be used in C as well (or at least in something C-like).) It's too bad csh wasn't the de-facto standard for UNIX systems, instead of sh. OH WELL.
Bash 1.0 was released Jun, 1989.
Do the math. You are wrong, sir.
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMM
I've run into this problem in the past as well. My solution was to abandon Bourne shell as a scripting shell and use ksh instead. To be 100% portable, you should use Bourne, but most of your major *NIXes have support for ksh (including linux, Solaris and AIX..not sure about HP-UX) and it has a lot of nice scripting gizmos like associative arrays, printf command, co-processes, pattern matching, etc. Of course, maybe you don't need all of that stuff.
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 is a good resource that might help as well as GNU Autotools documentation, 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
"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"
/bin/sh and not have anything break. For my own scripts (some of which have run to 1000 lines) I confine myself to sh features documented in my old copy of Kochan and Wood.
Debian policy requires that scripts that use bashisms (that is, non-POSIX features) use #!/bin/bash and not #!/bin/sh. The goal is to be able to link any POSIX shell to
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Bourne a shell, always a shell...
Ceci n'est pas une sig
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.
Funny, if I want to use bash I use #!/usr/local/bin/bash. Oh wait thats cause I use FreeBSD, a unix with a bourne shell.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Yeah, and put ONE and ONLY ONE manager for email and ONLY ONE for news and ONLY ONE for irc and ONLY ONE for icq? If you are a guru and want choice, well, then go and download your alternative package from the net, but do not force newbies to choose between mutt and pine and whatever.
And put an expert system for running tksysv that doesn't fuck up the order in which daemons must be started up and shut down. And DEBUG that fucking apt-get thing, so one can update a system. And don't invent a buggy GRUB when LILO is working just fine.
I've tried almost every distro since Yggdrasil came along, and I believe in the good old school that says one must debug the fucking thing before putting more "improvements" and "features" in.
Do any of your target platforms not have ksh88? PDKSH is rock solid, and the few incompatibilities are insignificant and documented. I believe OpenBSD uses it as /bin/sh. I've been using it for years and highly recommend it.
/bin/sh could probably be ported to linux pretty easily. I believe it's derived from ash. I don't think it's perfectly compatible with Bourne's original, though.
Alternatively, the FreeBSD
for an installer, I'd say it wasn't crazy idea; and for a user's shell, of course it's nuts, but we're talking about an install script.
you can _always_ count on perl being there (right?). any unix not having at least perl5 is not a unix system, in modern terms.
personally, I prefer tcsh as my _user_ shell. and its a pretty complete version of the c-shell, but made more livable.
--
"It is now safe to switch off your computer."
Hello, what planet are you on? The csh looks nothing like C. The syntax is clumsy and inflexible. See Csh Programming Considered Harmful.
Not only that, but csh is actually older than the bourne shell!!! It was derived from 6th Edition Unix, the bourne shell was new in 7th Edition. Talk about being slow to catch up...
Seriously, there is very little (most would say none) incentive to use csh anymore. Even in its tcsh incarnation, it's almost completely been superceded by zsh. You should check it out for your own sanity.
Should you desire, you can even turn on the god-awful insane history mechanism that all those weird-ass csh users seem to have gotten ingrained with...
The Linux packaging system for each of the distribution(s) you are targetting. That means packaging each for Debian, RedHat, and possibly others.
The POSIX shell standard is much closer to ksh than to Bourne shell. If that's what you want, ash is pretty much what you described.
Problem is, ksh / POSIX sh is not the lowest common denominator - there are old systems out there that still only have Bourne. (Contemplate for a moment, if you will, the design decision of the autoconf author not to rely on the existence of shell functions! Even Bourne shell has had those since the mid-80s or so.) Most vendors don't seem to care about pre-POSIX shells any more, though.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Wow, do you mean with ash I could use a Pentium III 780 instead of 866? Let's face it, given Moore's law, any speed improvement less than n vs. n^2 is more or less irrelevant.
As for memory usage, bash is about 0.5 megabytes, any memory chip that small is obsolete, and very expensive. Better get 64 megs or more, compared to which both sh and bash are about zero size.
In the dependencies issue, I admit you are right. But so many other packages need those same libraries that it's very likely you'll need them anyhow.
All in all, I think this "sh or bash" thing will be an issue only in a very few restricted cases, mostly embedded systems.
Comment removed based on user account deletion
Your argument is roughly equivalent to the statement:
"I think prawns are quite attractive - KILL ALL CREATURES OF THE SEA!!!!!1!!1!!!!!!!!
... but it's always on core ...
"Video bona proboque; deteriora sequor." -- Ovid
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 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.
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
- Make usually calls
/bin/sh -c, returning us to our original problem.
- Here's the problem with CSH.
- Program gets written with a real CSH. (Or with CSH linked to TCSH.)
- End user uses the opposite, which has a different implementation of feature x, or flat-out doesn't have it.
- See step 1.
--j0shuaThe korn shell is supposed to be 'the' POSIX compliant shell and ships with all commercial unix systems. So if cross platform compatability is required, korn is the logical choice.
Why would anyone choose to write scripts in sh anyway, it's like writing using a chisel a stone. Ksh at least has 2D arrays, and some pretty decent builting functions for pattern matching.
a lot of slashdotters have pointed out this is a non-issue; as far as writing scripts goes, so long as you are "careful" you won't run into any problems.
right? i mean exactly how hard is it, knowing, loving, and using bash to click-off the parts of your programmer mind that deal with the bashism shortcuts you take for granted?
as a programmer, i frequently need a few steps to shift gears. i'll be working for four or five hours on some C, flip into a perl program and find myself (quite unconsciously) dropping some $char@act%ers*. they're deceptively similar languages in construct, and i must say "okay, now i'm writing perl" or java or bash or forth or whatever.
this is not to suggest that our friend in need is without hope; that even if he had a real bourne shell he would still make mistakes. this simply illustrates that it's more difficult to avoid those mistakes EVEN WITH the knowledge.
if you're a non-programmer, don't bother responding to me, because it's hopeless to think you'll understand... just because you can quote the linked faq doesn't mean you actually understand it.
the case of typing export out is such a silly one that I often make the same error: i have a rather large administration tool that runs on NT, 2000, Solaris, Linux, and OpenBSD. It's goal is to unify their various differences so that administration can remain (roughly) the same.
as such, it's a myriad of shell scripts, 300-400 line C programs, perl programs, wrappers, and whatnot. the MOST COMMON PROBLEM that I deal with is because I develop initially on a Linux system. Linux is extremely developer friendly (perhaps because it was developed for developers, but that's a hiyku waiting about that i'm not going to release today) - and solaris, NT, and 2000 are not (again, YOU can disagree; I know many hailstorm developers that love the new windows platform. you're still wrong.)
however. i did mention that there was hope, and to that i will now digress: your application (whatever it is) must SOMEHOW share some commonalities with the platforms in which you wish it to run.
if your application is a C program: write your installer in C. or better still? write makefiles. perl program? even easier: you have a shell (perl, well, sort of). if your program is a bash script (and i'll pity you if it is) you simply require the use of bash.
i make my administration tool work on many platforms by making those platforms more similar- that way the jump is shorter.
i also have the added benefit of being able to test my changes. they go from my development machine to a staging system (one of each flavor) and from there onto the production webs.
i can't very well suggest that you "avoid making mistakes", and if I suggest "ash" or "zsh" or "csh" i'm simply suggesting that you require something else. i'm not going to have any allusions about it, however: if it doesn't work, use something else ANYTHING else. even if that means you need to slap solaris on a machine (for bourne), or perhaps stealing the *bsd's shell.
you have more than your two (obvious) options- in extremeties and in directions. remember your goal first, and then find out what problems exist.
best of luck
Must be an Albany graduate. For some reason (at least when I was there), csh was your default shell. If you were lucky you got it changed to tcsh before they disabled ypchsh for "security reasons". Bash? Nobody used it. I remember setting up Linux for the first time back then, trying to figure out how the heck environment variables worked in Bash. I knew this was a goddam simple question, but nobody at school knew because everyone there had only seen C Shells. I also knew that asking a question like "How do I set environment variables in Bash" on the net would not get me the answer. But at the time, a file that said "FOO=bar ; export FOO" or "export FOO=bar" was not that easy to find. I don't know why they continued to use CSH scripts for everything even when it appears everyone else in the world uses bash.
Since HP-UX 11 came out I believe /bin/sh is the POSIX shell. Not really Bourne exactly.
And I think most of us are bright enough to test our code a bit on those platforms for which we are responsible. Whining about shell discrepancies is a bit lame. What happened to the news?
- Sig this!
Who uses Algol today? We now have much more elegant shells like "rc", either the "rc" clone that is shipped with most Linux systems, or maybe even the original Plan 9 "rc" designed and written by Tom Duff.
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.
Thanks
Bruce
Bruce Perens.
Real Bourne Shell will be released as source code sooner or later by Caldera. Here is the press release:
http://news.linuxprogramming.com/news_story.php3?l tsn=2001-08-20-003-06-CD
http://ir.caldera.com/ReleaseDetail.cfm?ReleaseID= 57417
And here are some quotes:
So, you must keep you eyes on this:
http://unixtools.sourceforge.net/
Meanwhile you can do portable shell-scripting with help from these WWW-pages:
http://www.raycosoft.com/rayco/support/porting.htm l
http://www.raycosoft.com/rayco/support/SANS_2001_f iles/v3_document.htm
http://sources.redhat.com/autobook/
http://sources.redhat.com/autobook/autobook/autobo ok_208.html
Ash is really good Bourne Shell clone and POSIX-shell implementation. I really like to use it for my shell-scripting, because it prevents me from using bashisms. In my Debian GNU/Linux 2.2 Potato /bin/sh is actually a symlink to
ash that I compiled from sources I took from unstable Debian and it works.
But if /bin/sh is symlink to bash and you have some bashisms in you script that
starts "#!/bin/sh", it seems, that even in that case bash won't complain
about those bashisms.
But you must check out, which version of ash you are running. Debian has always used the latest version of ash. I think it is downloaded from this place:
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src /bin/sh/
Red Hat Linux had ash version 0.2 and it really sucks. Then I made bugreports and latest versions of Red Hat have fresher version of ash.
But it seems, that Slackware still has that ash version 0.2:
ncftp ...ware-8.0/source/ap/ash > pwdc kware-8.0/source/ap/ash/ ...ware-8.0/source/ap/ash > ls ...ware-8.0/source/ap/ash >
ftp://ftp.slackware.com/pub/mirrors/slackware/sla
ncftp
ash-linux-0.2.diff.gz _ash.tar.gz
ash-linux-0.2.tar.gz SlackBuild
ncftp
BTW I really don't understand, why somebody would want to create installer scripts, when this kind of tool exists: http://www.easysw.com/epm/
Juhapekka "naula" Tolvanen - http://iki.fi/juhtolv
The IEEE Standard 1003©2 ¥``POSIX©2'' specification for the shell©
Best Slashdot comment ever
This is somewhat OT but I think it is a valid point. How bout...a better shell to replace sh on those "enterprise" *nixen. I have not quite figured out why the "big guys" have not grown up a bit and started using more robust shells like bash and/or ksh. Frankly, I'm a korn shell guy when it comes to scripting jobs which is what I do for a living (ksh and Perl). Solaris ships with ksh88 out of the box. Solaris 8 might actually come with ksh93 now (NOT including dtksh which is a superset of ksh93 with dt code built-in) but I could be mistaken about that. However, Solaris still bumps into borne if one needs to go into maintenance mode. Now, I am not a hard-core Unix code hacker and I don't proclaim to know everything about Unix, but I have my fair amount of knowledge. No doubt, the first reply to this will be: It can't be done because of compatibility issues. BAH! I really do not think it would be that difficult to build and use the more up-to-date shells into the vanilla installs for those enterprise type *nixen. Why would you change? I know bash finally added support for arrays not too long ago (a couple years now?). Korn does arrays, but borne, does not. Can borne do tertiary conditions? I don't know, never tried but I doubt it. Does borne allow all of the test switches that bash and korn can do? The ever-loved command-line recall is a good 'nuff reason to do away with borne. Borne is old and it's deprecated. Everything has to evolve sometime. I'm not leaving out csh and tcsh on accident. I just am not a cshell kind of guy but I know it is very powerful. FreeBSD uses it as the default root shell in a vanilla installation. I believe even FreeBSD falls back to borne in maintenance mode. I think, in the end, the biggest reason why those Unix companies don't "upgrade" to the more robust shells is compatibility. Perhaps the second biggest reason is, "why? It works!". I agree, it works and if that were the only reason, I admit, that is a worthy reason. However, I feel its time to move on!! Things don't get better if they remain in the old ages.
- J
Well, at least he did, back in the day when bash had not really matured and gained market share and no other shell had the useability features tcsh had (tab completion, up/down arrow editing, etc). I wouldn't bet any money that he still does (although I wouldn't bet against it either - who knows, he might).
But bash now has almost all the features people (including me!) liked so much about tcsh, and zsh of course has all those and much much more. So there's no good reason anymore not to switch - well, there are reasons (availability on all machines that you use, availability of people to help you who are knowledgeable in bash/zsh, difficulty of the transition, etc) but the days of tcsh being "easiest to use" are long gone.
Besides, we can't all be the great tchrist - I imagine he has no trouble keeping syntaxes of esoteric features of different shells in his head and not confusing them, but I find it much easier to use the same shell syntax interactively as I use for scripting. That's the biggest reason I switched to bash, lo these many years ago. (Since then I've found many other reasons not to regret the migration.)
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
AFAIK bash is GNU so vendors may have license problems including it. I think this is why Apple is not including bash in Mac OS X.
Granted, not really Linux-related answer, however it does answer the question. Also, note last para of the question -- this is not about interactivityportability.
--AP
Actually, is writing korn or bourne shells the way to go?
We're year 2001. ZSH, Bash and Tcsh are there for years, and they work on all platforms out there, including Windows. They provide a lot of enhancements over Ksh and sh (kick-ass completion, readline, floating point arithmetic, a lot of handy shortcuts and builtins, etc) .
So, the way to go is probably to use nowaday's tools, not 20-years old ones.
{{.sig}}
Nowadays, if you install the ash Debian package, it asks you if you want to use it for /bin/sh.
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?
Perhaps, if you use apt and only apt, then it will work. In my case, I have tried "upgrading" a system where some of the packages where more up-to-date than the apt package in the FTP server (I had already compiled newer versions from source). Disaster.
The only way to test if your scripts will work on different Unices is: Test them on different Unices. You have only Linux? Too bad, if you really earn your money with that work, buy some other machines. That's professional life, deal with it.
The situation has been spelled out best by Larry Wall in an old Usenet posting:
Since, your problem is: There ain't no such thing as a standard Bourne shell. The real original Bourne shell was a beast - believe me, I've had access to the source. The C code was turned to some pseudo-Algol by way of macros (e.g., #define THEN ) { etc.) Most Unix vendors replaced it by an own implementation sooner or later.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
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.
Does this sound familar:
/bin/sh gets a defect call from me. There is no reason on earth not to ship and use more robust tools if your install truely is that complicated.
"Why isn't $NEW_SW available?"
"Because the install script crapped all over itself, and I'm trying to figure out what it's doing."
"Didn't you call support?"
"Yeah, but apparently our latest set of OS patches is not something they tested with."
"Did you get an ETA on the fix?"
"A couple of weeks, maybe more."
"But we need it now!"
"I know. That's why I've been here the last two days going over 120k of poorly written, documented and tested install script!"
Any vendor shipping an install that requires more than a few lines of
Ugh. I do NOT want to target a package to some linux distribution. I want to target a package to linux in general. I don't want to care about all those distribution. My package will most likely work on all of them (hopefully).
So this means that I cannot simply do what you want and take the 'linux packaging solution' because linux does not have a standard packaging solution. All distributions have some but not linux itself. But the packaging systems from the distributions are useless as I don't want to target a distribution.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
> Last I checked, OpenBSD was using pdksh
/bin/sh in 4.4BSD-Lite, FreeBSD and NetBSD.
Yeah, it appears so. Ash is
OpenBSD removed Ash around four years ago, according to their CVS.
Sorry you got modded down for being right. If I had real points I give you one, but at present the only mod points I have are the these fake ones I mint for my own private mod system.
-- MarkusQ
Have you ever heard of shared-copy-on-write executables?
Have you heard of U.S. Patent 4,742,450 on the shared-copy-on-write memory segments that loading such executables requires?
Will I retire or break 10K?
All in all, I think this "sh or bash" thing will be an issue only in a very few restricted cases, mostly embedded systems.
By dismissing embedded systems as a "few restricted cases," you misunderestimate their ubiquity and importance. Go to Worst Buy or Shircuit Shitty and look at the PC section vs. the sections that have TiVo, WebTV, GameCube, etc. Do you see more PCs on the shelf, or more embedded devices on the shelf? For instance, TiVo runs a Linux kernel, and Dreamcast and PS2 also have Linux available. (Sony will soon bring PS2 Linux Kit to the U.S.) Now would you rather run bash (Bloated A$$ SHell), or would you rather run something smaller and be able to add more features on a given set of fixed hardware such as a game console or a poor student's PC?
Will I retire or break 10K?
This actually works pretty well, and it's great for finding broken sh scripts.
From the zsh manual:
"Zsh tries to emulate `sh' or `ksh' when it is invoked as `sh' or `ksh' respectively."
I don't know how strict the sh emulation mode is.
I use ash, because it is /bin/sh on FreeBSD which is what I use mostly. I believe it is fairly conservative (that is, doesn't implement much more than a minimal bourne shell). I know the POSIX spec' fairly well. I never have any problems writing incompatible scripts (by, for example, accidentally using features that some other shell doesn't implement). I very occasionally find myself thinking that the bash/POSIX ksh syntax for arithmetic expressions would be nice (usually around the same time that I think I ought to rewrite the script in awk/python/c).
Of course, because I mostly only use FreeBSD I don't get to test my scripts on other shells very often... (HP-UX, OSF, and Ultrix used to be good platforms for finding quirky shells).
The shell I use most often is rc (from plan 9), but I don't do "real" programming in that because no other system has it installed (certainly not by default). Having a fairly even mixture of programming sh and programming rc is a good way to mess up your mind.
This comment has been scanned for viruses.
The only problem I ever ran into was that a lot of people seem to shebang #!/bin/sh on Linux systems, when in fact they're using Bash symantics. This confuses scripts trying to run on systems with a real bourne shell (e.g. Solaris). I don't mind that Linux doesn't have a proper Bourne shell, I just wish coders would properly acknowledge #!/bin/bash.
Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...
I've written quite a bit of
You either misunderstand or misremembered the explanation. No scripts break when root's shell is changed.
You shouldn't change root's shell because you shouldn't be using the root acount often enough for it to matter. If you use su to become root, use the -m flag so it keeps your existing shell and environment. That's what it's there for. Or, install sudo and use 'sudo bash' to become root. On all my servers I haven't 'logged in' as root in at least 6 months. Linux users use the root account far too often and then carry their bad habit to other OSes when they switch.
The other danger is not being able to use dynamically compiled shells in single user mode. You mentioned this.
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
Have you ever actually read the GPL?
The modern thing is simply the POSIX shell command language; If you write in the POSIX language, avoiding the quirks and extensions in the proprietary implementation you are using, your script should be highly portable to GNU bash and vice versa.
Similarly, if you want to write a new shell, your best bet is to use the standard as the guide rather than to clone the behavior of the legacy Bourne shell.
If you don't know what is standard and what is not, try the draft Single Unix Specification online.
Search for ``shell command language''.
A linux packaging system, eh? This is make, make install? Or do you mean something like rpm? Or deb?
Look ma, I'm a
Hi:
I do exactly the same thing - one shell script has to install my company's product on Linux, Solaris, AIX, and HP-UX. I develop the scripts on Linux, and I've been bitten in the ass by accidentally using a Bash-only extension. I have found this book to be very helpful:
Blinn, Bruce, _Portable Shell Programming_
ISBN 0-13-451494-7
-Ghengis
Okay, I may be deviant here, but I don't think
swearing at a troll in an effort to get a message
through his stone head is in itself a troll.
-I like my women like I like my tea: green-
The provided example for pointing out the problems with bash was just a really bad pick.
You are not required to use teh shorthand initialization of a variable at export. It is a shotcut and that is all. It is not necessary to use that shortcut. So, while yes it does not behave exclusively like bourne, it is a frivilous point.
I would have liked to have seen some better examples.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra