I fwd'd the email regarding VSC5 lite to our development team,
comments included below.
> I ran VSC5.1.1L on bash shell and communicated the results to Mr. Chet
> Ramey, the current maintainer of bash. I got his observation below and I
> don't know how to response. Please feel free to response to him directly
> if you want.
> > I have looked at the failed tests in sh_0 and I am not impressed
> >with the test suite. It seems to have been designed to verify that a
> >machine which has ksh installed as /bin/sh is POSIX-conformant. If
> >they wanted a test to prove that ksh was POSIX-conformat, they could
> >hardly have written a better one.
At the time VSC was developed, I think the only POSIX shells available
were all based on ksh, so it is hardly surprising if a few ksh-isms
in the shell code have crept in.
> >The test suite is riddled with ksh-isms that are not POSIX: `print',
> >relying on the shell to perform arithmetic expansion on the arguments
> >to `test's numeric operators, the fact that ksh doesn't include function
> >bodies in the output of `set', etc.
Somebody needs to check each of these carefully against POSIX.2.
Those that are believed to be genuine bugs in VSC could then be
forwarded to our team.
The one about expecting printf to accept expressions as arguments
sounds like a VSC bug. However, the output of `set' produced by bash
is definitely not POSIX compliant.
> >Many of the failed tests also call `sh' directly, which is probably not
> >the shell you're testing. It's a good way to see whether /bin/sh is
> >POSIX-conformant, but not anything else.
VSC is used to test the POSIX.2 compliance of a whole system, so
the shell tests are designed with that in mind. POSIX.2 requires
that the "sh" utility implements the POSIX shell language,
therefore that is the particular shell which the POSIX.shell tests
are intended to test.
If a user wishes to run the POSIX.shell tests against another shell,
they could probably achieve this by installing a symlink called "sh"
in a suitable place in their PATH.