On 11/06/2010 08:19 AM, Jim Meyering wrote: > Andreas Schwab wrote: > >> Jim Meyering <[email protected]> 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 [email protected] +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
