Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
On Fri, Aug 20, 2004 at 04:41:18PM -0700, Thomas Bushnell BSG wrote:
> Wouter Verhelst <wouter@grep.be> writes:
>
> > There's also,
> >
> > OPTION 5: Change section 10.4 to require the use of full pathnames when
> > non-Posix extensions are being used in commands; remove the "no
> > pathnames on commands" direction in section 6.1, but do discourage its
> > use whenever possible.
>
> Under one interpretation, this option doesn't work; under the other,
> it is as bad as option 4.
>
> First, if you mean "when non-Posix extensions are being used in
> Posix-specified commands" (like "test"), then it doesn't work, because
> a shell might well override "debconf" with a builtin, as I described.
Well, yeah, theoretically a shell could do that. However, in this
specific example, I would consider such a shell to be horribly broken.
'debconf' is a name which is clearly chosen to avoid namespace conflicts
such as the ones you're suggesting; and seen the fact that debconf is
quite well known right now, I consider it extremely unlikely for that to
be implemented in such a way.
Of course, that's not what you meant; but I'd think that other examples
would need to be examined on a case-by-case basis, and dealt with as
they occur, using a fair dosis of common sense.
The point being that, yeah, this is a possibility, but one that isn't
too likely. Given a) that Policy is just a guideline on how to perform
computer implementations, not one of those implementations itself; and
b) the absence of any proof to the contrary, I don't think these
problems are so likely that we need to worry about them right now. Also,
even if it's allowed, I don't think it's likely for a shell to implement
a builtin which is not specified by Posix (but I don't know all shells
out there and haven't read a Posix standard, ever, so I could be wrong)
Worst case, we could use wording which would make it clear that in the
case such a conflict ever appears, scripts breaking because of that
conflict should prepend a fixed path to the problematic command (or stop
using /bin/sh).
In other words, I suggest to deal with the things that are more likely
to happen, and to just ignore (but of course not dismiss) the less
likely problems.
> But if you mean "when non-Posix extension are being used, or non-Posix
> commands" then (because almost everything is non-Posix) we end up with
> all the brittleness that section 6.1 is trying to avoid,
No, that's the wrong interpretation ;-)
> and we lose all the performance benefits of shell builtins (when those
> builtins are well-behaved).
Indeed; however, if performance is an issue, then using /bin/sh is not
a real option anyway.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: