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 behaviour
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
.
Thanks,
Danek
Thanks,
I will change it to pkg:/library/libgdata
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: libgdata.txt
URL:
http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20100319/c101356d/attachment.txt
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
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
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, which is
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 of
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 fact
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 want
The timer has passed, there was at least one +1, there are no open
issues and nobody derailed, so I am marking this closed approved.
On 03/11/10 11:23, Brian Utterback wrote:
I am sponsoring this fasttrack on behalf of Lukas Rovensky. Binding is patch.
Time
out is 03/18/2010.
Template
http://hub.opensolaris.org/bin/edit/Community+Group+arc/ARCAgenda/
= OpenSolaris ARC Agenda
= TELECONFERENCE NUMBERS:
(866)545-5223 (Within US)
(215)446-3661 (International)
ACCESS CODE 939-55-86
Times are US/Pacific Timezone
ARC meetings are recorded.
03/24/2010
10 minutes Open
http://hub.opensolaris.org/bin/edit/Community+Group+arc/ARCAgenda/
= OpenSolaris ARC Agenda
= TELECONFERENCE NUMBERS:
(866)545-5223 (Within US)
(215)446-3661 (International)
ACCESS CODE 939-55-86
Times are US/Pacific Timezone
ARC meetings are recorded.
03/24/2010
10 minutes Open
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:
idmap: default unresolvable SID mapping to true
1.2. Name of Document Author/Supplier:
Author: Jordan Brown
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
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 decision...
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 achieve
[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 from
17 matches
Mail list logo
