On 03/18/10 08:53 AM, Stefan Teleman wrote:
> This project raises a concern in my mind with respect to a very old
> and generally accepted UNIX architectural principle:
>
> "Tools, Not Policy".
>
> If i understand it correctly, this case effectively vacates the
> principle stated above, and replaces it with its exact opposite:
>
> "Policy, Not Tools".
>
> Because the only possible rationale for having /usr/gnu/bin/grep
> transparently and silently replaced by a shell builtin grep is as a
> result of some mandatory policy in effect, which would trump explicit
> user selection.
>
> It would be very helpful if the project team would kindly explain how
> it intends to address the architectural concern above, and also how it
> intends to mitigate the proliferation of userland commands with
> identical names, but providing, in many cases, different semantics.
Users can override the policy and disable the builtins if they so
choose. They could also choose another shell instead of ksh93 -- these
changes don't apply to bash or tcsh or zsh.
I guess I don't really understand the objection -- the builtin behaves
the same way, but performs better. What's the issue? (We've do this
with other subsystems in the past, such as in-kernel accelerations for
SSL, HTTP, etc. These all provide a behind the scenes "improvement"
using an alternate implementation.)
- Garrett
>
> Thank you.
>
> --Stefan
>
> ------
>
> Garrett D'Amore - sun microsystems wrote:
>
>> This project is an amendment to the Korn Shell 93 Integration project
>> (PSARC/2006/550 and PSARC/2007/035, PSARC/2008/094, PSARC/2008/344
>> and PSARC/2008/589) specifying the following additional
>> interfaces:
>> Addition of /usr/gnu/bin, /usr/xpg4/bin and /usr/bin built in
>> mappings in ksh93
>
>
>
