Re: [gentoo-dev] Network configuration and bash

[Kevin F. Quinn]

On Tue, 6 Feb 2007 23:26:32 +0000
Roy Marples <uberlord@g.o> wrote:

> On Tue, 6 Feb 2007 21:28:04 +0000
> Ciaran McCreesh <ciaranm@×××××××.org> wrote:
>
> > I think it's more that you're expected to justify *why* the bash
> > requirement is so bad, given the cost of changing.
>
> 1) Lack of choice.
> Gentoo is all about giving the user choice. baselayout even supports
> other init systems when requested.

Surely you would provide choice by providing different baselayout
packages; one tailored for embedded systems that only have busybox, one
for general purpose use, etc.  That's what the virtual is for, isn't it?

> 2) Speed.
> Bash is one of the slowest shells around for looping.
> However, it also requires less forking due to it's nice built-ins.
> This does of course only work with bash and not other shells.

Restricting everything to 'sh' I think is more likely to slow things
down than anything else.  Apart from the forking issue that you
mention, builtins are different - '[' for example is about 30% slower
than '[[' in bash (which is what's implementing sh on Gentoo Linux).  I
wonder how much time would be saved on Gentoo Linux by replacing [ with
[[ throughout the init scripts; maybe a percentage point?

If there really is a big speed penalty from using bash on BSD compared
to the native shell, wouldn't it be better to supply a Gentoo/FreeBSD
baselayout?  They don't have to be completely independent; smart use of
the vcs would allow you to share scripts between baselayout branches,
with specific variants where it makes a difference.

> 3) What's the cost of *not* changing away from bash?
> I would say that bash is the best shell around in terms of features
> and ease of use, however that is not without cost. That cost is new
> bash versions consistently breaking baselayout, ebuilds and configure
> files.

w.r.t new bash versions, we should certainly be conservative in marking
new versions stable.  It's worth noting the breakage isn't always
100% the fault of bash. The recent problem with '=~' and quoting for
example is down to glibc behaving differently to everyone else's libc
when it comes to accepting quoted characters for the regex interfaces
(a point where the POSIX standard is open to interpretation).

> 4) Size.
> Because bash has all these nice features it's large, hence unsuitable
> for low memory or low disk space environments.

But you only get one bash text image in memory at any one time (~825k).
So space isn't a real issue, except on small-memory systems.

> 5) I'm *just* talking about config files here.
> If users want to run bash, that's fine and I won't stop them. They can
> also use bash in their init script if they so wish as I plan to
> support something like so
>
> depend() {
>    shell bash
> }

Making that sort of requirement explicit is a good idea.  I wouldn't use
'depend()', as in init scripts it's quite cleanly only to do with the
order of services.  You could make it an option to runscript:

#!/bin/runscript --shell=/bin/bash

or something along those lines - the shebang is clearly all about how
the script is executed, and the shell used falls nicely into that.

> And voila, problem solved. Of course, that's just an idea I just had.
> However, I also think that baselayout provided services should not
> require bash for the above reasons, hence the need for a new config.

I think the argument for conf.d files is better than that for init.d
scripts; you could have multiple baselayout setups that share conf.d
file formats.

-- 
Kevin F. Quinn