bug#23090: true and false not POSIX

[Ruediger Meier]

On Tuesday 22 March 2016, Eric Blake wrote:
> On 03/22/2016 09:08 AM, Stephane Chazelas wrote:
> >> BTW I know about POSIXLY_CORRECT env. I just ask this: Is it worth
> >> to violate parts of POSIX just for minor cosmetical reasons?
> >>
> >> I mean echo -n/-e may be an improvement though non-posix. But
> >> echo --version is a violation just for cosmetics, true --version
> >> is even worse.
> >
> > AFAICT, echo --version is a violation, true --version is not.
>
> 'echo --version' is not a violation.  POSIX says that you are allowed
> to require the user to set a particular environment variable to enter
> the POSIX-conformant setup; in GNU coreutils' case, that variable is
> POSIXLY_CORRECT.  When set, coreutils' echo behaves exactly as POSIX
> requires.  When not set, coreutils' echo behaves as GNU Coding
> Standards require.  As the two standards conflict, we cannot do both
> behaviors at once; so the behavior of choice is determined by your
> environment variables.
>
> In the case of 'true' and 'false', the two standards do not conflict,
> so we implement both of them at once without the need to resort to
> reading POSIXLY_CORRECT from the environment.


You could also let true behave like rm if POSIXLY_CORRECT is not set or 
if more than zero option given. Does it make sense to change the 
behavior fundamentally?

IMO bash for example does the most natural trade-off. They have -neE but 
nothing else.

cu,
Rudi