GNU bug report logs - #23090
true and false not POSIX

Previous Next

Full log

Message #20 received at 23090 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Ruediger Meier <sweet_f_a <at> gmx.de>,
 Stephane Chazelas <stephane.chazelas <at> gmail.com>
Cc: 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 09:23:34 -0600

[Message part 1 (text/plain, inline)]

On 03/22/2016 08:39 AM, Ruediger Meier wrote:
>> While I'd tend to agree it would be better if they didn't accept
>> options as most other implementations don't, AFAIK, POSIX
>> doesn't forbid "true" implementations to accept options or
>> operands.
>>
>> What those "None" mean is that the behaviour is not
>> specified would an application pass arguments to "true".
>>
>> It doesn't say for instance that if passed any argument, it
>> should ignore them.
> 
> Ok, but it must not use STDOUT and it must return 0.
> true --help may predict the future of the stars as long as it exits 0 
> and does _not_ print anything. 
> 
>> A conforming application should not pass arguments to "true".
> 
> Why not?

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

> Guideline 3:
> Each option name should be a single alphanumeric character (the alnum character classification) from the portable character set. The -W (capital-W) option shall be reserved for vendor options.
> 
> Multi-digit options should not be allowed.

On that grounds, ANY use of an option named '--help' is already
unspecified behavior according to POSIX, because it is not a valid
option name.  So a POSIX-ly correct application should not be giving
long options to any utility with any expectation of a particular behavior.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html

> OPTIONS
> ...
> Default Behavior: When this section is listed as "None.", it means that the implementation need not support any options. Standard utilities that do not accept options, but that do accept operands, shall recognize "--" as a first argument to be discarded.
> 
> The requirement for recognizing "--" is because conforming applications need a way to shield their operands from any arbitrary options that the implementation may provide as an extension. For example, if the standard utility foo is listed as taking no options, and the application needed to give it a pathname with a leading <hyphen>, it could safely do it as:
> 
> foo -- -myfile
> 
> and avoid any problems with -m used as an extension.

In other words, POSIX intentionally _allows_ 'true --help' to be an
extension, and because it is an allowed extension, conforming
applications must not assume that it behaves in any particular way.

> You may add options as long as you don't violate the specification.
> BTW coreutils "echo --help" is also wrong. Here POSIX explicitly 
> says: "Implementations shall not support any options".

No, 'echo' is a special case, and in this special case, coreutils' echo
_is_ compliant with POSIX, when you set POSIXLY_CORRECT in the environment.

> 
> BTW I know about POSIXLY_CORRECT env. I just ask this: Is it worth to 
> violate parts of POSIX just for minor cosmetical reasons?

We are NOT violating POSIX.  You have yet to quote chapter and verse
from POSIX pointing out something that coreutils is not already doing.

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

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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