[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 15:08:28 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- bug#23090: true and false not POSIX, Ruediger Meier, 2016/03/22
- bug#23090: true and false not POSIX, Stephane Chazelas, 2016/03/22
- bug#23090: true and false not POSIX, Ruediger Meier, 2016/03/22
- bug#23090: true and false not POSIX,
Stephane Chazelas <=
- bug#23090: true and false not POSIX, Eric Blake, 2016/03/22
- bug#23090: true and false not POSIX, Ruediger Meier, 2016/03/22
- bug#23090: true and false not POSIX, Paul Eggert, 2016/03/22
- bug#23090: true and false not POSIX, Stephane CHAZELAS, 2016/03/22
- bug#23090: true and false not POSIX, Ruediger Meier, 2016/03/22
- bug#23090: true and false not POSIX, Eric Blake, 2016/03/22
bug#23090: true and false not POSIX, Eric Blake, 2016/03/22