On Sun, Jul 31, 2016 at 10:17 AM, Assaf Gordon <assafgordon@gmail.com> wrote:
> Hello Jim
>
>> On Jul 31, 2016, at 03:08, Jim Meyering <jim@meyering.net> wrote:
>>
>> diffutils snapshot:
>>  http://meyering.net/diff/diffutils-3.3.50-0353.tar.xz
>>
>
> The "colors" test seems to succeed on Fedora/CentOS/SUSE systems (of various versions), but fail on others (Ubuntu, Debian, FreeBSD, Mac OS X).
>
> Attached are logs from 3 systems. From a cursory look it seems the exact same failure, but I haven't looked deeper.
> No other test failures found, but I'll have more results later today.

Hi Assaf,
Thank you for all the speedy testing.
I've looked into the failure on a Debian system for which /bin/sh is
dash 0.5.8-2.2.
dash's printf builtin handles \e differently -- that's easy to work
around: use \033, which *is* portable.
More surprising is that this generates no output:

  dash -c 'f() { local t=$(printf '\''\t\t'\''); printf "$t"; }; f'

I.e., piping it into wc -c prints 0.
With bash, it prints the expected pair of TAB bytes.
I found that I could work around this nonsensical behavior by hoisting
the "tab=..." definition up/out of those two functions, or by adding
standard-says-never-necessary double quotes like this:

  dash -c 'f() { local t="$(printf '\''\t\t'\'')"; printf "$t"; }; f'

However, I prefer not to work around it here (and in every other test
script where this comes up), and will insulate all of our test scripts
by rejecting any shell with that misbehavior, so plan to adjust
init.sh to select another shell when it finds this flaw.

On second thought, I will make the local change now, and sleep on the
idea of making init.sh reject dash.
Done in the attached patch.