[Toybox] making ./configure executable.

[Robert Thompson]

Yeah, I ran into some similar issues years ago...  In my case,  I got
burned into learning not to assume that bash (or any other shell) is
correct, or even necessarily *self* consistent(even on linux), so I
tend to reflexively do differential checks. It's a very small amount
of effort in the normal case, but months of project time and a major
missed deadline tend to leave a bit of a scar :)

there was a "posix, we swear" vendor /bin/sh, a classic /bin/bash, a
"new and sexy" /bin/bash, and the same version/same configuration
/bin/bash running on a different hardware/os...

We wasted months assuming that the newer bash was most likely correct
(it was a heisenbug, both rare and inconsistent). In that case, turned
out that the posix sh was technically correct and consistent, and
*all* of the bashes exhibited *different* incompatible heisenbugs. And
they tended to show up only about a day into a massive
un-checkpointable processing run...

that eval *still* smarts, and worse, it was supposedly-legacy crap
that we were just supposed to "update a bit" (it had always been doing
this, we were just the first people who noticed)...



On 2/5/18, Rob Landley <rob at landley.net> wrote:
> On 02/05/2018 04:01 PM, Robert Thompson wrote:
>> It seems that the single-equals is POSIX, while the double-equals is a
>> bash extension that at one point bash preferred and extended the match
>> behavior of.
>>
>> But, the bash manpage now documents double-equals  (when in the
>> context of the builtin test or its '[' alias) as equivalent to
>> single-equals.
>
> I researched all this crud at one point, but it was a few years ago now. :)
>
>> The manpage notes that when using test (rather than '['), one should
>> always use single-equals, due to POSIX compatibility issues, in case
>> the script gets run by a shell without a builtin test.
>>
>> Bash has another extended test, '[[', which does significantly
>> different, and expanded, things, but its behavior was inconsistent
>> across bash versions the last time it was relevant to my work.
>>
>> Apparently bash's interpretation of single-equals isn't always exactly
>> POSIX-standard, depending on which bash settings are in effect. A
>> quick skim shows that it may or may not be case-insensitive, may or
>> may not be glob-active (older version), *is* glob-active (newer
>> versions, with caveats?)...
>>
>> dash's behavior isn't saying "unknown operator '['". It's saying
>> "builtin-test-via-left-square-bracket: unknown operator '=='". I think
>> it's just phrasing it really poorly due to overly simplistic
>> backtracking in its parser (most recent symbol being assumed to be the
>> cause of the error, thus printed).
>
> Dash is crap. The switch to dash was because Ubuntu wanted to run its
> init scripts faster and thought changing all the init scripts to start
> with #!/bin/dash was too intrusive a change. No really:
>
>   https://wiki.ubuntu.com/DashAsBinSh
>
> This broke (among other things) the Linux kernel build. (Bash was the
> first program Linux ever ran, Linus extended his term program to run
> bash specifically. /bin/sh being bash was the one thing all Linux
> distros agreed on, until Ubuntu did a stupid.)
>
> Then, of course, the redirect didn't speed init up enough so they went
> down the parallelizing route and created "upstart", but didn't back out
> the /bin/sh change because that would be admitting they made a mistake.
> (They did relent enough to change the default so user accounts would
> have bash as their default shell in /etc/passwd.)
>
> Yes, it is a pet peeve of mine. :)
>
> Rob
>