Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Clint Adams <schizo@debian.org> writes:
> > What it mentions for the Korn shell of course doesn't matter here.
>
> Is it? I was under the impression that a majority of the spec was based
> on Korn behaviors.
This is of historical interest; it is not of interest to what the
standard requires for the sh command interpreter.
> > Can you give me a reference to the latter? I looked carefully, and I
> > only found it mentioned as a utility.
>
> In the informative RATIONALE section of the description of the "test"
> utility:
>
> Some additional primaries newly invented or from the KornShell appeared
> in an early proposal as part of the conditional command ( [[]]): s1 >
> s2, s1 < s2, str = pattern, str != pattern, f1 -nt f2, f1 -ot f2, and f1
> -ef f2. They were not carried forward into the test utility when the
> conditional command was removed from the shell because they have not
> been included in the test utility built into historical implementations
> of the sh utility.
RATIONALE is not part of the standard, nor does this does not require
the test utility to be built in. It notes that building in test is
common, which is undisputed. The question is not what is common; the
question is what is required and what is permitted from a Posix
shell.
Debian Policy could say "don't rely on non-Posix behavior of utilities
which are commonly builtin to shells", but the problem with that is
the vagueness about "which are commonly builtin."
POSIX does not mandate building in test; "test", from the standpoint
of Posix, is just another utility.
And, like any utility, a shell may build it in if it wishes.
> It's possible for a shell to implement "ls" as a builtin. It's also
> possible for a sysadmin to implement "ls" as a shell function or alias.
> In fact, people tend to clamor about their need to have this ability
> when it is suggested that a full path to a program be used in a
> maintainer script.
Exactly. It's possibly for "defconf" to be that too. This is exactly
why the current language of the Policy manual fails.
> I suspect that as time goes on, some people will want to use "ls" from
> various *BSD userlands rather than the GNU coreutils version, and many
> flamewars will ensue.
But not here, because Policy says that if you are using something in
the Build-Essential set, you can rely on it being installed, and that
currently includes GNU coreutils. If you want something not in the
Build-Essential set, then you can get it if you include a
Build-Depends, and that's that.
So the problem here only happens with respect to the extremely broad
permission from Posix to buildin any or all utilities. This is not a
mistake in Posix, but it was a mistake for the Debian Policy Manual to
rely on Posix as it currently does, to be specifying a
"Posix-compatible shell". Which is why my original bug report says
"Posix doesn't say what you think it does".
Thomas
Reply to: