On Tue, Nov 14, 2006 at 09:36:36PM -0800, Thomas Bushnell BSG wrote:
> Why? Surely it would be useful to know what the differences are between
> various shells. The statement "Posix-compatible" was apparently
> intended by the authors of that part of the Policy Manual to do that
> work for us, but it doesn't. That doesn't mean the work is valueless.
POSIX (SUSv3) + -a/-o + local was such a statement, and you started
arguing because it did not contain your favorite-of-the-day feature. You
fail to realize that any such statement _WILL_ restrict the set of
allowed features because that is the _purpose_ of such a statement.
And yes, the world moves and sometimes the limits should be extended -
that's happening right now. But that does not mean that suddenly
everything-and-the-kithcen-sink that some particular implementation
supports should be allowed. And it is also _fine_ if GNU coreutils
supports more than required by the policy; just make sure you explicitely
write "/usr/bin/test" if you want to rely on such a feature.
> If you think that we can just assume that all existing shells do nothing
> bad in this regard, it should be about five minutes work to find out
> what all their builtins are and form the union of that set.
That changes whenever a new version of a shell is released, so the only
possible way to do this is to drop the feature-based requirements and
use an "it must work with shells x, y and z" approach. That way the
users of those shells would report any discrepancies as bugs, just as
they do now for bashisms. And yes, "x, y and z" has to be selected
carefully not to create many new bugs, but that I think is doable.
Also, listing "all existing shells" would be insane, since many of them
have specific goals and are simply not designed to be able to be used as
/bin/sh (just think about tcsh - it is an existing shell too).
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
