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 <[email protected]> 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 > _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
