Garrett D'Amore wrote: > The point of this case is that the builtins are drop-in compatible. You > should not care about the implementation. If you *do*, then you're an > edge case user and its not unreasonable that you have to suffer some > extra pain to get exactly the implementation bits you want.
I think the relevant architectural question should be: "if a project team wants to update an existing GNU utility, what must that team do in order to avoid regression for ksh93 users, and how does that project team know that they need to do this?" That's the part that needs to be described adequately, so that any team doing that work doesn't have to stumble in the dark. If the answer is, "they must coordinate first with the ksh93 team," that seems reasonable, but there needs to be _some_ clear answer. I see nothing wrong with silently replacing existing utilities with better-performing ones having exactly the same interface, but I do think it's a problem if some users may accidentally see "old" versions of something that has been updated. (In particular, seeing a newly updated man or GNU info page, and having a new feature listed there not work because the command invocation is redirected by the shell would be pretty confusing.) -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
