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

Previous Next

Full log

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

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

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

Previous Next

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