On 03/18/10 09:54 PM, Sebastien Roy wrote:
> Norm,
>
> On 03/18/10 07:57 PM, Norm Jacobs wrote:
>> It's not that I don't think that the ksh93 built-ins have a place and
>> that they couldn't be a perfectly reasonable default for most people. In
>> some cases, they seem to provide something that is sorely needed in the
>> Solaris userland, a blend of POSIX conforming and GNUish commands.
>
> I'm afraid I don't understand your initial point. That's not what the
> ksh93 shell built-ins provide. $PATH is still honored, and the
> built-ins are compatible with the commands that are resolved from
> $PATH. You do not suddenly get a blend of POSIX and GNU commands.
I guess I just assumed that there would be one ksh93 built-in here for
something like basename and that it would take the same arguments and
function the same regardless of whether ksh93 were executing it in place
of the /usr/gnu, /usr/xpg4, or /usr/bin version. Perhaps that's not the
case.
> I believe that architecture introduced by PSARC 2006/550 maintains
> the semantics of $PATH by binding a built-in to a pathname, and only
> executing a built-in when a $PATH search matches the binding.
Perhaps I am misunderstanding this part of the current case.
> Part 1: ksh93 built in mappings for /usr/gnu/bin utilities
> ----------------------------------------------------------
> The case proposes to enable the following mappings to ksh93 built in
> commands for utilities in /usr/gnu/bin. When the utility is called
> using it's command name, and not the full path, the ksh93 builtin
> will be used instead of executing the /usr/gnu/bin binary.
>
As I understand that statement
$ PATH=/usr/gnu/bin:/usr/bin /usr/bin/ksh93 -c "basename --version"
and
$ PATH=/usr/gnu/bin:/usr/bin
/usr/bin/{your-favorite-non-ksh93-shell} -c "basename --version"
will return different results. Given that I explicitly put /usr/gnu/bin
at the front of the PATH in the examples, I would expect
/usr/gnu/bin/basename warts and all. Though perhaps it's only slightly
different and perhaps slightly better than the shell built-in bits that
are things like test, echo, ...
I think that in part, I misread this:
> Interface Stability Description
> --------- --------- -----------
> ksh93 '/usr/gnu/bin/basename' built in Uncommitted basename utility
> with GNU extensions
> ksh93 '/usr/gnu/bin/cksum' built in Uncommitted cksum utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/comm' built in Uncommitted comm utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/cut' built in Uncommitted cut utility with GNU
> extensions
> ksh93 '/usr/gnu/bin/dirname' built in Uncommitted dirname utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/expr' built in Uncommitted expr utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/fold' built in Uncommitted fold utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/join' built in Uncommitted join utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/logname' built in Uncommitted logname utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/mkdir' built in Uncommitted mkdir utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/mkfifo' built in Uncommitted mkfifo utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/mktemp' built in Uncommitted mktemp utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/pathchk' built in Uncommitted pathchk utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/paste' built in Uncommitted paste utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/sleep' built in Uncommitted sleep utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/sync' built in Uncommitted sync utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/tee' built in Uncommitted tee utility with GNU
> extensions
> ksh93 '/usr/gnu/bin/tty' built in Uncommitted tty utility with GNU
> extensions
> ksh93 '/usr/gnu/bin/uniq' built in Uncommitted uniq utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/rmdir' built in Uncommitted rmdir utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/wc' built in Uncommitted wc 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.
>>
>> For several paths on the system, customers expect certain behaviour
>> /usr/xpg4 XPG4 compatible behaviour
>> /usr/xpg6 XPG6 compatible behaviour
>> /usr/gnu GNU/Linux compatible behaviour
>> /usr/ucb SunOS/BSD 4.X behaviour
>> /usr/5bin SVR3 compatible behaviour
>> ...
>
>
> 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.
-Norm
