Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] tcsh, AD, and RHEL 5.6



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org