bug#23090: true and false not POSIX

[Stephane Chazelas]

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