On 03/29/2010 07:18 PM, John Plocher wrote:
> The architectural point is that the user/admin needs control of things
> like this; with ksh93 builtins, they have that ability (i.e., they can
> turn builtins off...) and update binutils packages and the like.
I'm suggesting that with better architect
On Mon, Mar 29, 2010 at 8:42 AM, Nicolas Williams
wrote:
> If you replace programs delivered by Solaris itself they you've rendered
> your system unsupportable and, indeed, we will not support it.
That may be true of Oracle's commercial Solaris Product, but we are
talking about OpenSolaris here.
On Sat, Mar 27, 2010 at 05:02:45PM +, Jeremy Harris wrote:
> Unfortunately, the cache invalidation and/or reload is also the latter
> time. I think this is a mistake. If I, with suitable permissions, cannot
> replace the binary of a utility in the filesystem of my system and
> get the expecte
On 03/27/2010 03:39 PM, Chris Pickett wrote:
> On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat
> wrote:
>> What benefit does this case bring ?
>
> First at all you do not go through fork() and be a lot faster.
The intent appears to be better performance; generally a good thing.
I'm concerned ab
On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat
wrote:
> Maybe I don't understand enough about ksh93 (since I'm a zsh user for
> interactive shell work) but I don't understand what this case is about.
>
> What benefit does this case bring ?
First at all you do not go through fork() and be a lot
On Thu, Mar 18, 2010 at 5:52 PM, Garrett D'Amore wrote:
> On 03/18/10 09:37 AM, Peter Tribble wrote:
> I have a couple of opinions about all this, which I'll restate here:
>
> 1) In an ideal world, we'd supply (by "default") a single implementation of
> these commands. It seems like ksh93 is the
On Thu, Mar 18, 2010 at 5:37 PM, Peter Tribble
wrote:
> On Thu, Mar 18, 2010 at 3:41 PM, Darren J Moffat
> wrote:
>>
>> Why would I want to use ksh93 builtins if I have /usr/gnu/bin explicitly in
>> my path ? Are the ksh93 builtin versions 100% compatible in all respects
>> with the GNU ones ?
On Fri, Mar 19, 2010 at 4:30 PM, Garrett D'Amore wrote:
> On 03/19/10 08:27 AM, Glenn Fowler wrote:
>>
>> On Fri, 19 Mar 2010 08:13:48 -0700 Garrett D'Amore wrote:
>>
>>>
>>> I am coming to agree. While I'm the sponsor on this case, I'm on the
>>> verge of derailing this case and asking that a ne
On Sat, Mar 20, 2010 at 12:26 AM, wrote:
> On Fri, Mar 19, 2010 at 04:08:09PM -0700, Garrett D'Amore wrote:
>> I'd rather see us modernize our own tools. I resent abdication of
>> our own engineering, and the necessity of abandoning all good
>> innovations (like shell builtins) because some peop
On Sat, Mar 20, 2010 at 2:58 AM, Jason King wrote:
> On Fri, Mar 19, 2010 at 5:26 PM, wrote:
>> On Fri, Mar 19, 2010 at 04:08:09PM -0700, Garrett D'Amore wrote:
>>> I'd rather see us modernize our own tools. I resent abdication of
>>> our own engineering, and the necessity of abandoning all goo
On Sat, Mar 20, 2010 at 12:56 AM, Alan Coopersmith
wrote:
> Garrett D'Amore wrote:
>> I really do think that the way this was handled in OpenSolaris -- which
>> occurred without any significant ARC discussion of the concerns
>> surrounding this -- is unfortunate. I am half tempted to bring forwar
On Fri, Mar 19, 2010 at 04:08:09PM -0700, Garrett D'Amore wrote:
> I'd rather see us modernize our own tools. I resent abdication of
> our own engineering, and the necessity of abandoning all good
> innovations (like shell builtins) because some people feel its
> critical that the only way to achi
On 03/19/10 03:52 PM, johansen at sun.com wrote:
> On Fri, Mar 19, 2010 at 08:13:48AM -0700, Garrett D'Amore wrote:
>
>> The fact that we have to put /usr/gnu at the head of $PATH of new
>> users is a bit of a travesty, and I'm of the opinion that we should
>> reexamine *that* particular decisi
On Fri, Mar 19, 2010 at 08:13:48AM -0700, Garrett D'Amore wrote:
> The fact that we have to put /usr/gnu at the head of $PATH of new
> users is a bit of a travesty, and I'm of the opinion that we should
> reexamine *that* particular decision...
This is merely one opinion. There are compelling bus
On Fri, 19 Mar 2010 08:13:48 -0700 Garrett D'Amore wrote:
> I am coming to agree. While I'm the sponsor on this case, I'm on the
> verge of derailing this case and asking that a new case to examine
> userland shell architecture be created. The fact that we have to put
> /usr/gnu at the head o
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 exten
On 03/19/10 08:13, Garrett D'Amore wrote:
> I'd rather see ksh93 based utilities (or rather libcmd based) with all
> the bells and whistles delivered into /usr/bin or perhaps /usr/ksh93/bin
> (and put at the head of $PATH) and leave /usr/gnu as a dumping ground
> for people who insist that they wa
On 03/19/10 08:27 AM, Glenn Fowler wrote:
> On Fri, 19 Mar 2010 08:13:48 -0700 Garrett D'Amore wrote:
>
>> I am coming to agree. While I'm the sponsor on this case, I'm on the
>> verge of derailing this case and asking that a new case to examine
>> userland shell architecture be created. The
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
On 03/19/10 07:58 AM, Norm Jacobs wrote:
>
>> 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,
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
On 18/03/2010 23:57, Norm Jacobs wrote:
> 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 behavio
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
I'm not a member of PSARC and can't actually vote here, but I would have
to give this case a -1.
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 sore
>the fix to disable builtins for pfksh is only a few lines
>dgk and I are checking out the code now
>
>there is another alternative if we can pfexec bracket sections of code inline
>I beleieve a message yesterday, about 1000 posts ago:) mentioned this is
>possible
>e.g., for the builtin b_mkdir(
>On 18/03/2010 16:38, Garrett D'Amore wrote:
>> On 03/18/10 09:28 AM, Casper.Dik at Sun.COM wrote:
>>>
Architecturally, I have to agree with Darren here. I don't know what
the concerns are here where this would fail to operate with the current
pfexec... I thought that it was just th
>Architecturally, I have to agree with Darren here. I don't know what
>the concerns are here where this would fail to operate with the current
>pfexec... I thought that it was just the case that pfexec would bypass
>the builtin and use the filesystem supplied binary.
That is not currently th
>That said, its possible that the GNU tools will evolve in the future, at
>a rate differently than the ksh93 versions do. (At that point, the case
>says that the ksh93 version will either be adapted, or they'll stop
>supplying the built-in.)
And, unfortunately, anyone who wants to deploy a n
On Thu, Mar 18, 2010 at 5:09 PM, Darren J Moffat
wrote:
>
>
> On 18/03/2010 15:58, Jennifer Pioch wrote:
>>
>> On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat
>> wrote:
>>>
>>> Maybe I don't understand enough about ksh93 (since I'm a zsh user for
>>> interactive shell work) but I don't understa
On Thu, Mar 18, 2010 at 4:24 PM, Garrett D'Amore - sun microsystems
wrote:
>
> Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI
> This information is Copyright 2010 Sun Microsystems
> 1. Introduction
>1.1. Project/Component Working Name:
> More ksh93 builtins
>1.2. Name of Docu
Which policy, which tools? Could you please a bit clearer?
Jenny
On Thu, Mar 18, 2010 at 4:53 PM, 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 co
On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat
wrote:
> Maybe I don't understand enough about ksh93 (since I'm a zsh user for
> interactive shell work) but I don't understand what this case is about.
>
> What benefit does this case bring ?
One advantage is MUCH HIGHER performance. A simple loop
On 18/03/2010 16:38, Garrett D'Amore wrote:
> On 03/18/10 09:28 AM, Casper.Dik at Sun.COM wrote:
>>
>>> Architecturally, I have to agree with Darren here. I don't know what
>>> the concerns are here where this would fail to operate with the current
>>> pfexec... I thought that it was just the cas
On Thu, Mar 18, 2010 at 3:41 PM, Darren J Moffat
wrote:
>
> Why would I want to use ksh93 builtins if I have /usr/gnu/bin explicitly in
> my path ? ?Are the ksh93 builtin versions 100% compatible in all respects
> with the GNU ones ?
No. It's explicitly stated that --version in particular is word
On 18/03/2010 16:28, Casper.Dik at sun.com wrote:
>
>
>> Architecturally, I have to agree with Darren here. I don't know what
>> the concerns are here where this would fail to operate with the current
>> pfexec... I thought that it was just the case that pfexec would bypass
>> the builtin and us
On Thu, Mar 18, 2010 at 3:24 PM, Garrett D'Amore - sun microsystems
wrote:
>
> Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI
> This information is Copyright 2010 Sun Microsystems
> 1. Introduction
> ? ?1.1. Project/Component Working Name:
> ? ? ? ? More ksh93 builtins
> ? ?1.2. Name of Docu
On 18/03/2010 15:58, Jennifer Pioch wrote:
> On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat
> wrote:
>> Maybe I don't understand enough about ksh93 (since I'm a zsh user for
>> interactive shell work) but I don't understand what this case is about.
>>
>> What benefit does this case bring ?
>
Maybe I don't understand enough about ksh93 (since I'm a zsh user for
interactive shell work) but I don't understand what this case is about.
What benefit does this case bring ?
How does this interact with PSARC/2009/377 in kernel pfexec, maybe it
doesn't need to and that is an okay answer, whe
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 w
On Thu, 18 Mar 2010 17:51:26 +0100 Casper.Dik at sun.com wrote:
> >the fix to disable builtins for pfksh is only a few lines
> >dgk and I are checking out the code now
> >
> >there is another alternative if we can pfexec bracket sections of code inline
> >I beleieve a message yesterday, about 1000
On Thu, 18 Mar 2010 09:38:17 -0700 Garrett D'Amore wrote:
> On 03/18/10 09:28 AM, Casper.Dik at Sun.COM wrote:
> >
> >
> >> Architecturally, I have to agree with Darren here. I don't know what
> >> the concerns are here where this would fail to operate with the current
> >> pfexec... I though
userland command name conflict resolution is handled
by crafting PATH around the conflicts and user preferences
ksh93 builtins can also be pluguins located in shared-libs/dlls
and plugin lookup can be interspersed with PATH lookup
if /usr/gnu/bin is searched before a plugin containing a grep buil
Garrett D'Amore wrote:
> 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
>> p
I believe I was very clear.
--Stefan
Jennifer Pioch wrote:
> Which policy, which tools? Could you please a bit clearer?
>
> Jenny
>
> On Thu, Mar 18, 2010 at 4:53 PM, Stefan Teleman
> wrote:
>> This project raises a concern in my mind with respect to a very old and
>> generally accepted
On 03/18/10 10:53, Garrett D'Amore wrote:
> I'm actually of the opinion that this entire case, along with the
> /usr/gnu situation, is a mess, and we should go back to the drawing
> board (so to speak) and address the more significant concerns that are
> the root cause for this case (in particular
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".
B
On Thu, Mar 18, 2010 at 04:58:39PM +0100, Jennifer Pioch wrote:
> On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat
> wrote:
> > Maybe I don't understand enough about ksh93 (since I'm a zsh user for
> > interactive shell work) but I don't understand what this case is about.
> >
> > What benefit doe
I have two arguments against this.
1) GNU tools are sometimes more flexible (you can do a lot with one command,
something which is quite tricky with Solaris tools.)
E.g.:
- grep -r something somewhere
- find -print0 (without it its' difficult to deal with files with complex
paths)
- xargs -0
On 03/18/10 10:45 AM, Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>
>> On 03/18/10 08:58 AM, Alan Coopersmith wrote:
>>
>>> Garrett D'Amore - sun microsystems wrote:
>>>
>>>
Compatibility between ksh93 built in utility implementation and GNU
coreutils implementation
Garrett D'Amore wrote:
> On 03/18/10 08:58 AM, Alan Coopersmith wrote:
>> Garrett D'Amore - sun microsystems wrote:
>>
>>> Compatibility between ksh93 built in utility implementation and GNU
>>> coreutils implementation:
>>> Should a future ARC case will add new features to the GNU coreutils
>>>
Jennifer Pioch wrote:
> Why? The majority in the discussion already said that this is not a
> bug in ksh93. Why should this case wait for something which is not a
> bug?
A majority of people who don't know what profile shells are or how they
are used is not relevant - even if they did, bugs are no
On 03/18/10 09:41 AM, Darren J Moffat wrote:
>
>
> On 18/03/2010 16:38, Garrett D'Amore wrote:
>> On 03/18/10 09:28 AM, Casper.Dik at Sun.COM wrote:
>>>
Architecturally, I have to agree with Darren here. I don't know what
the concerns are here where this would fail to operate with the
>>
On 03/18/10 09:37 AM, Peter Tribble wrote:
> On Thu, Mar 18, 2010 at 3:41 PM, Darren J Moffat
> wrote:
>
>> Why would I want to use ksh93 builtins if I have /usr/gnu/bin explicitly in
>> my path ? Are the ksh93 builtin versions 100% compatible in all respects
>> with the GNU ones ?
>>
On 03/18/10 09:28 AM, Casper.Dik at Sun.COM wrote:
>
>
>> Architecturally, I have to agree with Darren here. I don't know what
>> the concerns are here where this would fail to operate with the current
>> pfexec... I thought that it was just the case that pfexec would bypass
>> the builtin and
On 03/18/10 09:21 AM, Stefan Teleman wrote:
>
> The issue is that there are now 4 different grep's in Solaris, and
> that the shell can pick a different one from the one i explicitly
> chose by setting my PATH. I find that having 4 different greps is
> excessive, and very difficult to justify ar
On 03/18/10 09:09 AM, Darren J Moffat wrote:
>
>
>> ksh93-integration-discuss@ currently has an ongoing discussion about
>> this and the broken profile shell concept. There are two concurrent
>> proposals to integrate the concepts of shell builtins and profile
>> shells.
>
> Then this case should b
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 repla
On 03/18/10 08:58 AM, Alan Coopersmith wrote:
> Garrett D'Amore - sun microsystems wrote:
>
>> Compatibility between ksh93 built in utility implementation and GNU
>> coreutils implementation:
>> Should a future ARC case will add new features to the GNU coreutils
>> utilities the project team wi
On 03/18/10 08:41 AM, Darren J Moffat wrote:
> Maybe I don't understand enough about ksh93 (since I'm a zsh user for
> interactive shell work) but I don't understand what this case is about.
>
> What benefit does this case bring ?
(Note: I'm not the project team, just the ARC sponsor. They may h
Garrett D'Amore - sun microsystems wrote:
> Compatibility between ksh93 built in utility implementation and GNU
> coreutils implementation:
> Should a future ARC case will add new features to the GNU coreutils
> utilities the project team will update the corresponding ksh93 built
> in utility. Shou
Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI
This information is Copyright 2010 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
More ksh93 builtins
1.2. Name of Document Author/Supplier:
Author: Olga Kryzhanovska
1.3 Date of This Docume
61 matches
Mail list logo
