On Thu, 2006-11-16 at 21:16 -0600, Manoj Srivastava wrote: > Your scripts shouuld really just use whatever POSIX mandates > ls has. Just like it should use whatever POSIX mandates test has. Ok, so this means something like the following would be good for policy: "When POSIX specifies a command, shell scripts should only use the options mandated by POSIX for that command, even if the standard Debian versions have more. Specify a complete pathname to the command if you need the options the standard Debian version provides. (Exceptions: echo -n, and test -a/-e may be used even though not mandated by POSIX.) "You may use commands not specified by POSIX, provided they are in essential packages, or packages that you Depends: on." > Like POSIX, your script ought not to care about where the > command comes from. If you have depended on debconf, you can rely on > it present. If something makes debconf not behave like the > documentation for debconf says it should, that thing is buggy. > Either there is a bug in debconf, or there is a bug in the shell > interpreter. I'm not sure I understand, because this seems like you said something different previously. You are saying that if a shell makes debconf behave differently than /usr/bin/debconf, and that breaks your script, then it's a bug in the shell and a script author need not worry, right? Sounds excellent to me. But we have the case where shells make test or echo or kill behave differently than /usr/bin/test, /bin/echo, and /bin/kill. The only difference, it seems to me, is that POSIX mandates test, echo, and kill, but does not mandate debconf. In that case, the suggested text I wrote above, which makes this distinction, would do the trick, right? Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part