bug-coreutils
[Top][All Lists]
Advanced

[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 18:56:17 +0100
User-agent: KMail/1.9.10

On Tuesday 22 March 2016, Eric Blake wrote:
> On 03/22/2016 10:38 AM, Ruediger Meier wrote:

> > BTW this man page does not match to the most probably used built-in
> > command. This confuses the reader even more and is IMO another
> > argument why coreutils shouldn't have added --help options for
> > these kind of commands.
>
> The man page (and --help output) specifically state:
>
>        NOTE: your shell may have its own version of true, which
> usually super‐
>        sedes the version described here.  Please refer to your 
> shell's docu‐
>        mentation for details about the options it supports.

I knew this note. However in the real world it simply does not make 
sense to get a man page about something which is not used usually.

> So far, you haven't identified anything that we need to change in
> behavior in either 'true' or 'false' (certainly not any changes
> required for POSIX compliance, although it appears you are now moving
> on to questioning our extension behavior when used in ways not
> mandated by POSIX).  Therefore, I've taken the liberty of closing
> this bug report. But feel free to continue discussion, and if you can
> come up with a change that we _should_ make that won't disrupt
> existing clients, then we can reopen the bug to track that.  Note
> that it is a high bar to change the behavior of something like
> 'true'.

I suggest an enhancement for portability and implementation simplicity 
to remove the options --version and --help from true, false echo and [.

It's a problem that the most used implementations (POSIX or built-ins) 
behave differently and users might not be aware this fact when they use 
the coreutils implementations by mistake or on purpose. Since the use 
cases when somebody really needs a true, false or echo _binary_ are 
rare, the probabilty is high that the user assumes well known behavior.

The GNU coding style which requires these options is already violated 
for the test command. It's pedantic to require POSIXLY_CORRECT to 
disable such cosmetical options (case echo).

This behavior enhancment would imply an implementation enhancement for 
true and false because we could remove any locale and environment 
checks. One use case for a simple true _binary_ is for example to test 
other command (like setarch, gdb, strace, exec) if they work correctly 
on their system. All this complicated code in true makes it more 
unusable for such cases and people have to compile their own main 
function which returns 0.

cu,
Rudi





reply via email to

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