On 03/19/10 07:19 AM, Sebastien Roy wrote:
> 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.
>
Perhaps I delve slightly into implementation detail here, but the issue
of consistency is something that needs to be addressed here and now, not
wait for the future.
-Norm
