It makes their job so much easier to know that 80% of the people out there are using the same algorithm.
Security by obscurity may or may not be effective - depends on who is trying to read your mail and how much time/money/effort they want to spend. In general I'm glad not to have to rely on it. Picking a weak but obscure crypto algorithm is a bad idea. (No pun intended, IDEA is neither weak nor obscure.)
RSA has stood the test of time - it has probably been through more hours of cryptanalysis by qualified professionals than almost any other algorithm, and nobody has found a serious flaw in it yet. Could it be cracked tomorrow? ("Cracked" in the practical rather than the academic sense.) Yes, but I'd bet serious money against it.
Now... if 80% of the world used the same program to produce their RSA-encrypted e-mail, that's when it's time to worry. Because I have a lot less confidence in an individual program being bug-free than I do in RSA itself being secure. That's where the famous software monoculture (i.e. "everyone runs Microsoft Outlook in 1999, ergo Melissa", or "everyone runs Sendmail in 1988, ergo Morris worm") problem lies.
It won't be really wireless until the power supply is also wireless;-)
Waldo, by Heinlein. I read it a long time ago, thought it was really good. They used some sort of EM and the power company had a monopoly on power receivers, which would meter what you used. Occasionally the receivers would stop working for no detectible mechanical reason, thus bringing in the metaphysical part of the plot.
That has always seemed like a pretty cool idea to me.
Oh, good thing it's the video encryption stuff. When I read the headline I thought it would be insecure to get an IP address with DHCP, and that had me worried.
Ummmm, unless this is a joke (sometimes I'm dense about that), I should point out that DHCP has no security provisions at all. Both client and server have nothing to identify each other with other than name and MAC address, both easily forged.
From the DHCP server's perspective, you can't keep the clients from claiming any IP they want, so there's not much sense in trying. (Use smart switches or IPSec layers or the once-considered-secure 802.11b for partial protection there.)
From the client's perspective, you either trust what the server tells you (and yes this can have security implications - if someone can give you a fake DNS server you are open for man-in-the-middle attacks) or you hard-wire everything in.
I believe... that cryptography as we know it is obsolete.
Do you have anything to support this assertion, or only anecdotal evidence of specific crypto systems being cracked? If the latter, do you know for sure whether they were cracked because of (a) inherent weakness in assumptions upon which all cryptography is based, (b) weaknesses in the specific algorithms used, (c) weaknesses in the software architecture surrounding the encryption, or (d) bugs in the implementation? I think you'll find that most "cracks" are either (c) or (d).
Encryption and cryptography as it stands at this moment is a joke, just pool together enough resources, and even 128 bit keys can be cracked and unlocked
So what about my 1024-bit RSA private key?
BTW, "even 128 bit keys" is an empty statement. Number of bits is to key strength as megahertz is to computer speed. You can't compare different crypto algorithms, or different models of CPU, with such numbers alone.
Windows seems to handle this 'problem' without incident.
Probably by not locking the drive door, and throwing exceptions (think "signals") to any applications that try to read from the CD.
Actually, CD-ROMs are a poor example here, because they are read-only, so think about Zip disks, floppies, or DirectCDs. If you eject one at the wrong time under Windows, as under Unix, you will get filesystem corruption.
Windows seems to try and minimise this effect by disabling write caching to removable media. Certainly, some people would see this as an acceptible tradeoff - even Linus Torvalds has been known to advocate the position that "the floppy light should never go off while there is still cached write data".
However, architecture gets in the way. Windows comes from MS-DOS which was almost stateless -- not much caching anywhere, look for a drive where you think "A:" should be, and if it's there you can use it. Unix has more of a high-availability heritage; thus the concept of formally mounting a filesystem rather than just seeing what's happens to be in the drive right now.
If you really want a Windows-esque way to handle floppies (and other removables) there are two approaches: (a) use a user-space filesystem layer that uses block devices to emulate / replace the kernel-level filesystem. This is done by the mtools package, and (I think) by "desktop projects" that feel users will be uncomfortable with mounting - cf. KIO and the GNOME VFS. (b) Use supermount, a Linux kernel patch implementing a filesystem shim layer, written back in the 2.0 days and since ported reluctantly to 2.2 and 2.4. Supermount works by being absurdly forgiving in the face of users ejecting and inserting things without permission, while still retaining an element of at least read caching. Read the patch sometime (or just the design notes) to see how awkward this was to accomplish.
In short, a snapshot is approximately equal to an image of a filesystem. To create a snapshot, you run a mount command like "-u -o snapshot/var/snapshots/snap1/var". Becase of the way snapshots work, the snapshot must reside in the same filesystem that it contains.
Linux has snapshots too, but only if your filesystem is in a logical volume managed by LVM. An LVM tool calls the kernel LVM driver, which tells the filesystem in question to "quiesce itself" (i.e. make itself consistent on disk) if possible (only ext3 and reiserfs support this operation at the moment), then it creates a new snapshot logical volume, which is of course COW (as are, I assume, FreeBSD snapshots), and finally the filesystem is given permission to continue operations.
Unlike the FreeBSD snapshot facility (as you describe it, anyway) the new logical volume is read-only - you can't fsck it etc.
This is extremely powerful used in the hands of a good sysadmin.
Indeed, I've been thinking of using Linux snapshots more or less the way you describe. (Our shop is small enough that it's hardly worth doing daily backups, but if it's easy enough....)
even Tom "csh Considered Harmful" Christiansen uses tcsh interactivly. Just don't use it for scripting.
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.)
His point is that if Linux had a real Bourne Shell, he's wouldn't have to give two shits about what distro/version/patchlevel was installed as it related to his install scripts.
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.)
If tcsh had functions and stdout and stderr separation (redirecting stdout to one file and stderr to another), I probably would have continued to use it.
Some people use tcsh interactively but program with sh/ksh/bash/etc. I somewhat understand this mentality, but it's not for me. Because to me, there is not always a clear line between "interactive use" and "programming".
Have you ever typed, on a single command line, a mini-script to tar up every directory larger than xxx kilobytes, not counting *.o files (so you can't just use du), naming them../{dirname}.tar? Have you ever written an "alarm clock" on a single command line that clears the screen, then prints out hours:minutes:seconds on a fixed line, counting down to when it will start beeping at you by looping through echo ^G and sleep 1, but meanwhile letting you get a nap?
Heck, maybe it's just me. But when I need to do stuff like that, I would consider it a hassle to fire up an editor, write a script, save it, chmod it +x, run it, and delete it again. I would also consider it a hassle to make it run to multiple lines on my command line, because command line editing gets so much harder. No, the 600-char single line is the way I get certain things done.
csh would make my life a lot more difficult in this regard, because you can't do arbitrary conditionals and loops on a single line. I agree with your shell functions and redirection woes, but this limitation is another reason I avoid csh/tcsh interactively as well as for scripts.
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.
Well, bully for you and your Pentium III. I do development work on a PII-400. It's faster than my Pentium-MMX-166, you see. When I have to re-run a 'configure' file, which sometimes occurs every five or ten minutes (depending on what I'm working on, of course), it takes 60 seconds or so. With bash, it takes 65-70 seconds. To me, ash represents a tangible improvement.
If you think I should just get out of the dark ages already and get that dual Athlon I've been wanting, please reply so we can make arrangements for where and how you can ship it to me.
Only if you want to output the same text to two or more files, at the same time.
What if you want to have four output files from the same script, and output various things to each file? There are two ways to do this. The first is to use ">>file1" at the end of each command that outputs to the first file, ">>file2" at the end of each line that outputs to the second file, etc. This is cumbersome, and generates a lot of extra file open/close calls.
"So it's inefficient, who cares?" Well, it's also incorrect. It breaks when writing to a named pipe, for instance, because the reader of a pipe can get EOF on reading if you don't leave the pipe open the whole time.
More importantly, this method doesn't work so well when getting line-by-line input from a file. If you use '<file1' on a command, it will redirect input from the beginning of 'file1' every time. There is only one input file (stdin) that stays open between command blocks, and the shell programmer has no control over what file that is.
The second way is to open each file the way you would in a real programming language. In Bourne shell, that is the 'exec' command, as in 'exec 4>some_file', which opens descriptor 4 for output to 'some_file'. To close descriptor 4, use 'exec 4>&-'. Then to write to it, use 'some_cmd >&4'.
Input works the same way except with '<' in place of '>'.
In csh, none of this is possible - you have to explicitly redirect each command to or from your input or output.
If they're text files, I usually cat them and pipe them into the program over STDIN.
Try writing a mail filter that takes a mail message on stdin and reads a configuration file to decide what to do. In csh, this is at best really awkward. Your 'cat' solution won't work here. Once I managed it by actually saving stdin (the message) to a temp file, then re-execing my filter with a magic command line argument that meant "look, the message is in xxx file, stdin is your config file" and acted accordingly. It worked, but I'm not proud of it!
(Technically, I did the above in Bourne shell, but I was thinking like a csh user because I didn't know Bourne shell well enough at the time to know about redirecting with 'exec'. This was, perhaps needless to say, many years ago.)
In bash you cannot do this:
test -d "$dir" || ( echo "$dir doesn't exists"; exit 1)
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.
Thus, autoconf creates this kind of exit:
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.
One such distrobution is Red Hat 6.1. The bash that comes with that distro is version 1.14.7
There's your problem, then - unless Red Hat 6.1 comes with ash or pdksh installed standard, I guess the answer to your original question is either "no, sorry, you'll just have to work around the bash bugs" or "better tell your customers to install ash or pdksh or bash-2.x" or "Red Hat 6.1 is too buggy to support".
When you asked for "a real Bourne Shell for Linux", what you really wanted was "every Linux distribution shipping a reasonably bug-free shell as/bin/sh". This is a vendor QA issue, so what can one say? Bash 2.x seems to fit the bill, in any case, so your compatibility problems may go away in time.
Yes, any script that sets variables inside a compound pipeline and expects them to either (a) persist outside the pipeline or (b) not persist will be non-portable.
Any time you set a variable within a pipeline, use () around the pipeline; then the behavior is well-defined - variables will never persist outside the pipeline.
Does your profile get sourced?
It shouldn't. The subshell is not a newly executed copy of/bin/sh, after all, just a fork().
Unfortunately, while/bin/sh is pretty much a standard location, you can't rely on Perl being/usr/bin/perl, or/usr/sbin/perl (!), or/bin/perl, or/usr/contrib/bin/perl, or/usr/freeware/bin/perl (I've seen all of these in various Unix vendor installs) or/usr/local/bin/perl. You have to find it at runtime, which means you still need a shell script to invoke your perl script. Which is awkward - you need two files, or a here document which is even worse.
And no, they do not all come with Perl 5. HP-UX 11.00 still has Perl 4.0.36, in this day and age! I think Digital Unix had Perl 4 as well (I don't know when or if Tru64 switched), and I believe IRIX only switched to Perl 5 a couple years ago. AIX did not come with Perl at all until either 4.3.2 or 4.3.3 (the latest is 4.3.4, not counting 5L).
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.
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 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.
Obviously what the author wants is a shell which implements just the POSIX standard and nothing else.
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.
I know from experience that (some?) 1.x Bash versions have a bug in the getopt builtin.
That's unfortunate. I haven't used bash 1.x for a very long time, so I can't confirm or deny, but I think the reasonable thing to do is tell your customers you don't support bash 1.x as/bin/sh.
There is another bash bug (or at least difference with bash 2.x - I assume the bug is in 1.x) in its handling of $IFS. This one bit me last year. I submitted a patch for the Linux kernel which relied on a feature added by another user which hadn't been tested in bash 1.x (prior to my patch, the feature had never actually been used).... That's how I found out that Red Hat 6.0 apparently still shipped with bash 1.14, so we added a workaround that didn't use $IFS.
Is there any compelling reason (other than standards purity) not to just `rm sh; mv bash sh`?
size - bash is big, which is not an issue on disk, but I do care how much memory my cron scripts need.
efficiency - ash is noticeably faster than bash on my system. My "benchmark" is running a configure script generated by autoconf, after the settings have already been cached. (The first time you run configure, you'll be seeing 'gcc' efficiency more than anything else.) ash beats bash by something like 10%.
dependencies - bash needs readline (for command line handling) and libdl (for loading extensions), and readline needs curses, ncurses, termcap or equivalent. If any of the above libraries breaks (botched upgrade, etc) you're screwed. You could conceivably compile bash staticly so the dependencies are built in, but then your binary is even bigger - see point 1.
Er, wasn't the article about
sh compatibility? How did this ksh peculiarity creep in?
I know, I know. But in practice, this is sh compatibility, where/bin/sh is a link to ksh on AIX and to other POSIX shells on other Unices. As I've posted before, HP-UX doesn't even have a Bourne shell, to my knowledge.
Upshot is, vendors writing install scripts generally use ksh features, so this is relevant. I agree that bash seems to be 100% back-compatible with the original Bourne shell, or at least I'm unaware of any counterexamples.
the packages in testing now depend on initrd-tools, which in turn depend on ash.
They've always used an initrd for installing (so the kernel images have to be compiled to support initrd) - the difference is that now I believe Debian plans to use an initrd for regular hard disk booting as well. Hence the need for initrd-tools.
Red Hat and other distros already do this. The reason is that your root partition may be on a disk which is inaccessible without particular drivers for IDE or SCSI chipsets, and including all possible IDE and SCSI drivers in the one distributed kernel image is thought to be prohibitive. Debian compiles all SCSI drivers in anyway, whereas Red Hat builds an initrd to load the needed module(s) while booting.
Some distros take a third approach, and distribute several different kernel images to cover common SCSI drivers. Debian sort of does this too, with its Hedrick-IDE-drivers kernel image.
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.
Next best thing is to test with ash - I do this for exactly the reason you outlined in your post (great post btw). You still won't catch things like using $() instead of ``, of course, but most Unix vendors nowadays seem to have a POSIX/bin/sh anyway. I usually use `` anyway when I want the script to be portable, but $() is so much more readable... <sigh>
when it shows an example RIGHT IN THE STORY HEADER of how this isn't so (an incompatibility that I've run into myself, actually).
What example would that be? All I saw was a vague statement to the effect that "bash has had weird bugs in the past". Doubtless it is true, but what is one supposed to do about that? All programs have had weird bugs in the past - you just have to tell your customers that your install script may not work if they're still using really old versions of bash -- just like you tell them that your software no longer works on HP-UX 8 or 9.
To be clear, the syntax 'FOO=BAR; export FOO' works just fine on bash, so that can't be the
"example right in the story header" you mentioned.
Using ksh extensions to POSIX is just as bad as using bash extensions to POSIX - if a vendor script uses ksh-isms it may well work on all commercial Unices and not on Linux. But in that case I consider it the vendor's own problem.
Instead, why doesn't the article's poster come up with an example of a valid POSIX statement that breaks in bash
typeset -u varname
I don't know if it's strictly POSIX, but ksh supports this syntax for constraining a variable to auto-convert its contents to uppercase whenever you set it. This is the reason I can't use bash for my root shell in AIX - some poorly-written scripts don't have #! lines and rely on 'typeset -u'.
Slashdot Mirror
Security by obscurity may or may not be effective - depends on who is trying to read your mail and how much time/money/effort they want to spend. In general I'm glad not to have to rely on it. Picking a weak but obscure crypto algorithm is a bad idea. (No pun intended, IDEA is neither weak nor obscure.)
RSA has stood the test of time - it has probably been through more hours of cryptanalysis by qualified professionals than almost any other algorithm, and nobody has found a serious flaw in it yet. Could it be cracked tomorrow? ("Cracked" in the practical rather than the academic sense.) Yes, but I'd bet serious money against it.
Now ... if 80% of the world used the same program to produce their RSA-encrypted e-mail, that's when it's time to worry. Because I have a lot less confidence in an individual program being bug-free than I do in RSA itself being secure. That's where the famous software monoculture (i.e. "everyone runs Microsoft Outlook in 1999, ergo Melissa", or "everyone runs Sendmail in 1988, ergo Morris worm") problem lies.
Waldo, by Heinlein. I read it a long time ago, thought it was really good. They used some sort of EM and the power company had a monopoly on power receivers, which would meter what you used. Occasionally the receivers would stop working for no detectible mechanical reason, thus bringing in the metaphysical part of the plot.
That has always seemed like a pretty cool idea to me.
Ummmm, unless this is a joke (sometimes I'm dense about that), I should point out that DHCP has no security provisions at all. Both client and server have nothing to identify each other with other than name and MAC address, both easily forged.
From the DHCP server's perspective, you can't keep the clients from claiming any IP they want, so there's not much sense in trying. (Use smart switches or IPSec layers or the once-considered-secure 802.11b for partial protection there.)
From the client's perspective, you either trust what the server tells you (and yes this can have security implications - if someone can give you a fake DNS server you are open for man-in-the-middle attacks) or you hard-wire everything in.
Do you have anything to support this assertion, or only anecdotal evidence of specific crypto systems being cracked? If the latter, do you know for sure whether they were cracked because of (a) inherent weakness in assumptions upon which all cryptography is based, (b) weaknesses in the specific algorithms used, (c) weaknesses in the software architecture surrounding the encryption, or (d) bugs in the implementation? I think you'll find that most "cracks" are either (c) or (d).
So what about my 1024-bit RSA private key?
BTW, "even 128 bit keys" is an empty statement. Number of bits is to key strength as megahertz is to computer speed. You can't compare different crypto algorithms, or different models of CPU, with such numbers alone.
Probably by not locking the drive door, and throwing exceptions (think "signals") to any applications that try to read from the CD.
Actually, CD-ROMs are a poor example here, because they are read-only, so think about Zip disks, floppies, or DirectCDs. If you eject one at the wrong time under Windows, as under Unix, you will get filesystem corruption.
Windows seems to try and minimise this effect by disabling write caching to removable media. Certainly, some people would see this as an acceptible tradeoff - even Linus Torvalds has been known to advocate the position that "the floppy light should never go off while there is still cached write data".
However, architecture gets in the way. Windows comes from MS-DOS which was almost stateless -- not much caching anywhere, look for a drive where you think "A:" should be, and if it's there you can use it. Unix has more of a high-availability heritage; thus the concept of formally mounting a filesystem rather than just seeing what's happens to be in the drive right now.
If you really want a Windows-esque way to handle floppies (and other removables) there are two approaches: (a) use a user-space filesystem layer that uses block devices to emulate / replace the kernel-level filesystem. This is done by the mtools package, and (I think) by "desktop projects" that feel users will be uncomfortable with mounting - cf. KIO and the GNOME VFS. (b) Use supermount, a Linux kernel patch implementing a filesystem shim layer, written back in the 2.0 days and since ported reluctantly to 2.2 and 2.4. Supermount works by being absurdly forgiving in the face of users ejecting and inserting things without permission, while still retaining an element of at least read caching. Read the patch sometime (or just the design notes) to see how awkward this was to accomplish.
Linux has snapshots too, but only if your filesystem is in a logical volume managed by LVM. An LVM tool calls the kernel LVM driver, which tells the filesystem in question to "quiesce itself" (i.e. make itself consistent on disk) if possible (only ext3 and reiserfs support this operation at the moment), then it creates a new snapshot logical volume, which is of course COW (as are, I assume, FreeBSD snapshots), and finally the filesystem is given permission to continue operations.
Unlike the FreeBSD snapshot facility (as you describe it, anyway) the new logical volume is read-only - you can't fsck it etc.
Indeed, I've been thinking of using Linux snapshots more or less the way you describe. (Our shop is small enough that it's hardly worth doing daily backups, but if it's easy enough....)
Actually 2.4.15pre2 - big difference. So yes, it's in Linus's tree, just not in a "released" kernel yet. (Wait a few more days.)
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.)
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.)
Some people use tcsh interactively but program with sh/ksh/bash/etc. I somewhat understand this mentality, but it's not for me. Because to me, there is not always a clear line between "interactive use" and "programming".
Have you ever typed, on a single command line, a mini-script to tar up every directory larger than xxx kilobytes, not counting *.o files (so you can't just use du), naming them ../{dirname}.tar? Have you ever written an "alarm clock" on a single command line that clears the screen, then prints out hours:minutes:seconds on a fixed line, counting down to when it will start beeping at you by looping through echo ^G and sleep 1, but meanwhile letting you get a nap?
Heck, maybe it's just me. But when I need to do stuff like that, I would consider it a hassle to fire up an editor, write a script, save it, chmod it +x, run it, and delete it again. I would also consider it a hassle to make it run to multiple lines on my command line, because command line editing gets so much harder. No, the 600-char single line is the way I get certain things done.
csh would make my life a lot more difficult in this regard, because you can't do arbitrary conditionals and loops on a single line. I agree with your shell functions and redirection woes, but this limitation is another reason I avoid csh/tcsh interactively as well as for scripts.
Well, bully for you and your Pentium III. I do development work on a PII-400. It's faster than my Pentium-MMX-166, you see. When I have to re-run a 'configure' file, which sometimes occurs every five or ten minutes (depending on what I'm working on, of course), it takes 60 seconds or so. With bash, it takes 65-70 seconds. To me, ash represents a tangible improvement.
If you think I should just get out of the dark ages already and get that dual Athlon I've been wanting, please reply so we can make arrangements for where and how you can ship it to me.
Only if you want to output the same text to two or more files, at the same time.
What if you want to have four output files from the same script, and output various things to each file? There are two ways to do this. The first is to use ">>file1" at the end of each command that outputs to the first file, ">>file2" at the end of each line that outputs to the second file, etc. This is cumbersome, and generates a lot of extra file open/close calls.
"So it's inefficient, who cares?" Well, it's also incorrect. It breaks when writing to a named pipe, for instance, because the reader of a pipe can get EOF on reading if you don't leave the pipe open the whole time.
More importantly, this method doesn't work so well when getting line-by-line input from a file. If you use '<file1' on a command, it will redirect input from the beginning of 'file1' every time. There is only one input file (stdin) that stays open between command blocks, and the shell programmer has no control over what file that is.
The second way is to open each file the way you would in a real programming language. In Bourne shell, that is the 'exec' command, as in 'exec 4>some_file', which opens descriptor 4 for output to 'some_file'. To close descriptor 4, use 'exec 4>&-'. Then to write to it, use 'some_cmd >&4'.
Input works the same way except with '<' in place of '>'.
In csh, none of this is possible - you have to explicitly redirect each command to or from your input or output.
Try writing a mail filter that takes a mail message on stdin and reads a configuration file to decide what to do. In csh, this is at best really awkward. Your 'cat' solution won't work here. Once I managed it by actually saving stdin (the message) to a temp file, then re-execing my filter with a magic command line argument that meant "look, the message is in xxx file, stdin is your config file" and acted accordingly. It worked, but I'm not proud of it!
(Technically, I did the above in Bourne shell, but I was thinking like a csh user because I didn't know Bourne shell well enough at the time to know about redirecting with 'exec'. This was, perhaps needless to say, many years ago.)
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.
There's your problem, then - unless Red Hat 6.1 comes with ash or pdksh installed standard, I guess the answer to your original question is either "no, sorry, you'll just have to work around the bash bugs" or "better tell your customers to install ash or pdksh or bash-2.x" or "Red Hat 6.1 is too buggy to support".
When you asked for "a real Bourne Shell for Linux", what you really wanted was "every Linux distribution shipping a reasonably bug-free shell as /bin/sh". This is a vendor QA issue, so what can one say? Bash 2.x seems to fit the bill, in any case, so your compatibility problems may go away in time.
Yes, any script that sets variables inside a compound pipeline and expects them to either (a) persist outside the pipeline or (b) not persist will be non-portable.
Any time you set a variable within a pipeline, use () around the pipeline; then the behavior is well-defined - variables will never persist outside the pipeline.
It shouldn't. The subshell is not a newly executed copy of /bin/sh, after all, just a fork().
And no, they do not all come with Perl 5. HP-UX 11.00 still has Perl 4.0.36, in this day and age! I think Digital Unix had Perl 4 as well (I don't know when or if Tru64 switched), and I believe IRIX only switched to Perl 5 a couple years ago. AIX did not come with Perl at all until either 4.3.2 or 4.3.3 (the latest is 4.3.4, not counting 5L).
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 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.
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.
That's unfortunate. I haven't used bash 1.x for a very long time, so I can't confirm or deny, but I think the reasonable thing to do is tell your customers you don't support bash 1.x as /bin/sh.
There is another bash bug (or at least difference with bash 2.x - I assume the bug is in 1.x) in its handling of $IFS. This one bit me last year. I submitted a patch for the Linux kernel which relied on a feature added by another user which hadn't been tested in bash 1.x (prior to my patch, the feature had never actually been used).... That's how I found out that Red Hat 6.0 apparently still shipped with bash 1.14, so we added a workaround that didn't use $IFS.
I know, I know. But in practice, this is sh compatibility, where /bin/sh is a link to ksh on AIX and to other POSIX shells on other Unices. As I've posted before, HP-UX doesn't even have a Bourne shell, to my knowledge.
Upshot is, vendors writing install scripts generally use ksh features, so this is relevant. I agree that bash seems to be 100% back-compatible with the original Bourne shell, or at least I'm unaware of any counterexamples.
They've always used an initrd for installing (so the kernel images have to be compiled to support initrd) - the difference is that now I believe Debian plans to use an initrd for regular hard disk booting as well. Hence the need for initrd-tools.
Red Hat and other distros already do this. The reason is that your root partition may be on a disk which is inaccessible without particular drivers for IDE or SCSI chipsets, and including all possible IDE and SCSI drivers in the one distributed kernel image is thought to be prohibitive. Debian compiles all SCSI drivers in anyway, whereas Red Hat builds an initrd to load the needed module(s) while booting.
Some distros take a third approach, and distribute several different kernel images to cover common SCSI drivers. Debian sort of does this too, with its Hedrick-IDE-drivers kernel image.
Next best thing is to test with ash - I do this for exactly the reason you outlined in your post (great post btw). You still won't catch things like using $() instead of ``, of course, but most Unix vendors nowadays seem to have a POSIX /bin/sh anyway. I usually use `` anyway when I want the script to be portable, but $() is so much more readable ... <sigh>
-another Peter
What example would that be? All I saw was a vague statement to the effect that "bash has had weird bugs in the past". Doubtless it is true, but what is one supposed to do about that? All programs have had weird bugs in the past - you just have to tell your customers that your install script may not work if they're still using really old versions of bash -- just like you tell them that your software no longer works on HP-UX 8 or 9.
To be clear, the syntax 'FOO=BAR; export FOO' works just fine on bash, so that can't be the "example right in the story header" you mentioned.
Using ksh extensions to POSIX is just as bad as using bash extensions to POSIX - if a vendor script uses ksh-isms it may well work on all commercial Unices and not on Linux. But in that case I consider it the vendor's own problem.
typeset -u varname
I don't know if it's strictly POSIX, but ksh supports this syntax for constraining a variable to auto-convert its contents to uppercase whenever you set it. This is the reason I can't use bash for my root shell in AIX - some poorly-written scripts don't have #! lines and rely on 'typeset -u'.