GNU bug report logs - #24116
new snapshot available: diffutils-3.3.50-0353

Previous Next

Full log

View this message in rfc822 format

From: Dave Gordon <david.s.gordon <at> intel.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 24116 <at> debbugs.gnu.org
Subject: bug#24116: [bug-diffutils] bug#24116: bug#24116: [platform-testers] new snapshot available: diffutils-3.3.50-0353
Date: Fri, 5 Aug 2016 16:54:17 +0100

On 05/08/16 15:09, Dave Gordon wrote:
> On 05/08/16 14:13, Harald van Dijk wrote:
>> On 5-8-2016 14:46, Dave Gordon wrote:
>>> On 01/08/16 01:36, Jim Meyering wrote:
>>>> On Sun, Jul 31, 2016 at 10:17 AM, Assaf Gordon <assafgordon <at> gmail.com>
>>>> wrote:
>>>>> Hello Jim
>>>>>
>>>>>> On Jul 31, 2016, at 03:08, Jim Meyering <jim <at> 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.

[snip]

>> Alternatively:
>>
>>     local a
>>     a=$(...)
>>
>> should work too, including in dash. Since a=$(...) is not an argument to
>> any command here, since it's the shell syntax that says it's an
>> assignment rather than the semantics of a particular command, field
>> splitting won't happen here.
>>
>> Cheers,
>> Harald van Dijk

Hi,

after Harald's explanation, can I suggest you change the script to
separate the "local" and the assignment? That appears to work on all
shells, including dash(1)

$ dash -c 'f() { local t; t=$(printf '\''\t\t'\''); printf "$t"; }; f' | hd
00000000  09 09                                             |..|
00000002

It's a really minimal (3-character) change, and it's less ugly than
adding the extra quotes that the standard seems to say should never
be needed :)

.Dave.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.