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

Previous Next

Full log

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

Previous Next

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