[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20514: Patch to tie --help and --version behavior to POSIXLY_CORRECT

From: Eric Blake
Subject: bug#20514: Patch to tie --help and --version behavior to POSIXLY_CORRECT
Date: Wed, 06 May 2015 10:13:11 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 05/06/2015 09:40 AM, Shawn McMahon wrote:
> The following patch to "test" ties the behavior of "--help" and "--version"
> to POSIXLY_CORRECT. I don't believe this breaks anything, and if it does it
> can by fixed by setting the time-honored variable. This will solve the
> problem of users occasionally being confused by this behavior, which has
> happened even recently to coreutils developers. See for example:
> http://lists.gnu.org/archive/html/coreutils/2015-03/msg00007.html
> Proposed ChangeLog entry:
> Author: Shawn McMahon <address@hidden>
> Date:   Tue May 5 20:32:00 2015 -0400
>     test: tie --help and --version behavior to POSIXLY_CORRECT
> diff --git a/a/src/test.c b/b/src/test.c
> index 80cc679..3e73bb9 100644
> --- a/a/src/test.c
> +++ b/b/src/test.c
> @@ -789,6 +789,7 @@ INTEGER may also be -l STRING, which evaluates to the
> length of STRING.\n\
>  \n\
>  NOTE: [ honors the --help and --version options, but test does not.\n\
>  test treats each of those as it treats any other nonempty STRING.\n\
> +If POSIXLY_CORRECT is set, test honors both.\n\

Backwards.  The point of POSIXLY_CORRECT is that if it is set, we
conform to POSIX, if it is unset, then we have chosen to take on
intentionally non-compliant behavior.  If we make this change (and I'm
90-10 against changing anything at all), then:

/bin/test --help

would change to output help (as that is the non-compliant behavior), while

POSIXLY_CORRECT=1 /bin/test --help

would be the one that silently gives 0 status (because that is what
POSIX mandates).

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.

> -  if (LBRACKET)
> +  if (LBRACKET || getenv ("POSIXLY_CORRECT"))

Again, if we make the change, this logic is backwards (it should be
checking if POSIXLY_CORRECT is not set).

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]