|
|
|
|
|
|
by kergonath
785 days ago
|
|
|
> Until you have to gets your hands dirty and find small and bigger faults everywhere. For example, /bin/sh defaults to their ancient It’s irrelevant. Neither POSIX nor the UNIX certification (or being a descendant of the UNIXes of old like the BSDs) requires a recent GNU userland (which is, as the name implies, not UNIX). |
|
|
> > Until you have to gets your hands dirty and find small and bigger faults everywhere. For example, /bin/sh [...] doesn't work properly in these two parameter expansion cases:
> It’s irrelevant. Neither POSIX nor the UNIX certification [...] requires a recent GNU userland
Is it irrelevant?
If an implementation passes the conformance test suite, but is buggy according to the text of the spec in a way that is not caught by the test suite, can one really say it's "fully compliant with the POSIX standard"?
Is it the test suite that's the final arbiter of the POSIX standard, or is the text of the spec? Because I thought that the point of having a written spec, ratified by a standards body, is that the text of the spec defines what the spec is. It is the text of the spec that is submitted to the standards body, after all, not the test suite.