Norm, On 03/19/10 04:34 AM, Norm Jacobs wrote: > I think that in part, I misread this: >> Interface Stability Description >> --------- --------- ----------- >> ksh93 '/usr/gnu/bin/basename' built in Uncommitted basename utility >> with GNU extensions ... > to mean that > > $ ksh93 -c "/usr/gnu/bin/basename" > > would use the ksh93 basename built-in, which supports GNU extensions. > Though that does seem in conflict with the paragraph that precedes the > table. I gather that it means that > > $ PATH=/usr/gnu/bin:/usr/bin /usr/bin/ksh93 -c "basename" > > will use the ksh93 basename built-in, which happens to support GNU > extensions.
Correct: Fully qualified command names do not use built-ins. This is specified by 2006/550. >> Given that the shell honors compatibility within each of the >> applicable paths for which it provides built-in bindings, there >> doesn't seem to be any issue regarding "compatible behavior". > > If ksh93 built-ins are really drop-in replacements for the interfaces > they intend on interposing on under ksh93 (/usr/bin, /usr/xpg4, > /usr/gnu, ...), then we should be delivering a wrapper/link to the ksh93 > version so that we have consistency regardless of shell/execution > environment. It could be the intention of this case and that I just > missed it in my read through. If they are direct replacements, then they > should use delivered as such. If they are not direct replacements, then > they should probably not be used in place of their intended target under > ksh93 only. > > This may also have some added benefit in helping us be able to better > deal with conflict/divergence down the road. Yes, that's a good point, and perhaps that can be looked into in the future. However, I think this discussion is veering off-topic for this case, as you're now debating the implementation and architecture of the shell built-ins in general, which is not being introduced by this case. That was introduced by PSARC 2006/550. This case is building upon previously approved architecture. -Seb
