So will test be grandfathered?

[Thomas Hood <jdthood@aglu.demon.nl>]

[posting to the right place now...  my apologies for any duplication]

Manoj Srivastava suggested this language be added to 10.1 in order to
resolve the policy bug reported and discussed at great length in
#267142:
> ----------------------------------------------------------------------
>  10.1
> 
>   Except for the following shell builtins, additional commands provided
>   by a Debian shell installed in /bin/sh shall be considered to have the
>   same status as executables in the filesystem for the purpose of name
>   conflicts with other packages. As a result, they must either provide
>   the same functionality as the other program or else discuss with the
>   other maintainer and debian-devel which one should be renamed.
> 
> 
> Note:
> A Posix-conformant shell is allowed to build in *anything*, and if
> it's not a Posix-specified utility that's being built in, then it can
> have *any behavior whatsoever*.  The presence of two commands with
> conflicting behaviour adds an unacceptable uncertainty when scripts
> are executed, and this has to be resolved.
> ----------------------------------------------------------------------

Thomas Bushnell BSG <tb@becket.net> rightly asked:
> What we do still need is the list of grandfathered builtins.


While we wait for the official list to be compiled, can we at least
assume that "test" will be grandfathered?  If "test" will be
grandfathered then it follows that use of test's "-a" and "-o" options
should (continue to) be deprecated in scripts using /bin/sh.

Or will "test" not be grandfathered?  In that case some implementations
of "test" (coreutils's /usr/bin/test and the various "test" shell
builtins) will have to be modified, renamed or eliminated in order to
conform to the new/clarified rule.  Once the dust has settled there will
be a de facto standard "test" and, assuming that the latter implements
"-a" and "-o", there will be no need to deprecate the use of these
options.

-- 
Thomas Hood