[Top][All Lists]

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

bug#23090: true and false not POSIX

From: Stephane Chazelas
Subject: bug#23090: true and false not POSIX
Date: Tue, 22 Mar 2016 13:40:23 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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

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

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

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


reply via email to

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