bug#23090: true and false not POSIX

[Ruediger Meier]

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