[systemd-devel] What is wrong with Bash? [Was: Re: [ANNOUNCE] Journal File Format Documentation]

[Ciprian Dorin Craciun]

    (Ok. I've just opened another can of works... :) Thus I've changed
the subject, not to pollute the journal thread with this issue.) :)


On Tue, Oct 23, 2012 at 10:22 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 23.10.12 22:14, Ciprian Dorin Craciun (ciprian.craciun at gmail.com) wrote:
>>     Ok. Just to state my bias: I'm currently neutral in the SysV / BSD
>> init vs systemd. I **really** do want to get rid of all the Bash-ism
>> initializing my system (actually I would ban Bash from newer
>> projects). But this is a totally different topic which has been
>> discussed on almost all the mailing lists related to Linux that I'm
>> subscribed to...
>
> I am sorry I have to ask, but what's wrong with bash? I mean, it's a
> shell, but what is worse or better than any other shell about it? What's
> the benefit of dealing with multiple implementations of a shell? Do you
> want to waste memory, increase your test matrix, complicate the use,
> yadda, yadda?
>
> I really, really don't buy in this Debian ideology of "bash is bad, but
> dash is awesome", that's just intense BS.


    Well there's nothing wrong with Bash. I use it extensively in my
projects. Just to give some context: I think I've tried almost every
"sh"-flavoured implementation out there: from `ash` (busybox) to
`dash`, even Plan9's `rc`, then going through Scheme's `scsh`.

    Then why would I ban it from projects: because developers (me
included half of the times) aren't able to write correct Bash scripts
that won't blow in thousands of different "subtle" ways when dealing
with corner cases. Just to give a few hints about what makes me made
in Bash:
    * variable expansion quoting: people always forget to put the $x
in the damn double quotes, thus god forbid a space finds it's way in
there...
    * error handling is "optional" and having reliable error checking
is still an unknown for me; (yes I know about `set -E -e -u -o
pipefail ...` but that has such subtle issues with subshels, and other
features that I still don't know all the rules;)
    * it is almost impossible to write non-trivial reusable libraries;
(I've tried it and it's the most horrible piece of code I have ever
written...);
    * handling signals is a pain...
    * handling and controlling multiple processes is a joke... (just
`&` doesn't scale, and I know of `coproc`, only one at a time is
supported);
    (I could keep like this for hours...)

    Thus to conclude: I would love a UNIX process assembly language.
But Bash (or any other `sh` replacement, except maybe `scsh`) is not
that one...

    Ciprian.

    P.S.: Writing everything in C is not an option due to the low productivity.
    Maybe Go is the answer... (But I can't find their process
composition library... Because there is none...) :)