Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

[Eric Blake]

On 11/06/2010 08:19 AM, Jim Meyering wrote:
> Andreas Schwab wrote:
> 
>> Jim Meyering <address@hidden> writes:
>>
>>> Here's a better test case:
>>>
>>>     $ /bin/sh -c 'f(){ local s=$IFS; test -n "$s"; }; f'
>>>     [Exit 1]
>>>
>>> And based on that, here's a patch to gnulib's tests/init.sh
>>> that solves the problem more generally:
>>> (but this is not enough for coreutils, since some
>>> failing tests don't yet use init.sh)
>>
>> Why not just add the quotes?  This isn't formally an assignment, so the
>> behaviour of the shell is reasonable after all.
> 
> Actually, I'm doing both for the upcoming release.
> Adding the quotes as a stop-gap measure, because it feels like a
> kludge.  I'll remove it once I've converted all tests to use init.sh.
> IMHO, the fact that VAR=$OTHER_VAL never needs quotes
> should imply that `local VAR=$OTHER_VAL' also requires no quotes.

Local is not required by POSIX.  If local is a normal application, then
it requires quotes.  Only shells that provide it as a special builtin,
like bash, can support 'local s=$IFS' without needing the quotes.

By the way, if you insist on having 'local', even though it is not
POSIX, you could at least work around the BSD shell issue by:

local s
s=$IFS

rather than joining the assignment in the same expression as the
declaration.  This is a good habit to get into anyways, since:

local s=$(false); echo $?
0
local t; t=$(false); echo $?
1

that is, local is an expression of its own, and succeeds if the
assignment completed, throwing out the status of any command
substitutions used to compute that value; while doing assignment on its
own line has nothing to override the command substitution value.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature