Bug#267142: huh?
Clint Adams <schizo@debian.org> writes:
> > You can rely on a POSIX-conformant test, certainly. Posix-conformant
> > does not mean that the "test" program doesn't have any additional
> > options or features. GNU test, which supports -a and is the Debian
> > standard implementation of the "test" command, is Posix-conformant.
>
> Hold on. If tbsh, a POSIX-conformant sh (according to your
> exclusion of "utilities"), implements a "test" builtin that isn't
> POSIX-conformant, does 10.4 apply or not? If it doesn't, how can you
> rely on a POSIX-conformant test?
"Posix-conformant" does not fully specify the behavior of programs.
For example, a posix conformant test might, or might not, implement
-a.
If I rely on GNU test, I am still relying on a POSIX conformant test.
So there is certainly a POSIX rule that a builtin test must implement
at least the POSIX "test" spec; but that's not enough in practice.
POSIX assumes that builtins will work exactly the same as the programs
in the filesystem, but never actually requires this, and that's the
root of the situation. Shells like posh (IIUC) implement builtins
like "test" in a way which is different from with the Debian versions.
> > Really? Because when I run "debconf" I expect to have it either be
> > not builtin, or be builtin compatibly with /usr/bin/debconf. I expect
> > the very same thing for every command.
>
> Even in the case of alternatives and diversions and conflicting packages
> providing the same-named binaries, in the presence or absence of actual
> standards describing those commands?
Yes. If I depend on a package, I am allowed to assume that the Debian
version of that package's files is installed, and rely on it having
exactly the behavior of the Debian version. But I must either depend
on the package; or it can be an essential package (which doesn't
require a dependency). In the common case here, "coreutils" is an
essential package, and I am allowed to assume that /usr/bin/test is
exactly that program.
Alternatives need in general to be specified, in terms of what is the
standard interface that must be supported by all the various
alternatives. In practice, that specification can be ad hoc, where
individual features either get declared "not standard", or the various
versions coerced to implement the same behavior.
/bin/sh in Debian has not normally been treated this way; treating it
that way would be like my OPTION 3, in which there is a specified
interface for /bin/sh. (Because the instant problem is that
"Posix-compliant shell" is not actually an adequate specification of
the interface of /bin/sh.)
Thomas
Reply to: