[Top][All Lists]

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

bug#23090: true and false not POSIX

From: Ruediger Meier
Subject: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 17:39:19 +0100
User-agent: KMail/1.9.10

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.


reply via email to

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