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 11:18:25AM -0700, John Plocher wrote:
> 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
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
Bart Smaalders wrote:
> On 03/24/10 08:47, Joerg Schilling wrote:
>
> > And BTW: I don't like to depend on a program that still comes with bugs that
> > have been accepted as bugs by it's maintainers in 1998.
>
> The Solaris versions you know and love have many bugs filed against
> them, lots of
Darren Reed wrote:
> > POSIX is a pretty low bar. Heck, even Minix and VxWorks and some
> > variants of Windows meet it. What you're saying appears to be quite
> > incendiary, and rather a slap at the folks who worked on ZFS.
> >
> > Are you sure?
> >
>
> http://docs.sun.com/app/docs/doc/82
On 24/03/2010 17:04, Stefan Teleman wrote:
> Garrett D'Amore wrote:
>
>> The community has the ability to take those modifications, apply
>> further modifications, or create a new "head of tree" (essentially a
>> code fork). For example, Nexenta ships with a totally different userland.
>
> Which us
John Plocher wrote:
> On Mon, Mar 22, 2010 at 7:21 PM, Garrett D'Amore wrote:
> > Again, I can't talk about the rationale for the bits that are closed being
> > so.
>
>
> It is pretty clear that the reason it is closed is because Oracle
> feels the features, internal build coordination and confi
"Garrett D'Amore" wrote:
> I don't mean for that at all. But the change of the default path is
> being handled as part of PSARC 2010/067 -- i.e. that is the case (and
> its still open) that started this whole mess. I'm not a fan of the fact
> that the case is closed, but I cannot discuss rat
"Garrett D'Amore" wrote:
> > "make"?
> >
>
> Yes, GNU make, which behaves in a fashion totally unlike Sun make.
> (Admittedly Sun make is in /usr/ccs/bin, not in /usr/gnu.)
Let me also mention that GNU make implements a makefile parser that
is not compatible with the POSIX standard. White
Milan Jurik wrote:
> In case that /usr/gnu would not hide Solaris specific features like it
> is doing today, it is good solution probably. The problem is
> that /usr/gnu is doing that (e.g. ACLs or linker). It is broken
> architecture to hide significant features. Additionally it is big pain
> f
On 24/03/10 01:00 PM, Bart Smaalders wrote:
> On 03/24/10 08:47, Joerg Schilling wrote:
>
>> And BTW: I don't like to depend on a program that still comes with
>> bugs that
>> have been accepted as bugs by it's maintainers in 1998.
>
> The Solaris versions you know and love have many bugs filed ag
Garrett D'Amore wrote:
> The community has the ability to take those modifications, apply further
> modifications, or create a new "head of tree" (essentially a code
> fork). For example, Nexenta ships with a totally different userland.
Which userland does Nexenta ship ?
--Stefan
--
Stefan
On 03/24/10 08:47, Joerg Schilling wrote:
> And BTW: I don't like to depend on a program that still comes with bugs that
> have been accepted as bugs by it's maintainers in 1998.
The Solaris versions you know and love have many bugs filed against
them, lots of them more than merely 12 years old.
Darren Reed wrote:
> I'm led to believe that OpenSolaris won't pass the testing required to
> be labelled Unix (the problems start with ZFS: there are parts of it
> that aren't POSIX compliant) and as far as I know, nobody is interested
> in doing so. This has been known for quite some time. I
On 24/03/10 04:26 AM, James Carlson wrote:
> Darren Reed wrote:
>
>> Octave,
>>
>> I'm led to believe that OpenSolaris won't pass the testing required to
>> be labelled Unix (the problems start with ZFS: there are parts of it
>> that aren't POSIX compliant) and as far as I know, nobody is inter
John Plocher wrote:
> Worse yet (this is no surprise to most, I'm sure, but pity our poor users...):
>
> On your new OpenSolaris system, create a tar archive of, say, your web
> document root that you want to move over to another system: cd
> /export/website; tar cf ~/mywebsite.tar .
Let me add
On 03/24/10 10:04 AM, Stefan Teleman wrote:
> Garrett D'Amore wrote:
>
>> The community has the ability to take those modifications, apply
>> further modifications, or create a new "head of tree" (essentially a
>> code fork). For example, Nexenta ships with a totally different
>> userland.
>
>
On 03/24/10 08:57 AM, Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>
>> I don't mean for that at all. But the change of the default path is
>> being handled as part of PSARC 2010/067 -- i.e. that is the case (and
>> its still open) that started this whole mess. I'm not a fan of the fa
Darren Reed wrote:
> Octave,
>
> I'm led to believe that OpenSolaris won't pass the testing required to
> be labelled Unix (the problems start with ZFS: there are parts of it
> that aren't POSIX compliant) and as far as I know, nobody is interested
> in doing so. This has been known for quite some
oopersmith at sun.com
Sent: Wed, March 24, 2010 6:15:30 AM
Subject: Re: More ksh93 builtins
Darren Reed wrote:
> I'm led to believe that OpenSolaris won't pass the testing required to
> be labelled Unix (the problems start with ZFS: there are parts of it
> that aren't POS
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>>
>>
>>
>> - Original Message
>> From: Jason King
>> To: John Plocher
>> Cc: Alan Coopersmith; Garrett
>> D'Amore; shell-discuss at opensolaris.org; PSARC-ext at
>> sun.co
On Tue, Mar 23, 2010 at 7:55 PM, John Plocher wrote:
> On Tue, Mar 23, 2010 at 4:47 PM, Darren Reed wrote:
>>
>> Enjoy (the fact that S10 does not have bash or /usr/gnu or ...).
>
>
> Worse yet (this is no surprise to most, I'm sure, but pity our poor users...):
>
> On your new OpenSolaris system
sun.com; Milan
> Jurik; johansen at sun.com; Darren Reed at sun.com>
> Sent: Tue, March 23, 2010 9:39:27 PM
> Subject: Re: More ksh93 builtins
>
> On Tue, Mar 23, 2010 at 7:55 PM, John Plocher
> wrote:
>
>> On Tue, Mar 23, 2010 at 4:47 PM, Darren Reed wrote:
ohansen at sun.com; Darren Reed
Sent: Tue, March 23, 2010 9:39:27 PM
Subject: Re: More ksh93 builtins
On Tue, Mar 23, 2010 at 7:55 PM, John Plocher wrote:
> On Tue, Mar 23, 2010 at 4:47 PM, Darren Reed wrote:
>>
>> Enjoy (the fact that S10 does not have bash or /usr/gnu or ...).
&g
John Plocher wrote:
> On Tue, Mar 23, 2010 at 4:47 PM, Darren Reed wrote:
>> Enjoy (the fact that S10 does not have bash or /usr/gnu or ...).
I don't see that line in Darren's original mail - did you add that commentary?
It's incorrect if so, since bash was added in Solaris 8 with tcsh and gzip,
On Tue, Mar 23, 2010 at 4:47 PM, Darren Reed wrote:
>
> Enjoy (the fact that S10 does not have bash or /usr/gnu or ...).
Worse yet (this is no surprise to most, I'm sure, but pity our poor users...):
On your new OpenSolaris system, create a tar archive of, say, your web
document root that you w
On 22/03/10 10:03 AM, Alan Coopersmith wrote:
> Darren Reed wrote:
>
>> What the default path, in /etc/default and elsewhere, really
>> impact are things like:
>> - install scripts (that don't use ~/.foo)
>> - how scripts run remotely when ~/.foo isn't read
>> - at/cron jobs
>> - other uses of
Hi,
Alan Coopersmith p??e v ?t 23. 03. 2010 v 00:24 -0700:
> Milan Jurik wrote:
> > You ignored the rest of the e-mail, skipping arguments. Yes, you can
> > consider those arguments as non-sense but it is fair to say it openly in
> > discussion.
>
> Because it's still pointless. No amount of ar
*-*-*-*
>
>
>
> - Original Message
> From: Milan Jurik
> To: Nicolas Williams
> Cc: shell-discuss at opensolaris.org; Garrett D'Amore;
> PSARC-ext at sun.com; Darren Reed
> Sent: Tue, March 23, 2010 1:43:28 AM
> Subject: Re: More ksh93 builtins
>
Hi Alan,
Alan Coopersmith p??e v po 22. 03. 2010 v 23:52 -0700:
> Milan Jurik wrote:
> > Still GNU ls is in system. Why?
>
> Because users want it and removing it from the system serves no one.
>
Which users? Those which checks that ls --help will return them "Yes, it
is our sacred tool"? Ther
Hi Nico,
Nicolas Williams p??e v po 22. 03. 2010 v 12:08 -0500:
> On Mon, Mar 22, 2010 at 09:46:27AM -0700, Darren Reed wrote:
> > On 22/03/10 07:21 AM, Alan Coopersmith wrote:
> > >Milan Jurik wrote:
> > >>Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700:
> > >>>Garrett D'Amore wrote:
> > >>
- Original Message
From: Milan Jurik
To: Nicolas Williams
Cc: shell-discuss at opensolaris.org; Garrett D'Amore ;
PSARC-ext at sun.com; Darren Reed
Sent: Tue, March 23, 2010 1:43:28 AM
Subject: Re: More ksh93 builtins
Hi Nico,
Nicolas Williams p??e v po 22. 03. 2010 v 12:0
> On Mon, Mar 22, 2010 at 9:53 PM, Neal Pollack
> wrote:
> > If "welcome here" is PSARC
>
> No, it is the OpenSolaris ARC community alias, which
> PSARC-ext feeds into.
>
> I don't really care what goes on inside the
> proprietary PSARC at sun.com
> as it reviews closed cases - as long as the re
Milan Jurik wrote:
> You ignored the rest of the e-mail, skipping arguments. Yes, you can
> consider those arguments as non-sense but it is fair to say it openly in
> discussion.
Because it's still pointless. No amount of arguments will add up to
making it worthwhile or likely that /usr/gnu/bin/
Milan Jurik wrote:
> Still GNU ls is in system. Why?
Because users want it and removing it from the system serves no one.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Oracle Solaris Platform Engineering: X Window System
On Mon, Mar 22, 2010 at 9:53 PM, Neal Pollack wrote:
> If "welcome here" is PSARC
No, it is the OpenSolaris ARC community alias, which PSARC-ext feeds into.
I don't really care what goes on inside the proprietary PSARC at sun.com
as it reviews closed cases - as long as the results of those close
John Plocher wrote:
> On Mon, Mar 22, 2010 at 7:21 PM, Garrett D'Amore wrote:
>> Again, I can't talk about the rationale for the bits that are closed being
>> so.
>
>
> It is pretty clear that the reason it is closed is because Oracle
> feels the features, internal build coordination and configu
On Mon, Mar 22, 2010 at 7:21 PM, Garrett D'Amore wrote:
> Again, I can't talk about the rationale for the bits that are closed being
> so.
It is pretty clear that the reason it is closed is because Oracle
feels the features, internal build coordination and configuration of
their own distro (Open
On 03/22/10 04:04 PM, Don Cragun wrote:
> On Mar 22, 2010, at 10:20:20 -0700, Garrett D'Amore wrote:
>
>
>> On 03/22/10 10:03 AM, Alan Coopersmith wrote:
>>
>>> Darren Reed wrote:
>>>
>>>
What the default path, in /etc/default and elsewhere, really
impact are things like
getconf PATH adds the POSIX and SUS tools in front of /usr/bin and
includes development tools from /opt/SUNWspro/bin and /usr/ccs/bin.
IMO all good things and certainly better than PATH=/usr/bin alone.
Many utilities in /usr/bin are utterly unable to handle Cyrillic,
including Ukrainian while the t
On Mar 22, 2010, at 10:20:20 -0700, Garrett D'Amore wrote:
> On 03/22/10 10:03 AM, Alan Coopersmith wrote:
>> Darren Reed wrote:
>>
>>> What the default path, in /etc/default and elsewhere, really
>>> impact are things like:
>>> - install scripts (that don't use ~/.foo)
>>> - how scripts run remo
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
+-- "Garrett D'Amore" wrote (Mon, 22-Mar-2010, 09:56 -0700):
|
| Yes, it impacts those. And maybe others! But we shouldn't be having
| this debate. If the default PATH provides reasonable values, then we
| won't have to deal with this kind of problem worrying about pre-existing
| user en
On Mon, Mar 22, 2010 at 10:43:34AM -0700, Garrett D'Amore wrote:
> On 03/22/10 10:30 AM, Nicolas Williams wrote:
> >On Mon, Mar 22, 2010 at 10:22:08AM -0700, Garrett D'Amore wrote:
> >>On 03/22/10 10:08 AM, Nicolas Williams wrote:
> >>>I don't understand the sturm un drang over the /usr/gnu/bin-fir
On Mon, Mar 22, 2010 at 10:22:08AM -0700, Garrett D'Amore wrote:
> On 03/22/10 10:08 AM, Nicolas Williams wrote:
> >I don't understand the sturm un drang over the /usr/gnu/bin-first-in-
> >default-PATH thing. It's a NON-ISSUE (except for GNU tools like ls and
> >chmod where lack of support for Sol
On Mon, Mar 22, 2010 at 09:46:27AM -0700, Darren Reed wrote:
> On 22/03/10 07:21 AM, Alan Coopersmith wrote:
> >Milan Jurik wrote:
> >>Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700:
> >>>Garrett D'Amore wrote:
> I'm also of the opinion that it is a mistake to sacrifice familiarity
> >>>
On 03/22/10 10:30 AM, Nicolas Williams wrote:
> On Mon, Mar 22, 2010 at 10:22:08AM -0700, Garrett D'Amore wrote:
>
>> On 03/22/10 10:08 AM, Nicolas Williams wrote:
>>
>>> I don't understand the sturm un drang over the /usr/gnu/bin-first-in-
>>> default-PATH thing. It's a NON-ISSUE (excep
On 03/22/10 10:08 AM, Charles Seeger wrote:
> +-- "Garrett D'Amore" wrote (Mon, 22-Mar-2010, 09:56 -0700):
> |
> | Yes, it impacts those. And maybe others! But we shouldn't be having
> | this debate. If the default PATH provides reasonable values, then we
> | won't have to deal with this kin
On 03/22/10 10:08 AM, Nicolas Williams wrote:
> On Mon, Mar 22, 2010 at 09:46:27AM -0700, Darren Reed wrote:
>
>> On 22/03/10 07:21 AM, Alan Coopersmith wrote:
>>
>>> Milan Jurik wrote:
>>>
Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700:
> Garrett D'
On 03/22/10 10:03 AM, Alan Coopersmith wrote:
> Darren Reed wrote:
>
>> What the default path, in /etc/default and elsewhere, really
>> impact are things like:
>> - install scripts (that don't use ~/.foo)
>> - how scripts run remotely when ~/.foo isn't read
>> - at/cron jobs
>> - other uses of
Darren Reed wrote:
> What the default path, in /etc/default and elsewhere, really
> impact are things like:
> - install scripts (that don't use ~/.foo)
> - how scripts run remotely when ~/.foo isn't read
> - at/cron jobs
> - other uses of $SHELL where ~/.foo isn't read
And notably, that path hasn'
On 03/22/10 09:46 AM, Darren Reed wrote:
> On 22/03/10 07:21 AM, Alan Coopersmith wrote:
>> Milan Jurik wrote:
>>> Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700:
Garrett D'Amore wrote:
> I'm also of the opinion that it is a mistake to sacrifice familiarity
> for our paying Sola
On 22/03/10 07:21 AM, Alan Coopersmith wrote:
> Milan Jurik wrote:
>
>> Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700:
>>
>>> Garrett D'Amore wrote:
>>>
I'm also of the opinion that it is a mistake to sacrifice familiarity
for our paying Solaris 10 customers in f
Milan Jurik wrote:
> Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700:
>> Garrett D'Amore wrote:
>>> I'm also of the opinion that it is a mistake to sacrifice familiarity
>>> for our paying Solaris 10 customers in favor of familiarity for people
>>> coming from Linux.
>> But clearly all our
Hi,
Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700:
> [Removed the case id, since this is off-topic for the case which isn't
> currently
> on the table for discussion anyway.]
>
Good idea.
> Garrett D'Amore wrote:
> > I'm also of the opinion that it is a mistake to sacrifice familiarit
Hi,
johansen at sun.com p??e v p? 19. 03. 2010 v 15:52 -0700:
> 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* partic
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
- Original Message
From: Milan Jurik
To: Alan Coopersmith
Cc: PSARC-ext at sun.com; Garrett D'Amore ; shell-discuss
at opensolaris.org
Sent: Sat, March 20, 2010 10:34:44 AM
Subject: Re: More ksh93 builtins
Hi,
Alan Coopersmith p??e v p? 19. 0
[Removed the case id, since this is off-topic for the case which isn't currently
on the table for discussion anyway.]
Garrett D'Amore wrote:
> I'm also of the opinion that it is a mistake to sacrifice familiarity
> for our paying Solaris 10 customers in favor of familiarity for people
> coming fr
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
rmation 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 Document:
> 18 March, 2010
> 4. Technic
>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 bui
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 bui
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
1 - 100 of 116 matches
Mail list logo
