[Discuss] tcsh, AD, and RHEL 5.6

Derek Martin invalid at pizzashack.org
Sat Sep 8 07:56:11 EDT 2012


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.



More information about the Discuss mailing list