On 05/06/2015 10:13 AM, Eric Blake wrote:
> intentionally non-compliant behavior.  If we make this change (and I'm
> 90-10 against changing anything at all), then:
> 

> But the reason I'm against changing it is that checking an arbitrary
> string for empty content is SUCH a common operation that making certain
> arbitrary strings special is more likely to break behavior of
> unsuspecting programs.  The escape hatch of "well, you should have set
> POSIXLY_CORRECT" is unappealing, as turning on POSIX compliance often
> cripples other non-standard extensions that people tend to rely on.

Another argument against the change: This proposal would only affect
/bin/test (or 'env test', or other constructs that force resolution
through PATH).  However, most shells have 'test' as a builtin, so it
will NOT impact those instances.  Having coreutils needlessly differ
from other implementations is undesirable.  If you can first get 'bash'
patched to do this, you might have a stronger argument, but bash is one
of those programs where the mere act of setting POSIXLY_CORRECT in the
environment changes a lot about how bash behaves.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org