On Thu, 2006-11-16 at 19:23 -0600, Manoj Srivastava wrote: > The issue, apparently, is that under policy, some shell can > come up with all kinds of shadowing of things like debconf. I > suggest that if brought before the TC, the TC shall decide that is a > bug in the shell. Policy is not supposed to be written to specify > all kinds of silly and deliberate malice on the part of shell > authors.
Sorry, no, that's not the issue. If that were the issue, I would agree that it is not worth worrying about. The problem is that the specification "Posix compatible shell" doesn't mean anything. It is most certainly not something specified by Posix. What Posix does specify is the shell and utilities, considered as a unity, as a single thing. It does not specify what pieces of that might look like. Now you might say "well, a script is only allowed to rely on things that are specified in Posix.2, and not any extensions." The problem is that *every program in PATH* is regarded by Posix.2 as an extension. Now, you might say instead "well, a script is only allowed to rely on things that are specified in Posix.2 and the extensions created by installing programs in PATH from essential and Depends: packages." But that definition doesn't work, because it doesn't tell me whether I'm allowed to use things installed in PATH which have been overridden by a builtin. Or, you could say, "well, a script is allowed to rely on things specified in Posix.2, and extensions created by installing programs in PATH, except when shells commonly override those commands with builtins, in which case you cannot rely on them." This is a perfectly good specification, but it is incomplete, and needs a description of which builtins shells commonly override. This could be done either by giving a list of commands overridden, or by giving a list of shells which one must be compatible with. I see no reason for not just doing the latter. Thomas
signature.asc
Description: This is a digitally signed message part
