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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23090 in the body.
You can then email your comments to 23090 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 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
Subject: true and false not POSIX
Date: Tue, 22 Mar 2016 13:43:30 +0100

Hi,

Is there any good reason why coreutils true and false are not POSIX?

man 1p true:
  OPTIONS
       None.
  STDOUT
       Not used.

But coreutils true has --version and --help implemented. It needs 
>/dev/null redirection to work as expected.

Also these options are the reason why true.c is using many library 
functions like setlocale, etc. The binary is bloated and the risk that 
something goes wrong/crashs is much higher. I was looking for a minimal 
and rock-solid true command to be used in scripts.

IMO it is not worth to violate POSIX just because of cosmetical reasons 
(--help/--version). Moreover since the true command usually comes from 
the shell I guess that almost no person on earth ever had seen your 
nice --help output anyways.


cu,
Rudi

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

From: Stephane Chazelas <stephane.chazelas <at> gmail.com>
To: Ruediger Meier <sweet_f_a <at> gmx.de>
Cc: 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 13:40:23 +0000

2016-03-22 13:43:30 +0100, Ruediger Meier:
[...]
> Is there any good reason why coreutils true and false are not POSIX?
> 
> man 1p true:
>   OPTIONS
>        None.
>   STDOUT
>        Not used.
> 
> But coreutils true has --version and --help implemented. It needs 
> >/dev/null redirection to work as expected.
[...]

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.

A conforming application should not pass arguments to "true".

There are a number of other utilities that don't accept options
in their specification (like "exec", "dirname",...) and still
implementations (including certified ones) do support options.

You'll notice that for the ":" special builtin, the spec is
explicit in that it can take arguments and ignores them.

Note that "true" is built in most Bourne like shells, coreutils
true would only be invoked if called not as part of a shell
command line or if called by path.

env true --help
/bin/true --help
find file -exec true --help \;
csh -c 'true --help'
rc -c 'true --help'

Alternatives to "true" that are guaranteed to be built-in are
":" and "eval" (without argument; also available in csh and rc
like shells). "test" is also generally built in Bourne-like
shells.

For a no-op command that takes arbitrary arguments, there are:

sh -c ''
awk 'BEGIN{exit}'
printf ''

-- 
Stephane

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

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: 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 15:39:52 +0100

On Tuesday 22 March 2016, Stephane Chazelas wrote:
> 2016-03-22 13:43:30 +0100, Ruediger Meier:
> [...]
>
> > Is there any good reason why coreutils true and false are not
> > POSIX?
> >
> > man 1p true:
> >   OPTIONS
> >        None.
> >   STDOUT
> >        Not used.
> >
> > But coreutils true has --version and --help implemented. It needs
> >
> > >/dev/null redirection to work as expected.
>
> [...]
>
> 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?

> There are a number of other utilities that don't accept options
> in their specification (like "exec", "dirname",...) and still
> implementations (including certified ones) do support options.

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".

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.

> You'll notice that for the ":" special builtin, the spec is
> explicit in that it can take arguments and ignores them.
>
> Note that "true" is built in most Bourne like shells, coreutils
> true would only be invoked if called not as part of a shell
> command line or if called by path.


> env true --help
> /bin/true --help
> find file -exec true --help \;
> csh -c 'true --help'
> rc -c 'true --help'
>
> Alternatives to "true" that are guaranteed to be built-in are
> ":" and "eval" (without argument; also available in csh and rc
> like shells). "test" is also generally built in Bourne-like
> shells.
>
> For a no-op command that takes arbitrary arguments, there are:
>
> sh -c ''
> awk 'BEGIN{exit}'
> printf ''

These are no binaries but shell commandlines. You can't pass it to other 
programs, like gdb, setarch or whatever.

cu,
Rudi

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

From: Stephane Chazelas <stephane.chazelas <at> gmail.com>
To: Ruediger Meier <sweet_f_a <at> gmx.de>
Cc: 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 15:08:28 +0000

2016-03-22 15:39:52 +0100, Ruediger Meier:
> On Tuesday 22 March 2016, Stephane Chazelas wrote:
> > 2016-03-22 13:43:30 +0100, Ruediger Meier:
[...]
> 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. 

No, it is only required to exit with 0 and print nothing if
called as specified, that is without arguments. If passed any
argument, the behaviour is not specified.

Just like

dirname --help

is unspecified.

dirname -- foo/bar

is specified as utilities (other than the special builtins that
are not required to follow syntax guidelines) that take operands
must recognise (and ignore) a leading "--" argument.

true --

is not as true doesn't take operands. In practice though, you
could do "true -- --arbitrary args being ignored". That seems to
work with all the "true" implementations I've tried, but POSIX
would still leave that unspecified.

> > A conforming application should not pass arguments to "true".
> 
> Why not?

Because then the behaviour would be unspecified.

> > There are a number of other utilities that don't accept options
> > in their specification (like "exec", "dirname",...) and still
> > implementations (including certified ones) do support options.
> 
> 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".

Yes, the behaviour of echo when passed a "--help" argument is
clearly specified.

> 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.

[...]
> > sh -c ''
> > awk 'BEGIN{exit}'
> > printf ''
> 
> These are no binaries but shell commandlines. You can't pass it to other 
> programs, like gdb, setarch or whatever.

POSIX systems are required to have sh, awk and printf commands
in the filesystem.

There shouldn't be any problem passing them to gdb/setarch/env
or whatever.

replace the non-portable/non-standard:

execlp("true", "true", "--help", "and", "other", "arbitrary", "args", 0);

with:

execlp("awk", "awk", "BEGIN{exit}", "--help", "sh", "and", "other", "arbitrary", "args", 0);

for instance

(btw, sh -c '' may not be that good a choice because if sh is
yash, you'd get errors if arguments contain invalid characters).

-- 
Stephane

Message #17 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>, 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 09:13:40 -0600

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

On 03/22/2016 06:43 AM, Ruediger Meier wrote:
> Hi,
> 
> Is there any good reason why coreutils true and false are not POSIX?

No, because coreutils' true and false ARE compliant with POSIX.

> But coreutils true has --version and --help implemented. It needs 
>> /dev/null redirection to work as expected.

Not true.  POSIX says that behavior is unspecified for 'true --help'.
Therefore, whatever coreutils does in that case does not violate POSIX.

'true -- --help', on the other hand, must be silent - but coreutils
obeys that rule.

> 
> Also these options are the reason why true.c is using many library 
> functions like setlocale, etc. The binary is bloated and the risk that 
> something goes wrong/crashs is much higher. I was looking for a minimal 
> and rock-solid true command to be used in scripts.

If coreutils' true crashes due to wrong file permissions causing
setlocale() to fail, your system is already going to have severe
problems with other utilities.  Coreutils is complying with GNU Coding
Standards at the same time as POSIX, and we do not feel that it is
bloated for doing so.

> 
> IMO it is not worth to violate POSIX just because of cosmetical reasons 
> (--help/--version). Moreover since the true command usually comes from 
> the shell I guess that almost no person on earth ever had seen your 
> nice --help output anyways.

On many GNU/Linux systems, 'man true' displays the coreutils' man page
for true, which in turn was generated from 'true --help' output.  So a
lot more people read it than you might think, even if they don't
directly invoke it.

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

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

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)]

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

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

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

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.

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

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

Message #26 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>, 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 09:30:58 -0600

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

On 03/22/2016 09:13 AM, Eric Blake wrote:
> On 03/22/2016 06:43 AM, Ruediger Meier wrote:
>> Hi,
>>
>> Is there any good reason why coreutils true and false are not POSIX?
> 
> No, because coreutils' true and false ARE compliant with POSIX.
> 
>> But coreutils true has --version and --help implemented. It needs 
>>> /dev/null redirection to work as expected.
> 
> Not true.  POSIX says that behavior is unspecified for 'true --help'.
> Therefore, whatever coreutils does in that case does not violate POSIX.
> 
> 'true -- --help', on the other hand, must be silent - but coreutils
> obeys that rule.

Correction - POSIX says that 'true -- --help' is unspecified, so
coreutils can do whatever it wants (and in that case, GNU coreutils
opted to treat '--help' as an ignored operand, because the '--' ended
the chance to treat it as an option).

According to POSIX, the _only_ specified use of 'true' is without operands:

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

> SYNOPSIS
> 
> true

Any other arguments on the command line are extensions, and can behave
however the implementation wants; portable apps will not be invoking
'true' with arguments, because they are no longer getting behavior
mandated by POSIX.

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

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

Message #33 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
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 17:38:27 +0100

On Tuesday 22 March 2016, Eric Blake wrote:
> On 03/22/2016 06:43 AM, Ruediger Meier wrote:
> > Hi,
> >
> > Is there any good reason why coreutils true and false are not
> > POSIX?
>
> No, because coreutils' true and false ARE compliant with POSIX.
>
> > But coreutils true has --version and --help implemented. It needs
> >
> >> /dev/null redirection to work as expected.
>
> Not true.  POSIX says that behavior is unspecified for 'true --help'.
> Therefore, whatever coreutils does in that case does not violate
> POSIX.

I've seen many existing scripts where people do something like this:

cmd=whatever
# ignore if not exist
type "$cmd" || cmd="true"
[...]
$cmd --something --we --want --to --do --if --possible
[...]

Similar use case would be to set cmd="echo debug whatever: ".

You can't decline that you implicitly accept such usage, otherwise
$ true --blabla
would not return true (without error message) and
$ false --help
would not return false.

These exit codes are not good GNU Coding Standards I guess. Also not 
non-getopt behavior like "echo string --help".

> 'true -- --help', on the other hand, must be silent - but coreutils
> obeys that rule.
>
> > Also these options are the reason why true.c is using many library
> > functions like setlocale, etc. The binary is bloated and the risk
> > that something goes wrong/crashs is much higher. I was looking for
> > a minimal and rock-solid true command to be used in scripts.
>
> If coreutils' true crashes due to wrong file permissions causing
> setlocale() to fail, your system is already going to have severe
> problems with other utilities.  Coreutils is complying with GNU
> Coding Standards at the same time as POSIX, and we do not feel that
> it is bloated for doing so.
>
> > IMO it is not worth to violate POSIX just because of cosmetical
> > reasons (--help/--version). Moreover since the true command usually
> > comes from the shell I guess that almost no person on earth ever
> > had seen your nice --help output anyways.
>
> On many GNU/Linux systems, 'man true' displays the coreutils' man
> page for true, which in turn was generated from 'true --help' output.
>  So a lot more people read it than you might think, even if they
> don't directly invoke it.

I'm sure that's possible to write manpages without --help ...

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.

cu,
Rudi

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

Message #42 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>, 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 10:48:16 -0600

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

On 03/22/2016 10:38 AM, Ruediger Meier wrote:
> I've seen many existing scripts where people do something like this:
> 
> cmd=whatever
> # ignore if not exist
> type "$cmd" || cmd="true"
> [...]
> $cmd --something --we --want --to --do --if --possible
> [...]

Such scripts are non-portable.  They could use:

type "$cmd" || cmd=:

for more portability.  It's not our fault that non-portable scripts exist.

> 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.

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'.

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

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

Message #45 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>
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 18:56:17 +0100

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

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

From: Eric Blake <eblake <at> redhat.com>
To: Ruediger Meier <sweet_f_a <at> gmx.de>, bug-coreutils <at> gnu.org
Cc: 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 12:00:55 -0600

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

On 03/22/2016 11:56 AM, Ruediger Meier wrote:

>> 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.

It's not coreutils' fault if distros don't know how to make 'man true'
redirect to the shell's man page.

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

Sorry, but that would violate GNU Coding Standards, so we aren't going
to do it.

> 
> 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 probability that someone knows well-known GCS behavior of '--help'
working are also high.  At this point, the change would be more
disruptive than keeping the status quo.

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

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

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

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

On Tuesday 22 March 2016, Eric Blake wrote:
> On 03/22/2016 11:56 AM, Ruediger Meier wrote:
> >> 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.
>
> It's not coreutils' fault if distros don't know how to make 'man
> true' redirect to the shell's man page.
>
> > I suggest an enhancement for portability and implementation
> > simplicity to remove the options --version and --help from true,
> > false echo and [.
>
> Sorry, but that would violate GNU Coding Standards, so we aren't
> going to do it.

So then test --help is a coreutils bug because it does not respect GNU 
Coding Standard? As already said the exit codes are for sure not 
GNU-style too.

What about changing GNU Coding Standards to allow to break them if they 
don't make any sense like in this case?

> > 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 probability that someone knows well-known GCS behavior of
> '--help' working are also high.  At this point, the change would be
> more disruptive than keeping the status quo.

Yep one might use it in scripts wrongly:

/bin/false --version &>/dev/null || echo "cant determine version"

or right:

if test -n "$(/usr/bin/true --help)"; then
  rm -f /usr/bin/true
  echo 'int main(int argc, char **argv){return 0;}'> /tmp/true.c
  cc /tmp/true.c -o /usr/bin/true
fi

cu,
Rudi

Message #60 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>
Cc: 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 12:56:58 -0600

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

On 03/22/2016 12:35 PM, Ruediger Meier wrote:

>>> I suggest an enhancement for portability and implementation
>>> simplicity to remove the options --version and --help from true,
>>> false echo and [.
>>
>> Sorry, but that would violate GNU Coding Standards, so we aren't
>> going to do it.
> 
> So then test --help is a coreutils bug because it does not respect GNU 
> Coding Standard? As already said the exit codes are for sure not 
> GNU-style too.

No, 'test --help' is a special case where we follow the POSIX rules
always, because we have '[ --help' in its place for when we want to
expose the GNU capabilities of the same .c file.

> 
> What about changing GNU Coding Standards to allow to break them if they 
> don't make any sense like in this case?

You're welcome to propose a change to the standards; but they are not
maintained on this list; see bug-standards <at> gnu.org  If you get that
change approved by rms, then we'll adjust coreutils to match.  But rms
will probably ask for the coreutils' maintainers' opinion before
approving such a change, so it will be an uphill battle on your side.

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

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ruediger Meier <sweet_f_a <at> gmx.de>, 23090 <at> debbugs.gnu.org
Cc: stephane.chazelas <at> gmail.com
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 12:31:50 -0700

On 03/22/2016 09:39 AM, Ruediger Meier wrote:
> You could also let true behave like rm if POSIXLY_CORRECT is not set or
> if more than zero option given.
This misunderstands the intent of POSIXLY_CORRECT. Setting 
POSIXLY_CORRECT does not mean "remove all extensions not specified by 
POSIX". It merely means "conform to POSIX even where the default is to 
not conform".

It might be helpful to have some other environment variable that meant 
"try to be strict about supporting only behavior required by POSIX", as 
one could use that to develop shell scripts that were more portable. 
However, that would be a lot of work to implement, and it's not clear 
it's worth the hassle to develop, maintain, and document. Plus, POSIX 
does not always specify behavior, so portability wouldn't be guaranteed 
by this.

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

From: Stephane CHAZELAS <stephane.chazelas <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Ruediger Meier <sweet_f_a <at> gmx.de>, 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 20:19:37 +0000

2016-03-22 12:31:50 -0700, Paul Eggert:
[...]
> It might be helpful to have some other environment variable that
> meant "try to be strict about supporting only behavior required by
> POSIX", as one could use that to develop shell scripts that were
> more portable. However, that would be a lot of work to implement,
> and it's not clear it's worth the hassle to develop, maintain, and
> document. Plus, POSIX does not always specify behavior, so
> portability wouldn't be guaranteed by this.


But then in that environment, true --help would report an error:

true: no argument allowed

and exit with a non-zero exit status like when other non-POSIX
extensions are not supported. It wouldn't make true more POSIX
conformant but it would help people write POSIX scripts by
telling them the feature they rely on (true ignoring arguments)
is not standard.

The OP's request was primarily about increasing portability with
other true implementation where in "true --help", the "--help"
argument is ignored.

I agree POSIX true doesn't accept arguments, but before GNU
"true" started accepting --help, --version, you could do
portably (if not standardly):

true "$args" to be ignored

-- 
Stephane

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

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 22:14:40 +0100

On Tuesday 22 March 2016, Stephane CHAZELAS wrote:
> 2016-03-22 12:31:50 -0700, Paul Eggert:
> [...]
>
> > It might be helpful to have some other environment variable that
> > meant "try to be strict about supporting only behavior required by
> > POSIX", as one could use that to develop shell scripts that were
> > more portable. However, that would be a lot of work to implement,
> > and it's not clear it's worth the hassle to develop, maintain, and
> > document. Plus, POSIX does not always specify behavior, so
> > portability wouldn't be guaranteed by this.
>
> But then in that environment, true --help would report an error:
>
> true: no argument allowed
>
> and exit with a non-zero exit status like when other non-POSIX
> extensions are not supported. It wouldn't make true more POSIX
> conformant but it would help people write POSIX scripts by
> telling them the feature they rely on (true ignoring arguments)
> is not standard.
>
> The OP's request was primarily about increasing portability with
> other true implementation where in "true --help", the "--help"
> argument is ignored.
>
> I agree POSIX true doesn't accept arguments, but before GNU
> "true" started accepting --help, --version, you could do
> portably (if not standardly):
> true "$args" to be ignored

Frankly the only sane implementation of true(1) is IMO a main function 
which does nothing but return 0. Actually I was shocked then I saw 
coreutil's true.c today. Why on earth would somebody use getopt and 
locale machinery to implement the POSIX specification of true?

Anyways I give up, GNU-Style-Conventions seem to be much stronger than 
any common sense.

Don't get me wrong I really like --help and --version for real programs 
and I respect that coreutils did a good job to add these options 
strictly to all their progs. But for true and false? How could the 
true's version be interesting for somebody since there does only one 
sane true.c exist?

PS actually my personal issue with true is not really that I want to use 
it with options. I was simply looking for a minmal binary, available on 
any systems. Unfortunately true is not and will never be.

cu,
Rudi

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Ruediger Meier <sweet_f_a <at> gmx.de>, Eric Blake <eblake <at> redhat.com>
Cc: 23090 <at> debbugs.gnu.org
Subject: Re: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 23:53:36 +0100

On 03/22/2016 07:35 PM, Ruediger Meier wrote:
>   echo 'int main(int argc, char **argv){return 0;}'> /tmp/true.c

coreutils' src/true.c does exactly that - unless the user passes
an argument:

  int
  main (int argc, char **argv)
  {
    /* Recognize --help or --version only if it's the only command-line
       argument.  */
    if (argc == 2)
      {
        ...
      }

    return EXIT_STATUS;
  }

So what's your point here? File size?  Well, on my openSUSE system
/usr/bin/true needs 27328 bytes.  Compared to the 6-7K your minimal
example above result in (compiled with -O2 -g, then stripped), I'd
consider this neglectable for nowadays' RAM and disk sizes.

Re. '/usr/bin/[' --help:
I'm using it myself from time to time, as I like the terse
information there.

Have a nice day,
Berny

Previous Next

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