Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sat, Sep 08, 2012 at 07:10:58AM -0400, Dan Ritter wrote: > On Fri, Sep 07, 2012 at 06:18:25PM -0500, Derek Martin wrote: > > rare these days that Unix systems ship with /bin/sh = the original > > Bourne shell. So, set their shell to /bin/sh, and make sure that is > > bash on your linux systems, and everything should be hunky-dory. I > > know debian uses dash by default now, but in almost 20 years of > > managing Linux systems, I've always used bash as the system shell, > > even on production servers, and it's never caused a problem. Though, > > if the RC scripts are specifically written with dashisms, that could > > be problematic. This is one of the many reasons I don't like debian. > > If your system is hosed, you're probably going to boot from a rescue > > disk anyway... > > Debian changed to dash in large part to make sure that there > weren't bashisms in the RC scripts. (There were. They got > fixed.) The other reasons were to reduce required dependencies > and decrease boot times. Yeah I recall running into such bugs, though I thought when I read the bug reports the performance was the motivation, and the incompatibilities was just an unwanted and not entirely expected side effect... But regardless, there are other minor incompatibilities... I don't recall many of them specifically since I tend to avoid debian systems, but I recall that the behavior of the built-in echo command is different. I can't say what the state is today, but mentioned it as a possible caveat. > Having bash as the system shell rarely causes problems. Having > scripts that need bash but don't declare it explicitly is the > problem. Having scripts that invoke it as /bin/bash can also be a problem. One subtle but potentially important difference is that having /bin/bash in your #! line causes bash to read your shell startup files, whereas when invoked as /bin/sh it does not. Depending on how you have your environment set up, this can lead to a fork bomb. Particularly, if your environment files run scripts, each new invocation will start a new copy of bash, which will read your rc files, etc... I just tested this on my Fedora install, and it still happens, though various system process limits (i.e. ulimit) prevent it from killing my system. I ran into this with Debian Sid, which originally shipped with the which command being a shell script which was invoked as /bin/bash, and which I use in my .profile to figure out which of certain commands are on the system. When I logged in after doing that upgrade, my machine fork bombed. Several years later, when I started working at my current employer, I took down two of our production servers exactly the same way: they were still using the original Debian Sid. I've always preferred to stick to Bourne syntax for compatibility reasons anyway (I formerly admined Linux, HP-UX 9.x, 10.x, SunOS and Solaris all simultaneously and used the same login files and shell scripts everywhere), but this series of events guaranteed that I would always invoke my shell scripts as /bin/sh and avoid bashisms. You do still get most of bash's syntax anyway IIRC. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |