From gd78059@sac.sfbay.sun.com Thu Mar 18 08:25:00 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IFP0EL021266 for ; Thu, 18 Mar 2010 08:25:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IFOxuu054253; Thu, 18 Mar 2010 09:25:00 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00H0RHHN1J00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Mar 2010 08:24:59 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00E70HHNIU60@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Mar 2010 08:24:59 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IFOwYd003728; Thu, 18 Mar 2010 08:24:58 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IFOvMu021261; Thu, 18 Mar 2010 08:24:57 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o2IFOvCI021257; Thu, 18 Mar 2010 08:24:57 -0700 (PDT) Date: Thu, 18 Mar 2010 08:24:57 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] To: PSARC-ext@sun.com Cc: olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6862 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 Document: 18 March, 2010 4. Technical Description I'm sponsoring this fast-track request on behalf of the ksh93-integration project. Please note that this is an *open* case. The release binding is the same as with the ksh93 project: a patch/micro release of Solaris delivering through ON Stability levels are as described below. 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 Bug/RFE Number(s): 6935110 ksh93 needs (more) XPG, GNU built ins This case proposes to deliver the following features as a set of independent putbacks as they become available. Each feature is self contained and independent of the others, so out of order and partial putbacks at this granularity should have no adverse impact on the functionality and behavior of the system as a whole. 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. 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 Notes ----- Compatibility of AT&T AST ksh93 built in utilities and GNU coreutils implementations: Modulo correction bugs in the implementation, we believe that the ksh93 built in utilities act as a 100% compatible drop in for the GNU programs sans wording of --help, --version and error message output (error messages are Not-An-Interface). 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. Should this not be possible the ksh93 project team will remove the mapping. Part 2: ksh93 built in mappings for /usr/xpg4/bin utilities ---------------------------------------------------------- The case proposes to enable the following mappings to ksh93 built in commands for utilities in /usr/xpg4/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/xpg4/bin binary. Interface Stability Description --------- --------- ----------- ksh93 '/usr/xpg4/bin/basename' built in Committed POSIX basename utility ksh93 '/usr/xpg4/bin/egrep' built in Committed POSIX egrep utility ksh93 '/usr/xpg4/bin/fgrep' built in Committed POSIX fgrep utility ksh93 '/usr/xpg4/bin/grep' built in Committed POSIX grep utility ksh93 '/usr/xpg4/bin/id' built in Committed POSIX id utility ksh93 '/usr/xpg4/bin/rm' built in Committed POSIX rm utility Part 3: ksh93 built in mappings for /usr/bin utilities ---------------------------------------------------------- The case proposes to enable the following mappings to ksh93 built in commands for utilities in /usr/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/xpg4/bin binary. Interface Stability Description --------- --------- ----------- ksh93 '/usr/bin/dirname' built in Committed POSIX dirname utility General comments ---------------- This case heavily builds on PSARC/2006/550 which was the first PSARC case to introduce the concept of shell built ins bound to a path. Future development ------------------ The shell project team will file separate ARC case to add the same shell built ins to bash4, reusing the same code as ksh93 (libcmd.so.1). The shell project will provide an API within libcmd.so.1 for other shells (e.g. bash4) and applications to call the built ins directly. This API will be available as contracted API until sufficient experience has been collected and then opened as Committed interface. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From darrenm@opensolaris.org Thu Mar 18 08:41:42 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IFfgGp021755 for ; Thu, 18 Mar 2010 08:41:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IFfeeT020405 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 10:41:42 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00H1VI9HXT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 08:41:41 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00EXZI9GIU70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 08:41:40 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IFfelA028681; Thu, 18 Mar 2010 15:41:40 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2HKLrBY028383; Thu, 18 Mar 2010 15:41:37 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 92298111268926868; Thu, 18 Mar 2010 08:41:08 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Mar 2010 08:41:08 -0700 Date: Thu, 18 Mar 2010 15:41:05 +0000 From: Darren J Moffat Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA24991.5080201@opensolaris.org> Organization: OpenSolaris MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BA249B2.003E,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 586 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, when ksh93 is the profile shell ? 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 ? If so then I wonder why we are even shipping the GNU ones. -- Darren J Moffat From stefan.teleman@sun.com Thu Mar 18 08:54:05 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IFs5pA021998 for ; Thu, 18 Mar 2010 08:54:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IFs0SE013066; Thu, 18 Mar 2010 08:54:00 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00I0FIU0KP00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Mar 2010 08:54:00 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00EGEITZIV70@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Mar 2010 08:53:59 -0700 (PDT) Received: from [10.7.250.112] (punchin-client-10-7-250-112.SFBay.Sun.COM [10.7.250.112]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o2IFrvsL304697; Thu, 18 Mar 2010 08:53:57 -0700 (PDT) Date: Thu, 18 Mar 2010 11:53:57 -0400 From: Stefan Teleman Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> To: PSARC-ext@sun.com Cc: "Garrett D'Amore - sun microsystems" , shell-discuss@opensolaris.org, Stefan Teleman Reply-to: stefan.teleman@sun.com Message-id: <4BA24C95.6020205@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 1235 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. 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 -- Stefan Teleman Oracle Corporation stefan.teleman@Sun.COM From Alan.Coopersmith@Sun.COM Thu Mar 18 08:58:30 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IFwU5d022184 for ; Thu, 18 Mar 2010 08:58:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IFwNpT015559 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 08:58:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0011BJ1HRO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 18 Mar 2010 08:58:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH0013CJ0TLT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 18 Mar 2010 08:58:05 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IFw5cW020448 for ; Thu, 18 Mar 2010 08:58:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00L00IY55S00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 18 Mar 2010 08:58:05 -0700 (PDT) Received: from [129.145.155.53] ([unknown] [129.145.155.53]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH00CSAJ0TAF20@fe-sfbay-09.sun.com>; Thu, 18 Mar 2010 08:58:05 -0700 (PDT) Date: Thu, 18 Mar 2010 08:58:05 -0700 From: Alan Coopersmith Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> Sender: Alan.Coopersmith@Sun.COM To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@Sun.COM, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA24D8D.7000008@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 771 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. Should this not be possible the ksh93 project team will > remove the mapping. So this constrains all future GNU coreutils update cases to coordinate with the ksh93 builtins, right? Have those responsible for the GNU coreutils agreed to this constraint? Should this be expressed as an ARC contract for cross-consolidation agreement of Volatile interfaces? -- -Alan Coopersmith- alan.coopersmith@sun.com Oracle Solaris Platform Engineering: X Window System From piochjennifer@googlemail.com Thu Mar 18 08:59:20 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IFxK7H022196 for ; Thu, 18 Mar 2010 08:59:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IFxJ3s013052 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 08:59:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0010NJ2VYV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 08:59:19 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001BWJ2ULQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 08:59:18 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IFu1gC002562 for ; Thu, 18 Mar 2010 15:59:18 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-156791 for PSARC-ext@sun.com; Thu, 18 Mar 2010 15:58:41 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-88585 for PSARC-ext@sun.com; Thu, 18 Mar 2010 15:58:41 +0000 (Z) Received: from mail-px0-f175.google.com ([209.85.216.175] [209.85.216.175]) by relay1i.sun.com with ESMTP id BT-MMP-42788159 for PSARC-ext@sun.com; Thu, 18 Mar 2010 15:58:41 +0000 (Z) Received: by pxi5 with SMTP id 5so1414240pxi.8 for ; Thu, 18 Mar 2010 08:58:40 -0700 (PDT) Received: by 10.115.102.36 with SMTP id e36mr630787wam.126.1268927920144; Thu, 18 Mar 2010 08:58:40 -0700 (PDT) Date: Thu, 18 Mar 2010 16:58:39 +0100 From: Jennifer Pioch Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24991.5080201@opensolaris.org> To: Darren J Moffat Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kechbf6HX7sgjjSPeiaNWWUw9H6xMCa1N2A4dgumrCk=; b=JL+47IW0UdX2CojuOUVPqKQNbGqVcAfk7i4mN9Lm1BadfJF/jGieWkzaCYBMAuW1yB 1dItgQqjXr4x5e2NLfOdy+pg7bS3NTRPwYi9COpJiZxMLaOChbmGaAI+NpAyR//TdJS5 dOFfQNkx2Sk2CtJspePUvgxk4kQBCO7LFZTSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kreDIF6kmUwuAhSA8iwk62S7AvBjiipkhop5JZd29kYjyXhxDBPYYGQJyN8yx/UJJQ CP6RcXQRCtICbd2daqZjepXwy0Z34zIX1oTgABydWu6gU24DsjfqT5DGKb4nrZXEfYJz W3ArB5lqbOjTbLPq8Fz1OgKY8iwF0rWRxGYew= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.084sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> Status: RO Content-Length: 1859 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 iterating over my source tree with basename takes 26 seconds without a builtin and 0.1 seconds when basename is a builtin: $ timex ksh93 -c 'find work/src | while read i ; do x=$(basename $i) ; done' real 26.35 user 9.34 sys 1.34 $ timex ksh93 -c 'builtin basename ; find work/src | while read i ; do x=$(basename $i) ; done' real 0.11 user 0.07 sys 0.03 This ROCKS incredibly!!!! :) > How does this interact with PSARC/2009/377 in kernel pfexec, maybe it > doesn't need to and that is an okay answer, when ksh93 is the profile shell > ? 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. > Why would I want to use ksh93 builtins if I have /usr/gnu/bin explicitly in > my path ? The default end user path in Opensolaris contains /usr/gnu/bin at the beginning. Scripts which run from that environment will have lower performance in ksh93 except when they set their own PATH. Enabling the builtins in /usr/gnu/bin solves the problem and restores full performance again. > Are the ksh93 builtin versions 100% compatible in all respects > with the GNU ones ? I think yes. Otherwise Olga wouldn't propose them. > If so then I wonder why we are even shipping the GNU > ones. I don't see the point either since the ksh93 commands have both features from GNU AND BSD Jenny -- Jennifer Pioch, Uni Frankfurt From gdamore@sun.com Thu Mar 18 09:02:26 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IG2QHK022316 for ; Thu, 18 Mar 2010 09:02:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IG2IRC019036 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 10:02:24 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00J01J7Z3C00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:02:23 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00E8AJ7YIV80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:02:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IG2MlA023328 for ; Thu, 18 Mar 2010 09:02:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00E00J4HYF00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:02:22 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH0098DJ7YK620@fe-sfbay-10.sun.com>; Thu, 18 Mar 2010 09:02:22 -0700 (PDT) Date: Thu, 18 Mar 2010 09:02:21 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24991.5080201@opensolaris.org> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA24E8D.9060201@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1742 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 have different ideas here, so they should respond if appropriate.) ksh93 already has the code. As I understand it, this change benefits ksh93 users and scripts, by reducing the total number of fork/exec calls. It makes use of the common code base that we already have available. I am not aware of any other benefits. > > How does this interact with PSARC/2009/377 in kernel pfexec, maybe it > doesn't need to and that is an okay answer, when ksh93 is the profile > shell ? I don't think this gets involved with that, because the builtins are only used when a default path search is applied, not when a fully specified path is used. > > 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 ? If so then I wonder > why we are even shipping the GNU ones. > My understanding is that yes, the ksh93 ones are fully compatible modulo some bugs which are fixed in the ksh93 versions. I've always questioned the idea that we have to ship all GNU tools, instead of modernizing our own set. I think the idea is to make people who prefer Linux happy. 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.) -- Garrett From piochjennifer@googlemail.com Thu Mar 18 09:05:53 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IG5rfB022366 for ; Thu, 18 Mar 2010 09:05:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IG5pYX022708; Thu, 18 Mar 2010 10:05:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0030DJDRYF00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:05:51 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001USJDOLQ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:05:48 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IG07Ju020816; Thu, 18 Mar 2010 16:05:47 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-2629162; Thu, 18 Mar 2010 16:05:47 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-71332560; Thu, 18 Mar 2010 16:05:45 +0000 (Z) Received: from mail-px0-f175.google.com ([209.85.216.175] [209.85.216.175]) by relay1i.sun.com with ESMTP id BT-MMP-4749220; Thu, 18 Mar 2010 16:05:44 +0000 (Z) Received: by pxi5 with SMTP id 5so1422104pxi.8 for ; Thu, 18 Mar 2010 09:05:44 -0700 (PDT) Received: by 10.142.195.21 with SMTP id s21mr127314wff.147.1268928344028; Thu, 18 Mar 2010 09:05:44 -0700 (PDT) Date: Thu, 18 Mar 2010 17:05:43 +0100 From: Jennifer Pioch Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24C95.6020205@Sun.COM> To: stefan.teleman@sun.com Cc: PSARC-ext@sun.com, shell-discuss@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <67079b831003180905x5c5113aei66128bd6c6e9eaae@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=w0r7pXXaUKVH1AKK2GwPAVzJv9xT/bGw6UpIdjY9k6I=; b=GuCFfrY6IRBF18H12e/ZSDtWPbpUwarcyDQfP6KEAVGVsyncP6eWSwNkPDCT67lpGH TdS4+KSSxMYKZq2pBL37fAMRx7FEJAbjK+H96xPjZsdopntbzLw7+JnpP61eM6eSeT4Z xD/YlzSD4sb94PV7YQMWBQTs0KsnDJX0rwykw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rk4zv8asJ5AYyH8xmRggcshPT5NA+Wby7MUMdwZy6GVyd2Cx9VWC3TqLnqfi7OwdMu OdD6TQhuik8UD6kZbYODX40YkfrHKET2TxtwQ3qt+gnlBX7tQE7wcHEIF/eNAINSdbrS c/o/m7acqo6Mdl/iubJ7DSXWBONR89ySx7tqA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 1.944sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24C95.6020205@Sun.COM> Status: RO Content-Length: 1590 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 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. > > 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 > > > > -- > Stefan Teleman > Oracle Corporation > stefan.teleman@Sun.COM > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > -- Jennifer Pioch, Uni Frankfurt From gdamore@sun.com Thu Mar 18 09:07:35 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IG7Zf3022385 for ; Thu, 18 Mar 2010 09:07:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IG7XiL019285 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:07:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00401JGM9T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 09:07:34 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH0016VJGMLQ10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 09:07:34 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IG7XsW022737 for ; Thu, 18 Mar 2010 09:07:33 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00200J5C8R00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 09:07:33 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH00C7HJGKAF60@fe-sfbay-09.sun.com>; Thu, 18 Mar 2010 09:07:33 -0700 (PDT) Date: Thu, 18 Mar 2010 09:07:32 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24D8D.7000008@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA24FC4.8030402@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24D8D.7000008@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1506 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 will update the corresponding ksh93 built >> in utility. Should this not be possible the ksh93 project team will >> remove the mapping. >> > So this constrains all future GNU coreutils update cases to coordinate > with the ksh93 builtins, right? Have those responsible for the GNU > coreutils agreed to this constraint? Should this be expressed as an > ARC contract for cross-consolidation agreement of Volatile interfaces? > > The ksh93 versions adhere to the public interfaces from the GNU versions. If they change the semantics, then it will require some extra work, but I'm not sure that a contract properly captures this. That said, this case explicitly states that it will revert any builtin if the GNU version evolves incompatibly (or even offers a new feature that the ksh93 doesn't) in the future. Personally, I despise the fact that we have to have GNU at the front of the user path. My $PATH doesn't list /usr/gnu at all. I'd far rather break this dependency upon GNU, and supply our own versions based on the ksh93 code base (which seems to be actively maintained), and just scrap /usr/gnu. But that's just my opinion, and not this case in any event. - Garrett From piochjennifer@googlemail.com Thu Mar 18 09:07:48 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IG7mrj022401 for ; Thu, 18 Mar 2010 09:07:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IG7l1t008563 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 11:07:48 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00J09JGZDH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:07:47 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00E8KJGZISB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:07:47 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IG35iV024765 for ; Thu, 18 Mar 2010 16:07:46 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-2551878 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:07:46 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-46034000 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:07:45 +0000 (Z) Received: from mail-px0-f175.google.com ([209.85.216.175] [209.85.216.175]) by relay4i.sun.com with ESMTP id BT-MMP-14428715 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:07:45 +0000 (Z) Received: by pxi5 with SMTP id 5so1424255pxi.8 for ; Thu, 18 Mar 2010 09:07:45 -0700 (PDT) Received: by 10.141.12.6 with SMTP id p6mr2818026rvi.179.1268928464937; Thu, 18 Mar 2010 09:07:44 -0700 (PDT) Date: Thu, 18 Mar 2010 17:07:44 +0100 From: Jennifer Pioch Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <67079b831003180907t79d95f8dm16a9a1bae1ab19ad@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QpM36/RYvzKChc/R3XvBp8Px+Mrba7kwsmnBdvEcieY=; b=tov4cd8GhnrucDdcjuVnGh9vOGtjDHcPdvZmAnvf6gues3yrTH7zOrfTSdwRQYEUUj E3FdfSNstFmyPXZMhIiJoOAvcl8JdXX7h1ZaBaNfTHngzFVJzIfwGpGa+l0ja9bYI4ck nEIob8oIZGEthdBNWMcH4icM6qL862q4NcAFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g3rnl9QF+4w2MZv3amS1o/AmusLgrBXk/vwDcivT1EH8kSrlEy+Glweq87sxLEkmuk NM5O6XSC7/IWVIukQyTiIzuTnmeIt9TCp4eHRy0sq3Y/rymRrmNYmb+UGXby1rkbhWBf KKSxT/uFc0kCj8jcCStn8I+Lk1YuG6UDerqf8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.135sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> Status: RO Content-Length: 7324 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 Document Author/Supplier: > Author: Olga Kryzhanovska > 1.3 Date of This Document: > 18 March, 2010 > 4. Technical Description > > I'm sponsoring this fast-track request on behalf of the > ksh93-integration project. > Please note that this is an *open* case. > > The release binding is the same as with the ksh93 project: a > patch/micro release of Solaris delivering through ON > Stability levels are as described below. > > > 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 > > Bug/RFE Number(s): > > 6935110 ksh93 needs (more) XPG, GNU built ins > > This case proposes to deliver the following features as a set of > independent putbacks as they become available. Each feature is > self contained and independent of the others, so out of order > and partial putbacks at this granularity should have no adverse > impact on the functionality and behavior of the system as a whole. > > > 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. > > > 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 > > Notes > ----- > Compatibility of AT&T AST ksh93 built in utilities and GNU > coreutils implementations: > Modulo correction bugs in the implementation, we believe that the > ksh93 built in utilities act as a 100% compatible drop in for the > GNU programs sans wording of --help, --version and error message > output (error messages are Not-An-Interface). > > 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. Should this not be possible the ksh93 project team will > remove the mapping. > > > > Part 2: ksh93 built in mappings for /usr/xpg4/bin utilities > ---------------------------------------------------------- > The case proposes to enable the following mappings to ksh93 built in > commands for utilities in /usr/xpg4/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/xpg4/bin binary. > > Interface Stability Description > --------- --------- ----------- > ksh93 '/usr/xpg4/bin/basename' built in Committed POSIX basename utility > ksh93 '/usr/xpg4/bin/egrep' built in Committed POSIX egrep utility > ksh93 '/usr/xpg4/bin/fgrep' built in Committed POSIX fgrep utility > ksh93 '/usr/xpg4/bin/grep' built in Committed POSIX grep utility > ksh93 '/usr/xpg4/bin/id' built in Committed POSIX id utility > ksh93 '/usr/xpg4/bin/rm' built in Committed POSIX rm utility > > > > Part 3: ksh93 built in mappings for /usr/bin utilities > ---------------------------------------------------------- > The case proposes to enable the following mappings to ksh93 built in > commands for utilities in /usr/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/xpg4/bin binary. > > Interface Stability Description > --------- --------- ----------- > ksh93 '/usr/bin/dirname' built in Committed POSIX dirname utility > > > General comments > ---------------- > This case heavily builds on PSARC/2006/550 which was the first > PSARC case to introduce the concept of shell built ins bound > to a path. > > > Future development > ------------------ > The shell project team will file separate ARC case to add the same > shell built ins to bash4, reusing the same code as ksh93 > (libcmd.so.1). > The shell project will provide an API within libcmd.so.1 for other > shells (e.g. bash4) and applications to call the built ins directly. > This API will be available as contracted API until sufficient > experience has been collected and then opened as Committed > interface. > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > +1 Jenny -- Jennifer Pioch, Uni Frankfurt From stefan.teleman@sun.com Thu Mar 18 09:08:11 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IG8BhX022422 for ; Thu, 18 Mar 2010 09:08:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IG8AR8021600 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Thu, 18 Mar 2010 09:08:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0082ZJHMB900@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 10:08:10 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005YVJHMTW10@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 10:08:10 -0600 (MDT) Received: from [10.7.250.112] (punchin-client-10-7-250-112.SFBay.Sun.COM [10.7.250.112]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o2IG88iC308095; Thu, 18 Mar 2010 09:08:08 -0700 (PDT) Date: Thu, 18 Mar 2010 12:08:08 -0400 From: Stefan Teleman Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <67079b831003180905x5c5113aei66128bd6c6e9eaae@mail.gmail.com> To: Jennifer Pioch Cc: PSARC-ext@sun.com, shell-discuss@opensolaris.org, "Garrett D'Amore - sun microsystems" Reply-to: stefan.teleman@sun.com Message-id: <4BA24FE8.5080009@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24C95.6020205@Sun.COM> <67079b831003180905x5c5113aei66128bd6c6e9eaae@mail.gmail.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 1746 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 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. >> >> 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 >> >> >> -- >> Stefan Teleman >> Oracle Corporation >> stefan.teleman@Sun.COM >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> > > > -- Stefan Teleman Oracle Corporation stefan.teleman@Sun.COM From gdamore@sun.com Thu Mar 18 09:10:42 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGAgWV022452 for ; Thu, 18 Mar 2010 09:10:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGAe6k022979 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:10:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0082RJLTJJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 10:10:41 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005EWJLRU520@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 10:10:39 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IGAdEM023520 for ; Thu, 18 Mar 2010 09:10:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00L00IY55R00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 09:10:39 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH00C7TJLRAF70@fe-sfbay-09.sun.com>; Thu, 18 Mar 2010 09:10:39 -0700 (PDT) Date: Thu, 18 Mar 2010 09:10:38 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24C95.6020205@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan.Teleman@sun.com Cc: PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" , shell-discuss@opensolaris.org Message-id: <4BA2507E.1080900@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24C95.6020205@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1798 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 > > > From Darren.Moffat@oracle.com Thu Mar 18 09:11:00 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGAxIk022475 for ; Thu, 18 Mar 2010 09:10:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGAxPa010663 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 11:10:59 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00J0FJMAJD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:10:58 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00E5EJM9IV90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:10:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGAlcn002267; Thu, 18 Mar 2010 16:10:47 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2IAmCpJ015762; Thu, 18 Mar 2010 16:10:44 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 97224111268928592; Thu, 18 Mar 2010 09:09:52 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Mar 2010 16:09:50 +0000 Date: Thu, 18 Mar 2010 16:09:47 +0000 From: Darren J Moffat Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> To: Jennifer Pioch Cc: Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA2504B.3050106@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BA25085.0028:SCFMA4539814,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1929 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 ? > > One advantage is MUCH HIGHER performance. A simple loop iterating over > my source tree with basename takes 26 seconds without a builtin and > 0.1 seconds when basename is a builtin: > $ timex ksh93 -c 'find work/src | while read i ; do x=$(basename $i) ; done' > > real 26.35 > user 9.34 > sys 1.34 > > $ timex ksh93 -c 'builtin basename ; find work/src | while read i ; do > x=$(basename $i) ; done' > > real 0.11 > user 0.07 > sys 0.03 > > This ROCKS incredibly!!!! :) > >> How does this interact with PSARC/2009/377 in kernel pfexec, maybe it >> doesn't need to and that is an okay answer, when ksh93 is the profile shell >> ? > > 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 be put in waiting need spec until that discussion reaches some consensus. The profile shell concept is not broken, some people may not like what it is or how it works but it is approved a delivered architecture. It has been deliver as part of Solaris since Solaris 8 and is based on functionality going back more than 15 years in various Trusted Solaris (and even before that name) releases of SunOS. >> If so then I wonder why we are even shipping the GNU >> ones. > > I don't see the point either since the ksh93 commands have both > features from GNU AND BSD Do the have 100% of the features with exactly the same behaviour though ? -- Darren J Moffat From Nicolas.Williams@sun.com Thu Mar 18 09:11:51 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGBp7M022496 for ; Thu, 18 Mar 2010 09:11:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGBpP4023851 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:11:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0053JJNR5R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:11:51 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00176JNOLO20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:11:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGBm1h003913; Thu, 18 Mar 2010 16:11:48 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2I8asAr025491; Thu, 18 Mar 2010 16:11:44 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 92393241268928588; Thu, 18 Mar 2010 09:09:48 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Mar 2010 09:09:46 -0700 Date: Thu, 18 Mar 2010 11:09:40 -0500 From: Nicolas Williams Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> To: Jennifer Pioch Cc: Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <20100318160940.GI18167@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BA250C1.015C,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1298 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 does this case bring ? > > One advantage is MUCH HIGHER performance. A simple loop iterating over > my source tree with basename takes 26 seconds without a builtin and > 0.1 seconds when basename is a builtin: BTW, I've been using ${var##*/} and ${var%/*} for years as a built-in replacement for basename(1) and dirname(1). Making those two commands built-ins won't help me! :) > This ROCKS incredibly!!!! :) I agree that more builtins -> better. > > Are the ksh93 builtin versions 100% compatible in all respects > > with the GNU ones ? > > I think yes. Otherwise Olga wouldn't propose them. > > > If so then I wonder why we are even shipping the GNU > > ones. > > I don't see the point either since the ksh93 commands have both > features from GNU AND BSD Bash users still need the commands in the bin directories. This case has a note indicating that eventually even bash4 weill be able to use ksh93 builtins, but that would still leave zsh, tcsh, ... Nico -- From gdamore@sun.com Thu Mar 18 09:15:43 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGFgNW022564 for ; Thu, 18 Mar 2010 09:15:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGFgVc014309 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 11:15:42 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0062VJU60Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:15:42 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001RLJU5LV10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:15:41 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IGFebA024932 for ; Thu, 18 Mar 2010 09:15:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00L00IY55R00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:15:40 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH00CZ0JTZAF90@fe-sfbay-09.sun.com>; Thu, 18 Mar 2010 09:15:35 -0700 (PDT) Date: Thu, 18 Mar 2010 09:15:35 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA2504B.3050106@Oracle.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Jennifer Pioch , Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA251A7.9000200@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1768 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 be put in waiting need spec until that > discussion reaches some consensus. > > The profile shell concept is not broken, some people may not like what > it is or how it works but it is approved a delivered architecture. It > has been deliver as part of Solaris since Solaris 8 and is based on > functionality going back more than 15 years in various Trusted Solaris > (and even before that name) releases of SunOS. 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. If the above isn't true, and there will be breakage for any of these, then yes, this case needs to be put in waiting need spec. If however the only problem is that pfexec'd versions of the builtins will not use the builtin but suffer a performance penalty (a real fork/exec), then I think we can proceed. Can folks more familiar with the problem(s) involved here please clarify? > >>> If so then I wonder why we are even shipping the GNU >>> ones. >> >> I don't see the point either since the ksh93 commands have both >> features from GNU AND BSD > > Do the have 100% of the features with exactly the same behaviour though ? > Olga has assured me that yes, this is the case. (Modulo fixing some edge case bugs, such as handling of multi-byte locales.) - Garrett From piochjennifer@googlemail.com Thu Mar 18 09:16:48 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGGmbF022587 for ; Thu, 18 Mar 2010 09:16:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGGiah033258 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 10:16:47 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0065VJVZ9D00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:16:47 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001WGJVWLV10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:16:44 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGGioM005288 for ; Thu, 18 Mar 2010 16:16:44 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-158540 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:16:44 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-71087539 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:16:41 +0000 (Z) Received: from mail-pw0-f49.google.com ([209.85.160.49] [209.85.160.49]) by relay1i.sun.com with ESMTP id BT-MMP-4766829 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:16:41 +0000 (Z) Received: by pwj2 with SMTP id 2so1675654pwj.8 for ; Thu, 18 Mar 2010 09:16:40 -0700 (PDT) Received: by 10.142.118.26 with SMTP id q26mr1351412wfc.127.1268929000583; Thu, 18 Mar 2010 09:16:40 -0700 (PDT) Date: Thu, 18 Mar 2010 17:16:40 +0100 From: Jennifer Pioch Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA2504B.3050106@Oracle.COM> To: Darren J Moffat Cc: Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <67079b831003180916la77065eqfab06b1c88c5133e@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1VwWqCcqXsZq9+YPXIVYQBcp2Ycww941DSp+JXZCOzo=; b=HjDN/EnqxOwMlwJlDRK4bgsJTrTWUnqibtmebiQFtQi7sEexygUvpLMwTgLBEtztYg aMF3haE1wwOCGGb8XlEhsuL+7Q0GJVt/+hJgpnSp5ovhgFZtLmP/h9MrNONswaf/2ZQ+ J+IQaRQBkOrskEbzT9ZbeU+PvgiO0AyMDn864= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DQgfdg8yePQjmUhp5r9HOiFQ9winWYFagSk4CxqDZ1SPo4dSP5kd7E0sSsuo5CQJdt QwIksSbLqxqSRjs7fjSvxq+EsZEAGZDghogUN+lhi3mjYI4uRtNETW1h5ryQEFUjrB3i iGTXYZtzlICAPJI3cgy5YZ0T07nK3A8s6SKX0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 2.133sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> Status: RO Content-Length: 2656 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 understand what this case is about. >>> >>> What benefit does this case bring ? >> >> One advantage is MUCH HIGHER performance. A simple loop iterating over >> my source tree with basename takes 26 seconds without a builtin and >> 0.1 seconds when basename is a builtin: >> $ timex ksh93 -c 'find work/src | while read i ; do x=$(basename $i) ; >> done' >> >> real 26.35 >> user 9.34 >> sys 1.34 >> >> $ timex ksh93 -c 'builtin basename ; find work/src | while read i ; do >> x=$(basename $i) ; done' >> >> real 0.11 >> user 0.07 >> sys 0.03 >> >> This ROCKS incredibly!!!! :) >> >>> How does this interact with PSARC/2009/377 in kernel pfexec, maybe it >>> doesn't need to and that is an okay answer, when ksh93 is the profile >>> shell >>> ? >> >> 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 be put in waiting need spec until that discussion > reaches some consensus. 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? Why should this case wait for something where not even a consensus has been reached whether the issue is a bug or not? Or is this a delay tactic again to stall? > > The profile shell concept is not broken, Go to the bash authors and ask them. Ask them why they never accepted the patches for profile shell support. Why did BSD never adopt the profile shell system? Did Linux adopt this concept? The answer is all a big, sticky NO. > some people may not like what it is > or how it works but it is approved a delivered architecture. It has been > deliver as part of Solaris since Solaris 8 and is based on functionality > going back more than 15 years in various Trusted Solaris (and even before > that name) releases of SunOS. > >>> If so then I wonder why we are even shipping the GNU >>> ones. >> >> I don't see the point either since the ksh93 commands have both >> features from GNU AND BSD > > Do the have 100% of the features with exactly the same behaviour though ? Yes, I think so. Jenny -- Jennifer Pioch, Uni Frankfurt From casper@holland.sun.com Thu Mar 18 09:17:22 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGHMWo022609 for ; Thu, 18 Mar 2010 09:17:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGHL3e033669 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 10:17:22 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0090FJWY6000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 10:17:22 -0600 (MDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005CEJWWTZ30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 10:17:21 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGHITU004441; Thu, 18 Mar 2010 16:17:18 +0000 (GMT) Date: Thu, 18 Mar 2010 17:17:18 +0100 From: Casper.Dik@sun.com Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24E8D.9060201@sun.com> Sender: casper@holland.sun.com To: Shells discussion Cc: Darren J Moffat , PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" Message-id: <201003181617.o2IGHITU004441@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <4BA24E8D.9060201@sun.com> Status: RO Content-Length: 411 >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 newer version of a GNU tool in OpenSolaris needs to make sure that ksh93 is updated at the same time. Casper From stefan.teleman@sun.com Thu Mar 18 09:21:24 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGLNkt022718 for ; Thu, 18 Mar 2010 09:21:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGLMna018839; Thu, 18 Mar 2010 11:21:23 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH0092JK3MKD00@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 10:21:22 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005E8K3JUB20@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 10:21:20 -0600 (MDT) Received: from [10.7.250.112] (punchin-client-10-7-250-112.SFBay.Sun.COM [10.7.250.112]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o2IGLI8W311169; Thu, 18 Mar 2010 09:21:18 -0700 (PDT) Date: Thu, 18 Mar 2010 12:21:18 -0400 From: Stefan Teleman Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA2507E.1080900@sun.com> To: "Garrett D'Amore" , PSARC-ext@sun.com Cc: "Garrett D'Amore - sun microsystems" , shell-discuss@opensolaris.org Reply-to: stefan.teleman@sun.com Message-id: <4BA252FE.1000308@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24C95.6020205@Sun.COM> <4BA2507E.1080900@sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 2221 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 >> 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. Why do I need to explicitly disable something I don't want in the first place ? I want to use the GNU grep in /usr/gnu/bin/grep. I don't want to have to tell the shell NOT to silently override my explicit choices. Having the shell override explicit choices by default is in my opinion inherently broken. And the rationale behind this breakage appears to be: "We broke the expected behavior. If you don't like this breakage, change your shell." > I guess I don't really understand the objection -- the builtin behaves > the same way, but performs better. What's the issue? 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 architecturally. And it is not acceptable to say "get rid of /usr/gnu and make room for the ksh93 builtins", because that's not how it is supposed to work. The GNU coreutils/binutils were integrated first. --Stefan -- Stefan Teleman Oracle Corporation stefan.teleman@Sun.COM From casper@holland.sun.com Thu Mar 18 09:28:38 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGSc4W022779 for ; Thu, 18 Mar 2010 09:28:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGSbF5001948; Thu, 18 Mar 2010 09:28:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00A07KFP9200@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 10:28:37 -0600 (MDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005LYKFOU530@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 10:28:37 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGSXkS009692; Thu, 18 Mar 2010 16:28:33 +0000 (GMT) Date: Thu, 18 Mar 2010 17:28:33 +0100 From: Casper.Dik@sun.com Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA251A7.9000200@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , Jennifer Pioch , Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> Status: RO Content-Length: 543 >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 the case and "pfsh" in OpenSolaris doesn't work as OpenSolaris did for the builtins. I'm hoping to fix that by making sure we ignore the builtin commands in profile shells. (By default and as only option inside of a profile shell) Casper From gsf@research.att.com Thu Mar 18 09:30:35 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGUZZg022849 for ; Thu, 18 Mar 2010 09:30:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGUXfF045991; Thu, 18 Mar 2010 10:30:34 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00A0LKIXH000@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 10:30:33 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00553KIXUB30@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 10:30:33 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGUXh7010251; Thu, 18 Mar 2010 16:30:33 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-2532849; Thu, 18 Mar 2010 16:28:33 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-45479286; Thu, 18 Mar 2010 16:28:32 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay4i.sun.com with ESMTP id BT-MMP-62419393; Thu, 18 Mar 2010 16:28:32 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-blue.research.att.com (Postfix) with ESMTP id BCD7DEF6DF; Thu, 18 Mar 2010 12:28:32 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id o2IGSWbJ004778; Thu, 18 Mar 2010 12:28:32 -0400 Date: Thu, 18 Mar 2010 12:28:32 -0400 From: Glenn Fowler Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] To: PSARC-ext@sun.com, stefan.teleman@sun.com Cc: gd78059@sac.sfbay.sun.com, shell-discuss@opensolaris.org Message-id: <201003181628.o2IGSWbJ004778@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.096sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24C95.6020205@Sun.COM> Status: RO Content-Length: 1255 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 builtin then /usr/gnu/bin/grep will take precedence over the grep builtin On Thu, 18 Mar 2010 11:53:57 -0400 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. From peter.tribble@gmail.com Thu Mar 18 09:31:21 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGVL4E022912 for ; Thu, 18 Mar 2010 09:31:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGVDQr004596 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:31:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00L0FKK61900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:31:18 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00E41KK5IVB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:31:17 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGOWb4010282 for ; Thu, 18 Mar 2010 16:31:17 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-2610328 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:31:17 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-69136677 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:31:15 +0000 (Z) Received: from mail-wy0-f177.google.com ([74.125.82.177] [74.125.82.177]) by relay1i.sun.com with ESMTP id BT-MMP-42839207 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:31:15 +0000 (Z) Received: by wyb34 with SMTP id 34so1087968wyb.8 for ; Thu, 18 Mar 2010 09:31:06 -0700 (PDT) Received: by 10.216.173.74 with SMTP id u52mr27386wel.204.1268929865654; Thu, 18 Mar 2010 09:31:05 -0700 (PDT) Date: Thu, 18 Mar 2010 16:31:04 +0000 From: Peter Tribble Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I+bPSxxqG3dva4N7SfB8MxueRSFMmFqkokuTmWt4n1c=; b=WzgVzt8OpJfEP6aBoVtEUdI/5ff7PrHDsi2//JGk3BvNQeQSUv8luXK2VnQ3RP9L7l 8IhilkGFKCMLQhHHgp1xTW7XkLxLhRgFRpbYKK5dT2nbdlPvi2MDdjpJi26MlGydxjGs A5gKKLoK9wt67Ojaj5ah3s796hRMgLF52pNXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hq/X4OwS2r91Gupu28h+tyT79CXPd+U9DF7ifLjSbxxWzLw8FopYgMnne4KJkAAn6z 1AX1QpzSU5F2Uvyns+tMNfeAeWcsI1LAA1R9IMM9AslqhQon7kfrOumxQs0ztmxH9x2S NL0ldJKydhI318/FN48Idj58ZAvywPFZgQvIo= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 2.048sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o2IGVL4E022912 Status: RO Content-Length: 2643 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 Document Author/Supplier: >         Author:  Olga Kryzhanovska >    1.3  Date of This Document: >        18 March, 2010 > 4. Technical Description > > I'm sponsoring this fast-track request on behalf of the > ksh93-integration project. > Please note that this is an *open* case. > > The release binding is the same as with the ksh93 project: a > patch/micro release of Solaris delivering through ON > Stability levels are as described below. > > > 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 > > Bug/RFE Number(s): > > 6935110  ksh93 needs (more) XPG, GNU built ins > > This case proposes to deliver the following features as a set of > independent putbacks as they become available. Each feature is > self contained and independent of the others, so out of order > and partial putbacks at this granularity should have no adverse > impact on the functionality and behavior of the system as a whole. > > > 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. > > > Interface                               Stability        Description > ---------                               ---------        ----------- > ksh93 '/usr/gnu/bin/basename' built in  Uncommitted      basename utility with GNU extensions So, if I call a plain basename, what gets executed? Does it look at the PATH setting and call the gnu/solaris/xpg4 (or for the more perverse of us, ucb) variant of the builtin? Is there just one builtin that always behaves the same way? Or, another way, if I don't have /usr/gnu/bin in my PATH, will the builtin basename have the GNU extensions? (Differences for something like basename are minor; for other utilities the differences may matter.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From Darren.Moffat@Oracle.COM Thu Mar 18 09:31:52 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGVp6Z022952 for ; Thu, 18 Mar 2010 09:31:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGVn6O046693; Thu, 18 Mar 2010 10:31:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00905KL1JX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:31:49 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001EHKKZLV40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:31:47 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGVklB011040; Thu, 18 Mar 2010 16:31:46 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2IGVgdg011849; Thu, 18 Mar 2010 16:31:43 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 97288921268929901; Thu, 18 Mar 2010 09:31:41 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Mar 2010 09:31:41 -0700 Date: Thu, 18 Mar 2010 16:31:37 +0000 From: Darren J Moffat Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> To: Casper.Dik@sun.com Cc: "Garrett D'Amore" , Jennifer Pioch , Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA25569.1030300@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BA2556F.01C0:SCFMA4539814,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 722 On 18/03/2010 16:28, Casper.Dik@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 use the filesystem supplied binary. > > That is not currently the case and "pfsh" in OpenSolaris doesn't work as > OpenSolaris did for the builtins. I'm hoping to fix that by making sure > we ignore the builtin commands in profile shells. (By default and as only > option inside of a profile shell) Thank you Casper, that is all I needed to know. I'm happy to see that you and Glenn are working on it. -- Darren J Moffat From gdamore@sun.com Thu Mar 18 09:36:52 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGaqtO023042 for ; Thu, 18 Mar 2010 09:36:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGaqWs008603 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:36:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00L1JKTGC700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 09:36:52 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00EAEKTFIUE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 09:36:51 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IGapOV001566 for ; Thu, 18 Mar 2010 09:36:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00A00KQL5X00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Mar 2010 09:36:51 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH009OGKTEK6E0@fe-sfbay-10.sun.com>; Thu, 18 Mar 2010 09:36:51 -0700 (PDT) Date: Thu, 18 Mar 2010 09:36:50 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA252FE.1000308@Sun.COM> Sender: Garrett.Damore@sun.com To: stefan.teleman@sun.com Cc: PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" , shell-discuss@opensolaris.org Message-id: <4BA256A2.5030701@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24C95.6020205@Sun.COM> <4BA2507E.1080900@sun.com> <4BA252FE.1000308@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1150 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 architecturally. We already have them even without this case. I hate this too. I would love to just get rid of *all* the others, provide a single implementation based on ksh93 that offers all the most often requested features. But that's not this case. > > And it is not acceptable to say "get rid of /usr/gnu and make room for > the ksh93 builtins", because that's not how it is supposed to work. > The GNU coreutils/binutils were integrated first. If you feel that way, then either don't use ksh93, or use a .profile that disables the builtins. 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 want. - Garrett From peter.tribble@gmail.com Thu Mar 18 09:38:04 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGc4T6023063 for ; Thu, 18 Mar 2010 09:38:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGc4lR009161 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:38:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00B27KVF0M00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:38:03 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001A6KVELR70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:38:02 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IGWsoP021039 for ; Thu, 18 Mar 2010 16:38:02 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-160265 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:38:02 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-69147345 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:38:00 +0000 (Z) Received: from mail-wy0-f177.google.com ([74.125.82.177] [74.125.82.177]) by relay1i.sun.com with ESMTP id BT-MMP-3454471 for PSARC-ext@sun.com; Thu, 18 Mar 2010 16:37:59 +0000 (Z) Received: by wyb34 with SMTP id 34so1091081wyb.8 for ; Thu, 18 Mar 2010 09:37:54 -0700 (PDT) Received: by 10.216.162.3 with SMTP id x3mr524401wek.21.1268930273810; Thu, 18 Mar 2010 09:37:53 -0700 (PDT) Date: Thu, 18 Mar 2010 16:37:53 +0000 From: Peter Tribble Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24991.5080201@opensolaris.org> To: Darren J Moffat Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SISfhbeq9eH6rCwvn4PCdVYQqAEf743buOyJUj0cORo=; b=FwgsxP1jRxDu8Z/nSi+lo09qgWStJW737qctyggjcw5/7/vLypROBkPZooyXkxVqoR R2qIiDKfUCDo7fk4PWYwAYly76pSOPxKuDHpDWEIw0yrYOw9Zf7LF2N1tfhln6WOBSo/ we7e/RTvy0h9z7YDTDp5waV72YM2ScJ3k3lJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iCk0IrZQbCAsjyFQeXWjehC77nV48aBcWs8KTPRJWt8JXIa9I5efoZxk21c9ZpweXu vF9TVr/2+Uujp4/eglGKz7CMUKgrdXRx4jJG+XlrK1lWIXuLdYvVGLKhfGNjbwquKfqM jNmjRTebiV95pNG1BfVruzoQXIlukl1i7zI6A= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.044sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o2IGc4T6023063 Status: RO Content-Length: 699 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 worded differently. I've seen configure scripts and applications take apart --version output in order to divine version-specific behaviour > If so then I wonder why we are even shipping the GNU > ones. Because that's what many users and applications expect. And there's a world outside ksh93. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From gdamore@sun.com Thu Mar 18 09:38:20 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGcJFJ023082 for ; Thu, 18 Mar 2010 09:38:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGcJs2009553 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:38:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00L0HKVVFS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@SUN.COM); Thu, 18 Mar 2010 09:38:19 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00E8MKVUIVC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@SUN.COM); Thu, 18 Mar 2010 09:38:18 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IGcISV001829 for ; Thu, 18 Mar 2010 09:38:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00M00KP10300@fe-sfbay-09.sun.com> for PSARC-ext@SUN.COM (ORCPT PSARC-ext@SUN.COM); Thu, 18 Mar 2010 09:38:18 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH00CMHKVTAFH0@fe-sfbay-09.sun.com>; Thu, 18 Mar 2010 09:38:17 -0700 (PDT) Date: Thu, 18 Mar 2010 09:38:17 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> Sender: Garrett.Damore@sun.com To: Casper.Dik@sun.com Cc: Darren J Moffat , Jennifer Pioch , Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA256F9.5060104@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 694 On 03/18/10 09:28 AM, Casper.Dik@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 use the filesystem supplied binary. >> > That is not currently the case and "pfsh" in OpenSolaris doesn't work as > OpenSolaris did for the builtins. I'm hoping to fix that by making sure > we ignore the builtin commands in profile shells. (By default and as only > option inside of a profile shell) > > > Casper > > This sounds like a showstopper for this case then. - Garrett From Darren.Moffat@Oracle.COM Thu Mar 18 09:42:09 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGg9VI023127 for ; Thu, 18 Mar 2010 09:42:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGg1r3055929; Thu, 18 Mar 2010 10:42:05 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00BAZL24UL00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:42:04 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001VLL20LQ50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:42:01 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGfxqP010603; Thu, 18 Mar 2010 16:42:00 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2IGfq1W031700; Thu, 18 Mar 2010 16:41:52 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 92501821268930480; Thu, 18 Mar 2010 09:41:20 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Mar 2010 09:41:20 -0700 Date: Thu, 18 Mar 2010 16:41:16 +0000 From: Darren J Moffat Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA256F9.5060104@sun.com> To: "Garrett D'Amore" Cc: Casper.Dik@sun.com, Jennifer Pioch , Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA257AC.1050802@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BA257D2.00D9:SCFMA4539814,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> <4BA256F9.5060104@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1079 On 18/03/2010 16:38, Garrett D'Amore wrote: > On 03/18/10 09:28 AM, Casper.Dik@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 use the filesystem supplied binary. >> That is not currently the case and "pfsh" in OpenSolaris doesn't work as >> OpenSolaris did for the builtins. I'm hoping to fix that by making sure >> we ignore the builtin commands in profile shells. (By default and as only >> option inside of a profile shell) >> >> >> Casper >> > > This sounds like a showstopper for this case then. This case doesn't make the current situation worse. I also now understand that isn't really that relevant to this case anyway because this is all about when /usr/gnu/bin is first in your path and about providing builtins for that. Since we have no /usr/gnu/bin entries in exec_attr anyway there is no issue with pfexec and this case. -- Darren J Moffat From casper@holland.sun.com Thu Mar 18 09:46:08 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGk8H3023204 for ; Thu, 18 Mar 2010 09:46:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGk3Mh060069; Thu, 18 Mar 2010 10:46:03 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00CGPL8RH700@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:46:03 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001T1L8MLR80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:45:59 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGjtO9016121; Thu, 18 Mar 2010 16:45:55 +0000 (GMT) Date: Thu, 18 Mar 2010 17:45:55 +0100 From: Casper.Dik@sun.com Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA257AC.1050802@Oracle.COM> Sender: casper@holland.sun.com To: Darren J Moffat Cc: "Garrett D'Amore" , Jennifer Pioch , Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <201003181645.o2IGjtO9016121@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> <4BA256F9.5060104@sun.com> <4BA257AC.1050802@Oracle.COM> Status: RO Content-Length: 1175 >On 18/03/2010 16:38, Garrett D'Amore wrote: >> On 03/18/10 09:28 AM, Casper.Dik@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 use the filesystem supplied binary. >>> That is not currently the case and "pfsh" in OpenSolaris doesn't work as >>> OpenSolaris did for the builtins. I'm hoping to fix that by making sure >>> we ignore the builtin commands in profile shells. (By default and as only >>> option inside of a profile shell) >>> >>> >>> Casper >>> >> >> This sounds like a showstopper for this case then. > >This case doesn't make the current situation worse. I also now >understand that isn't really that relevant to this case anyway because >this is all about when /usr/gnu/bin is first in your path and about >providing builtins for that. Since we have no /usr/gnu/bin entries in >exec_attr anyway there is no issue with pfexec and this case. I agree with Darren (assuming there are no profiles with now builtin GNU commands) Casper From gsf@research.att.com Thu Mar 18 09:48:56 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGmuS9023297 for ; Thu, 18 Mar 2010 09:48:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGmsrU062458; Thu, 18 Mar 2010 10:48:54 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00D1XLDIDV00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:48:54 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00136LDGLO50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 09:48:52 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IGeFSM015992; Thu, 18 Mar 2010 16:48:51 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-2611653; Thu, 18 Mar 2010 16:48:51 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-164513; Thu, 18 Mar 2010 16:48:51 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-42867733; Thu, 18 Mar 2010 16:48:51 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id 3ABC5212F67; Thu, 18 Mar 2010 12:48:51 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id o2IGmpsK005250; Thu, 18 Mar 2010 12:48:51 -0400 Date: Thu, 18 Mar 2010 12:48:51 -0400 From: Glenn Fowler Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] To: Casper.Dik@sun.com, shell-discuss@opensolaris.org Cc: Darren.Moffat@oracle.com, darrenm@opensolaris.org, gd78059@sac.sfbay.sun.com, PSARC-ext@sun.com Message-id: <201003181648.o2IGmpsK005250@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.059sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> <4BA256F9.5060104@sun.com> Status: RO Content-Length: 1229 On Thu, 18 Mar 2010 09:38:17 -0700 Garrett D'Amore wrote: > On 03/18/10 09:28 AM, Casper.Dik@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 use the filesystem supplied binary. > >> > > That is not currently the case and "pfsh" in OpenSolaris doesn't work as > > OpenSolaris did for the builtins. I'm hoping to fix that by making sure > > we ignore the builtin commands in profile shells. (By default and as only > > option inside of a profile shell) > > > > > > Casper > > > > > This sounds like a showstopper for this case then. > - Garrett 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() (with made-up function names) pfexec_pretend("mkdir") b_mkdir() pfexec_stop_pretending() if this is possible I would like to see example code From casper@holland.sun.com Thu Mar 18 09:51:30 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGpU3D023323 for ; Thu, 18 Mar 2010 09:51:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGpU0J016756 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:51:30 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00C03LHUT400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 10:51:30 -0600 (MDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005EKLHTU150@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 10:51:30 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGpQZc017575; Thu, 18 Mar 2010 16:51:26 +0000 (GMT) Date: Thu, 18 Mar 2010 17:51:26 +0100 From: Casper.Dik@sun.com Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181648.o2IGmpsK005250@penguin.research.att.com> Sender: casper@holland.sun.com To: Glenn Fowler Cc: shell-discuss@opensolaris.org, Darren.Moffat@oracle.com, darrenm@opensolaris.org, gd78059@sac.sfbay.sun.com, PSARC-ext@sun.com Message-id: <201003181651.o2IGpQZc017575@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> <4BA256F9.5060104@sun.com> <201003181648.o2IGmpsK005250@penguin.research.att.com> Status: RO Content-Length: 536 >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() (with made-up function names) > pfexec_pretend("mkdir") > b_mkdir() > pfexec_stop_pretending() >if this is possible I would like to see example code No, not quite: the kernel-code will only work on exec and not inside a shell. Casper From gdamore@sun.com Thu Mar 18 09:52:18 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGqHiU023357 for ; Thu, 18 Mar 2010 09:52:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IGqDVe065108 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 10:52:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00E41LJ53C00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@SUN.COM); Thu, 18 Mar 2010 09:52:17 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001JQLJ3LR90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@SUN.COM); Thu, 18 Mar 2010 09:52:16 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IGqFHF004842 for ; Thu, 18 Mar 2010 09:52:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00400LD88G00@fe-sfbay-10.sun.com> for PSARC-ext@SUN.COM (ORCPT PSARC-ext@SUN.COM); Thu, 18 Mar 2010 09:52:15 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH002UYLIXA410@fe-sfbay-10.sun.com>; Thu, 18 Mar 2010 09:52:10 -0700 (PDT) Date: Thu, 18 Mar 2010 09:52:09 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: Sender: Garrett.Damore@sun.com To: Peter Tribble Cc: Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA25A39.4030804@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2402 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 ? >> > No. It's explicitly stated that --version in particular is worded differently. > I've seen configure scripts and applications take apart --version output > in order to divine version-specific behaviour > If those versions specify a full path, then they'll not see a change. It does sound like this is kind of busted. I can understand why this happens though. > >> If so then I wonder why we are even shipping the GNU >> ones. >> > Because that's what many users and applications expect. And there's > a world outside ksh93. > > 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 most well-maintained POSIX conforming implementation, and offers all the features people seem to want, so that seems like the best choice. 2) /usr/gnu versions would still ship for people who *insist*, but we should not be advocating GNU versions in preference to the POSIX conforming versions. /usr/gnu has no place (IMO) on the default user's path. The fact that we put it there at all now is just a crutch to workaround the lack of investment in the aging (rotting!) Sun userland (ksh93 not included) 3) IMO, the configuration of builtins should be enabled the same way that other PATH elements are enabled -- via a new PATH element. I would not mind seeing /usr/ksh93/bin. This could be prepended to the default PATH for new users. It would provide POSIX conforming (plus any of the popular desired features from GNU, BSD, etc.) implementations of commands, but would also allow for simple builtins to be used by libcmd and ksh93. Since ksh93 uses libcmd, there would be *zero* functional difference apart from the savings of a fork/exec, and everyone would be happy. This whole nonsense IMO, comes about because the ksh93 folks want to enable higher performance, but someone decided that /usr/gnu should be at the front of default users PATHs. I think *that* decision was busted. -- Garrett From gdamore@sun.com Thu Mar 18 09:52:55 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IGqtUN023379 for ; Thu, 18 Mar 2010 09:52:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IGqrSL017864 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 09:52:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00C0JLK6XL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 10:52:54 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00547LK6UB50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 10:52:54 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IGqsJ7003710 for ; Thu, 18 Mar 2010 09:52:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00400LD88G00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 09:52:54 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH0023ZLK5A420@fe-sfbay-10.sun.com>; Thu, 18 Mar 2010 09:52:53 -0700 (PDT) Date: Thu, 18 Mar 2010 09:52:53 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA257AC.1050802@Oracle.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Casper.Dik@sun.com, Jennifer Pioch , Darren J Moffat , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA25A65.6090403@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> <4BA256F9.5060104@sun.com> <4BA257AC.1050802@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1242 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@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 use the filesystem supplied binary. >>> That is not currently the case and "pfsh" in OpenSolaris doesn't >>> work as >>> OpenSolaris did for the builtins. I'm hoping to fix that by making sure >>> we ignore the builtin commands in profile shells. (By default and as >>> only >>> option inside of a profile shell) >>> >>> >>> Casper >>> >> >> This sounds like a showstopper for this case then. > > This case doesn't make the current situation worse. I also now > understand that isn't really that relevant to this case anyway because > this is all about when /usr/gnu/bin is first in your path and about > providing builtins for that. Since we have no /usr/gnu/bin entries in > exec_attr anyway there is no issue with pfexec and this case. > Thanks for the clarification. So, this particular objection is removed. - Garrett From gsf@research.att.com Thu Mar 18 10:26:19 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IHQJIY024012 for ; Thu, 18 Mar 2010 10:26:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IHQG8B005182; Thu, 18 Mar 2010 10:26:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00G3FN3T7100@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 11:26:17 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005ZTN3SU180@brm-avmta-1.central.sun.com>; Thu, 18 Mar 2010 11:26:16 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IHNhqD024672; Thu, 18 Mar 2010 17:26:15 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-2614590; Thu, 18 Mar 2010 17:26:15 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-69221131; Thu, 18 Mar 2010 17:26:11 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-42926089; Thu, 18 Mar 2010 17:26:10 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id DBF7D212F66; Thu, 18 Mar 2010 12:54:56 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id o2IGsuOl005514; Thu, 18 Mar 2010 12:54:56 -0400 Date: Thu, 18 Mar 2010 12:54:56 -0400 From: Glenn Fowler Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] To: Casper.Dik@sun.com, gsf@research.att.com Cc: Darren.Moffat@oracle.com, darrenm@opensolaris.org, gd78059@sac.sfbay.sun.com, PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <201003181654.o2IGsuOl005514@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.105sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <4BA251A7.9000200@sun.com> <201003181628.o2IGSXkS009692@dm-holland-01.uk.sun.com> <4BA256F9.5060104@sun.com> <201003181648.o2IGmpsK005250@penguin.research.att.com> <201003181651.o2IGpQZc017575@dm-holland-01.uk.sun.com> Status: RO Content-Length: 732 On Thu, 18 Mar 2010 17:51:26 +0100 Casper.Dik@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 posts ago:) mentioned this is possible > >e.g., for the builtin b_mkdir() (with made-up function names) > > pfexec_pretend("mkdir") > > b_mkdir() > > pfexec_stop_pretending() > >if this is possible I would like to see example code > No, not quite: the kernel-code will only work on exec and not inside > a shell. ok, thanks anyway, we should have an alpha package for you to check tomorrow that disables the -lcmd builtins in pfksh From alan.coopersmith@oracle.com Thu Mar 18 10:33:29 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IHXTt6024130 for ; Thu, 18 Mar 2010 10:33:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IHWLAf034142 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 11:33:29 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00G0XNFEV100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 11:33:14 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH0054ONFEU580@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 11:33:14 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IHXDIY014638; Thu, 18 Mar 2010 17:33:13 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2IHXA1X015481; Thu, 18 Mar 2010 17:33:10 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 97478441268933558; Thu, 18 Mar 2010 10:32:38 -0700 Received: from [129.145.155.53] (/129.145.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Mar 2010 10:32:36 -0700 Date: Thu, 18 Mar 2010 10:32:35 -0700 From: Alan Coopersmith Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <67079b831003180916la77065eqfab06b1c88c5133e@mail.gmail.com> To: Jennifer Pioch Cc: Darren J Moffat , PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" , shell-discuss@opensolaris.org Message-id: <4BA263B3.50802@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BA263D7.0056:SCFMA4539814,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <67079b831003180858r51fd2481j66ec951ea7401278@mail.gmail.com> <4BA2504B.3050106@Oracle.COM> <67079b831003180916la77065eqfab06b1c88c5133e@mail.gmail.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 502 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 not decided by democratic vote of the masses, but by review of the experts in that area. -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From carlsonj@workingcode.com Thu Mar 18 10:39:24 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IHdOTF024175 for ; Thu, 18 Mar 2010 10:39:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IHdITt008530; Thu, 18 Mar 2010 10:39:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00113NPHNK00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Mar 2010 10:39:17 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH00MI2NPGLD20@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Mar 2010 10:39:16 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IHVPa8006809; Thu, 18 Mar 2010 17:39:16 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-2636453; Thu, 18 Mar 2010 17:39:11 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-71218670; Thu, 18 Mar 2010 17:39:10 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-22429422; Thu, 18 Mar 2010 17:39:10 +0000 (Z) Received: from [10.50.23.149] ([65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o2IHcTON011745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Mar 2010 13:38:32 -0400 (EDT) Date: Thu, 18 Mar 2010 13:38:26 -0400 From: James Carlson Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA256A2.5030701@sun.com> To: "Garrett D'Amore" Cc: stefan.teleman@sun.com, PSARC-ext@sun.com, shell-discuss@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <4BA26512.9070300@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-EATSERVER-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.646sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24C95.6020205@Sun.COM> <4BA2507E.1080900@sun.com> <4BA252FE.1000308@Sun.COM> <4BA256A2.5030701@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1330 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 want. I think the relevant architectural question should be: "if a project team wants to update an existing GNU utility, what must that team do in order to avoid regression for ksh93 users, and how does that project team know that they need to do this?" That's the part that needs to be described adequately, so that any team doing that work doesn't have to stumble in the dark. If the answer is, "they must coordinate first with the ksh93 team," that seems reasonable, but there needs to be _some_ clear answer. I see nothing wrong with silently replacing existing utilities with better-performing ones having exactly the same interface, but I do think it's a problem if some users may accidentally see "old" versions of something that has been updated. (In particular, seeing a newly updated man or GNU info page, and having a new feature listed there not work because the command invocation is redirected by the shell would be pretty confusing.) -- James Carlson 42.703N 71.076W From alan.coopersmith@oracle.com Thu Mar 18 10:47:16 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IHlFvt024218 for ; Thu, 18 Mar 2010 10:47:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2IHlBWj048614; Thu, 18 Mar 2010 11:47:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00225O2QMZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 10:47:14 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH001LXO2PLTE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Mar 2010 10:47:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2IHlDTE004559; Thu, 18 Mar 2010 17:47:13 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2I9EFhh008891; Thu, 18 Mar 2010 17:47:06 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 92680511268934334; Thu, 18 Mar 2010 10:45:34 -0700 Received: from [129.145.155.53] (/129.145.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Mar 2010 10:45:34 -0700 Date: Thu, 18 Mar 2010 10:45:29 -0700 From: Alan Coopersmith Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24FC4.8030402@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA266B9.5050503@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BA2671A.0125:SCFMA4539814,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24D8D.7000008@sun.com> <4BA24FC4.8030402@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 1345 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 >>> utilities the project team will update the corresponding ksh93 built >>> in utility. Should this not be possible the ksh93 project team will >>> remove the mapping. >>> >> So this constrains all future GNU coreutils update cases to coordinate >> with the ksh93 builtins, right? Have those responsible for the GNU >> coreutils agreed to this constraint? Should this be expressed as an >> ARC contract for cross-consolidation agreement of Volatile interfaces? >> >> > > The ksh93 versions adhere to the public interfaces from the GNU > versions. If they change the semantics, then it will require some extra > work, but I'm not sure that a contract properly captures this. Even just having a note added to the SFW metadata file would be better than doing nothing, which goes back to the original question of whether those responsible for the GNU coreutils in SFW have agreed to this or even been made aware of it? -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From gdamore@sun.com Thu Mar 18 10:53:53 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2IHrrM8024269 for ; Thu, 18 Mar 2010 10:53:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2IHrqAm018475 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 10:53:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZH00I01ODSWX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 11:53:52 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZH005APODSTWB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 11:53:52 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2IHrmNn018572 for ; Thu, 18 Mar 2010 10:53:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZH00300O79CI00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 10:53:48 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZH007UMODFI650@fe-sfbay-09.sun.com>; Thu, 18 Mar 2010 10:53:40 -0700 (PDT) Date: Thu, 18 Mar 2010 10:53:39 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA266B9.5050503@oracle.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA268A3.9060202@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24D8D.7000008@sun.com> <4BA24FC4.8030402@sun.com> <4BA266B9.5050503@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1929 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: >>>> 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. Should this not be possible the ksh93 project team will >>>> remove the mapping. >>>> >>>> >>> So this constrains all future GNU coreutils update cases to coordinate >>> with the ksh93 builtins, right? Have those responsible for the GNU >>> coreutils agreed to this constraint? Should this be expressed as an >>> ARC contract for cross-consolidation agreement of Volatile interfaces? >>> >>> >>> >> The ksh93 versions adhere to the public interfaces from the GNU >> versions. If they change the semantics, then it will require some extra >> work, but I'm not sure that a contract properly captures this. >> > Even just having a note added to the SFW metadata file would be better > than doing nothing, which goes back to the original question of whether > those responsible for the GNU coreutils in SFW have agreed to this or > even been made aware of it? > I doubt they have been formally notified. If they have, I'm unaware of it. 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 the /usr/gnu replacements) to come up. The problem is, I'm not sure there is any desire on anyone doing the actual work to revisit the overall architecture surrounding user environments. Even if it is desperately needed. -- Garrett From Norm.Jacobs@Oracle.COM Thu Mar 18 16:57:03 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2INv2AR000825 for ; Thu, 18 Mar 2010 16:57:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2INv1JY011454 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 18:57:02 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZI0010D571BD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 16:57:01 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZI00DMC5718QD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 16:57:01 -0700 (PDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o2INv0hK380829; Thu, 18 Mar 2010 16:57:00 -0700 (PDT) Date: Thu, 18 Mar 2010 18:57:00 -0500 From: Norm Jacobs Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA2BDCC.3090607@Oracle.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LOrHQ5fmxY8ZfdiFfJdHog)" X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 16858 This is a multi-part message in MIME format. --Boundary_(ID_LOrHQ5fmxY8ZfdiFfJdHog) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT 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 sorely needed in the Solaris userland, a blend of POSIX conforming and GNUish commands. Several things concern me about this case. * When I (read any user) explicitly set my PATH to include /usr/bin, /usr/xpg4/bin, /usr/xpg6/bin, ..., I expect that my selection will be honored. I am asking for a specific toolset and expect a bug for bug compatible version. * "default" behaviour should apply across the board here. 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 10:24 AM, 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 Document Author/Supplier: > Author: Olga Kryzhanovska > 1.3 Date of This Document: > 18 March, 2010 > 4. Technical Description > > I'm sponsoring this fast-track request on behalf of the > ksh93-integration project. > Please note that this is an *open* case. > > The release binding is the same as with the ksh93 project: a > patch/micro release of Solaris delivering through ON > Stability levels are as described below. > > > 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 > > Bug/RFE Number(s): > > 6935110 ksh93 needs (more) XPG, GNU built ins > > This case proposes to deliver the following features as a set of > independent putbacks as they become available. Each feature is > self contained and independent of the others, so out of order > and partial putbacks at this granularity should have no adverse > impact on the functionality and behavior of the system as a whole. > > > 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. > > > 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 > > Notes > ----- > Compatibility of AT&T AST ksh93 built in utilities and GNU > coreutils implementations: > Modulo correction bugs in the implementation, we believe that the > ksh93 built in utilities act as a 100% compatible drop in for the > GNU programs sans wording of --help, --version and error message > output (error messages are Not-An-Interface). > > 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. Should this not be possible the ksh93 project team will > remove the mapping. > > > > Part 2: ksh93 built in mappings for /usr/xpg4/bin utilities > ---------------------------------------------------------- > The case proposes to enable the following mappings to ksh93 built in > commands for utilities in /usr/xpg4/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/xpg4/bin binary. > > Interface Stability Description > --------- --------- ----------- > ksh93 '/usr/xpg4/bin/basename' built in Committed POSIX basename utility > ksh93 '/usr/xpg4/bin/egrep' built in Committed POSIX egrep utility > ksh93 '/usr/xpg4/bin/fgrep' built in Committed POSIX fgrep utility > ksh93 '/usr/xpg4/bin/grep' built in Committed POSIX grep utility > ksh93 '/usr/xpg4/bin/id' built in Committed POSIX id utility > ksh93 '/usr/xpg4/bin/rm' built in Committed POSIX rm utility > > > > Part 3: ksh93 built in mappings for /usr/bin utilities > ---------------------------------------------------------- > The case proposes to enable the following mappings to ksh93 built in > commands for utilities in /usr/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/xpg4/bin binary. > > Interface Stability Description > --------- --------- ----------- > ksh93 '/usr/bin/dirname' built in Committed POSIX dirname utility > > > General comments > ---------------- > This case heavily builds on PSARC/2006/550 which was the first > PSARC case to introduce the concept of shell built ins bound > to a path. > > > Future development > ------------------ > The shell project team will file separate ARC case to add the same > shell built ins to bash4, reusing the same code as ksh93 > (libcmd.so.1). > The shell project will provide an API within libcmd.so.1 for other > shells (e.g. bash4) and applications to call the built ins directly. > This API will be available as contracted API until sufficient > experience has been collected and then opened as Committed > interface. > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > --Boundary_(ID_LOrHQ5fmxY8ZfdiFfJdHog) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 sorely needed in the Solaris userland, a blend of POSIX conforming and GNUish commands.

Several things concern me about this case.
  • When I (read any user) explicitly set my PATH to include /usr/bin, /usr/xpg4/bin, /usr/xpg6/bin, ..., I expect that my selection will be honored.  I am asking for a specific toolset and expect a bug for bug compatible version.
  • "default" behaviour should apply across the board here.
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 10:24 AM, 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 Document Author/Supplier:
	 Author:  Olga Kryzhanovska
    1.3  Date of This Document:
	18 March, 2010
4. Technical Description

I'm sponsoring this fast-track request on behalf of the
ksh93-integration project.
Please note that this is an *open* case.

The release binding is the same as with the ksh93 project: a
patch/micro release of Solaris delivering through ON
Stability levels are as described below.


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

Bug/RFE Number(s):

6935110  ksh93 needs (more) XPG, GNU built ins

This case proposes to deliver the following features as a set of
independent putbacks as they become available. Each feature is
self contained and independent of the others, so out of order
and partial putbacks at this granularity should have no adverse
impact on the functionality and behavior of the system as a whole.


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.


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

Notes
-----
Compatibility of AT&T AST ksh93 built in utilities and GNU
coreutils implementations:
Modulo correction bugs in the implementation, we believe that the
ksh93 built in utilities act as a 100% compatible drop in for the
GNU programs sans wording of --help, --version and error message
output (error messages are Not-An-Interface).

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. Should this not be possible the ksh93 project team will
remove the mapping.



Part 2: ksh93 built in mappings for /usr/xpg4/bin utilities
----------------------------------------------------------
The case proposes to enable the following mappings to ksh93 built in
commands for utilities in /usr/xpg4/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/xpg4/bin binary.

Interface                                Stability        Description                             
---------                                ---------        -----------  
ksh93 '/usr/xpg4/bin/basename' built in  Committed        POSIX basename utility
ksh93 '/usr/xpg4/bin/egrep' built in     Committed        POSIX egrep utility
ksh93 '/usr/xpg4/bin/fgrep' built in     Committed        POSIX fgrep utility
ksh93 '/usr/xpg4/bin/grep' built in      Committed        POSIX grep utility
ksh93 '/usr/xpg4/bin/id' built in        Committed        POSIX id utility
ksh93 '/usr/xpg4/bin/rm' built in        Committed        POSIX rm utility



Part 3: ksh93 built in mappings for /usr/bin utilities
----------------------------------------------------------
The case proposes to enable the following mappings to ksh93 built in
commands for utilities in /usr/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/xpg4/bin binary.

Interface                                Stability        Description                             
---------                                ---------        -----------  
ksh93 '/usr/bin/dirname' built in        Committed        POSIX dirname utility


General comments
----------------
This case heavily builds on PSARC/2006/550 which was the first
PSARC case to introduce the concept of shell built ins bound
to a path.


Future development
------------------
The shell project team will file separate ARC case to add the same
shell built ins to bash4, reusing the same code as ksh93
(libcmd.so.1).
The shell project will provide an API within libcmd.so.1 for other
shells (e.g. bash4) and applications to call the built ins directly.
This API will be available as contracted API until sufficient
experience has been collected and then opened as Committed
interface.



6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open

--Boundary_(ID_LOrHQ5fmxY8ZfdiFfJdHog)-- From Alan.Burlison@sun.com Thu Mar 18 17:25:12 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2J0PCjO001037 for ; Thu, 18 Mar 2010 17:25:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2J0PBAT015646 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 17:25:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZI00D0F6HZDG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 18:25:11 -0600 (MDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZI00D086HYD200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 18:25:11 -0600 (MDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2J0P70f023577; Fri, 19 Mar 2010 00:25:07 +0000 (GMT) Received: from vpn-129-150-121-142.uk.sun.com ([129.150.121.142]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1NsQ1T-0007Ko-8W; Fri, 19 Mar 2010 00:25:07 +0000 Date: Fri, 19 Mar 2010 00:25:06 +0000 From: Alan Burlison Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA2BDCC.3090607@Oracle.COM> To: Norm Jacobs Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA2C462.5040201@sun.com> Organization: Oracle MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Thunderbird/3.0.1 Status: RO Content-Length: 583 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 standards(5) mandates specific directory paths for different levels of POSIX etc compliance. I'm not clear how this 'hidden override' mechanism impacts that, an explanation would be helpful. And I don't see any mention of /usr/xpg6/bin in there either. -- Alan Burlison -- From Sebastien.Roy@Sun.COM Thu Mar 18 19:54:56 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2J2sum6002856 for ; Thu, 18 Mar 2010 19:54:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2J2suuR026575 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Mar 2010 19:54:56 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZI00701DFK2G00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 20:54:56 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZI00DR5DFJDA60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 20:54:55 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2J2stkk006096 for ; Fri, 19 Mar 2010 02:54:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZI00300D9PDD00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Mar 2010 20:54:55 -0600 (MDT) Received: from [192.168.1.3] ([unknown] [173.76.16.34]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZI00LUZDF8XX10@mail-amer.sun.com>; Thu, 18 Mar 2010 20:54:45 -0600 (MDT) Date: Thu, 18 Mar 2010 22:54:44 -0400 From: Sebastien Roy Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA2BDCC.3090607@Oracle.COM> Sender: Sebastien.Roy@Sun.COM To: Norm Jacobs Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA2E774.5050701@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 1650 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 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. > > Several things concern me about this case. > > * When I (read any user) explicitly set my PATH to include /usr/bin, > /usr/xpg4/bin, /usr/xpg6/bin, ..., I expect that my selection will > be honored. I am asking for a specific toolset and expect a bug > for bug compatible version. > * "default" behaviour should apply across the board here. > > 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". -Seb From Norm.Jacobs@Oracle.COM Fri Mar 19 01:34:36 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2J8YaN8023562 for ; Fri, 19 Mar 2010 01:34:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2J8YZ7m029644; Fri, 19 Mar 2010 01:34:35 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZI00M05T5NC100@brm-avmta-1.central.sun.com>; Fri, 19 Mar 2010 02:34:35 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZI00A3TT5MNW60@brm-avmta-1.central.sun.com>; Fri, 19 Mar 2010 02:34:34 -0600 (MDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o2J8YWiw119374; Fri, 19 Mar 2010 01:34:33 -0700 (PDT) Date: Fri, 19 Mar 2010 03:34:32 -0500 From: Norm Jacobs Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA2E774.5050701@sun.com> To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, olga.kryzhanovska@gmail.com, shell-discuss@opensolaris.org Message-id: <4BA33718.5010905@Oracle.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5ydNpPhzeV35rLgmd8cwQQ)" X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 12970 This is a multi-part message in MIME format. --Boundary_(ID_5ydNpPhzeV35rLgmd8cwQQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT 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 --Boundary_(ID_5ydNpPhzeV35rLgmd8cwQQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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
--Boundary_(ID_5ydNpPhzeV35rLgmd8cwQQ)-- From sebastien.roy@oracle.com Fri Mar 19 05:20:40 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JCKeje026078 for ; Fri, 19 Mar 2010 05:20:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2JCKduR012045; Fri, 19 Mar 2010 07:20:39 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ006053MFUB00@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 05:20:39 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ006KC3MEK600@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 05:20:38 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2JCKXQf022443; Fri, 19 Mar 2010 12:20:33 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2JCKQ4O013676; Fri, 19 Mar 2010 12:20:27 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 94963201269001196; Fri, 19 Mar 2010 05:19:56 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Mar 2010 05:19:55 -0700 Date: Fri, 19 Mar 2010 08:19:54 -0400 From: Sebastien Roy Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA33718.5010905@Oracle.COM> To: Norm Jacobs Cc: Sebastien Roy , PSARC-ext@sun.com, shell-discuss@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <4BA36BEA.6020407@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BA36C0D.012E:SCFMA4539814,ss=1,fgs=0 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 2046 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" > > 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. Correct: Fully qualified command names do not use built-ins. This is specified by 2006/550. >> 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. 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 not being introduced by this case. That was introduced by PSARC 2006/550. This case is building upon previously approved architecture. -Seb From Norm.Jacobs@Oracle.COM Fri Mar 19 07:58:06 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JEw63X028633 for ; Fri, 19 Mar 2010 07:58:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2JEw3Rb021907; Fri, 19 Mar 2010 09:58:05 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ00F0TAWSU500@brm-avmta-1.central.sun.com>; Fri, 19 Mar 2010 08:58:04 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ00A2YAWRPY30@brm-avmta-1.central.sun.com>; Fri, 19 Mar 2010 08:58:04 -0600 (MDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o2JEw2du168418; Fri, 19 Mar 2010 07:58:02 -0700 (PDT) Date: Fri, 19 Mar 2010 09:58:01 -0500 From: Norm Jacobs Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA36BEA.6020407@oracle.com> To: Sebastien Roy Cc: Sebastien Roy , PSARC-ext@sun.com, shell-discuss@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <4BA390F9.70203@Oracle.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 2323 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 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. > > Correct: Fully qualified command names do not use built-ins. This is > specified by 2006/550. > >>> 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. > > 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 not being introduced by > this case. That was introduced by PSARC 2006/550. This case is > building upon previously approved architecture. > Perhaps I delve slightly into implementation detail here, but the issue of consistency is something that needs to be addressed here and now, not wait for the future. -Norm From gdamore@sun.com Fri Mar 19 08:13:52 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JFDqGQ028839 for ; Fri, 19 Mar 2010 08:13:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2JFDpah035442 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 19 Mar 2010 09:13:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ00H17BN31000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 08:13:51 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ00FHBBN3EA20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 08:13:51 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2JFDpmw024893 for ; Fri, 19 Mar 2010 08:13:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZJ00G00BJLHX00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 08:13:50 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZJ00ABWBN0YV80@fe-sfbay-10.sun.com>; Fri, 19 Mar 2010 08:13:49 -0700 (PDT) Date: Fri, 19 Mar 2010 08:13:48 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA390F9.70203@Oracle.COM> Sender: Garrett.Damore@sun.com To: Norm Jacobs Cc: Sebastien Roy , Sebastien Roy , PSARC-ext@sun.com, shell-discuss@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <4BA394AC.3040608@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1470 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 not being introduced by >> this case. That was introduced by PSARC 2006/550. This case is >> building upon previously approved architecture. >> > > Perhaps I delve slightly into implementation detail here, but the > issue of consistency is something that needs to be addressed here and > now, not wait for the future. 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 $PATH of new users is a bit of a travesty, and I'm of the opinion that we should reexamine *that* particular decision, in which case much of the motivation behind *this* case comes into question. (If /usr/gnu isn't the default for most users, then there is little motivation to provide builtin wrappers for them.) 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 GNU warts. -- Garrett From gsf@research.att.com Fri Mar 19 08:28:14 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JFSEYa028984 for ; Fri, 19 Mar 2010 08:28:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2JFS9nA024420; Fri, 19 Mar 2010 08:28:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ00H07CAPV400@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 08:28:01 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ00FBPCAPED30@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 08:28:01 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2JFREp4026581; Fri, 19 Mar 2010 15:28:00 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-2611989; Fri, 19 Mar 2010 15:27:59 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-48803259; Fri, 19 Mar 2010 15:27:59 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay4i.sun.com with ESMTP id BT-MMP-64003176; Fri, 19 Mar 2010 15:27:59 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-blue.research.att.com (Postfix) with ESMTP id 4D2E1EF778; Fri, 19 Mar 2010 11:27:59 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id o2JFRwOV017870; Fri, 19 Mar 2010 11:27:58 -0400 Date: Fri, 19 Mar 2010 11:27:58 -0400 From: Glenn Fowler Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] To: Norm.Jacobs@Oracle.COM, shell-discuss@opensolaris.org Cc: gd78059@sac.sfbay.sun.com, PSARC-ext@sun.com, sebastien.roy@Oracle.COM, Sebastien.Roy@sun.com Message-id: <201003191527.o2JFRwOV017870@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.096sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> Status: RO Content-Length: 1392 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 $PATH of new users is a bit of a travesty, and > I'm of the opinion that we should reexamine *that* particular decision, > in which case much of the motivation behind *this* case comes into > question. (If /usr/gnu isn't the default for most users, then there is > little motivation to provide builtin wrappers for them.) > 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 GNU warts. dgk are discussing this right now we had somehow missed the detail that the proposed ksh builtin binding dir is "/usr/gnu/bin" just because a libcmd builtin handles some gnu options does not make it gnu there are most likely gnu features that libcmd builtins will never implement e.g., the gnu getopt(3) "feature" that allows options to appear after operands once we solidify the ideas where should we post, and under what subject? -- Glenn Fowler -- at&t Research, Florham Park NJ -- From gdamore@sun.com Fri Mar 19 08:31:23 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JFVNQH029049 for ; Fri, 19 Mar 2010 08:31:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2JFVL5n026452 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 19 Mar 2010 08:31:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ00803CFR4K00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 08:31:03 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ00A84CFR3V70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 08:31:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2JFV3Sl028212 for ; Fri, 19 Mar 2010 08:31:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZJ00800C614T00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 08:31:03 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZJ00AYVCFFYVC0@fe-sfbay-10.sun.com>; Fri, 19 Mar 2010 08:30:52 -0700 (PDT) Date: Fri, 19 Mar 2010 08:30:51 -0700 From: "Garrett D'Amore" Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <201003191527.o2JFRwOV017870@penguin.research.att.com> Sender: Garrett.Damore@sun.com To: Glenn Fowler Cc: Norm.Jacobs@Oracle.COM, shell-discuss@opensolaris.org, gd78059@sac.sfbay.sun.com, PSARC-ext@sun.com, sebastien.roy@Oracle.COM, Sebastien.Roy@sun.com Message-id: <4BA398AB.1060701@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> <201003191527.o2JFRwOV017870@penguin.research.att.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1801 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 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, >> in which case much of the motivation behind *this* case comes into >> question. (If /usr/gnu isn't the default for most users, then there is >> little motivation to provide builtin wrappers for them.) >> > >> 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 GNU warts. >> > dgk are discussing this right now > we had somehow missed the detail that the proposed ksh builtin binding dir > is "/usr/gnu/bin" > > just because a libcmd builtin handles some gnu options does not make it gnu > there are most likely gnu features that libcmd builtins will never implement > e.g., the gnu getopt(3) "feature" that allows options to appear after operands > > once we solidify the ideas where should we post, and under what subject? > Reply to this message. I'm going to put this case on waiting-needs-spec. My guess is that ultimately the thing to do will be to "not" override the GNU builtins, because you're not providing truly 100% compatible drop-ins. (And it sounds like unless you're willing to introduce any bugs that are present in the GNU versions, you never will be.) - Garrett From johansen@sun.com Fri Mar 19 15:52:29 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JMqTeA006197 for ; Fri, 19 Mar 2010 15:52:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2JMqRUf046873; Fri, 19 Mar 2010 16:52:28 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ00M0DWVFYB00@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 15:52:27 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ00LPYWVF1Y90@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 15:52:27 -0700 (PDT) Received: from kotuk.sfbay.sun.com (kotuk.SFBay.Sun.COM [129.146.228.79]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2JMqRKW028023; Fri, 19 Mar 2010 15:52:27 -0700 (PDT) Received: from kotuk.sfbay.sun.com (kotuk.local [127.0.0.1]) by kotuk.sfbay.sun.com (8.14.4+Sun/8.14.4) with ESMTP id o2JMqR3o012387; Fri, 19 Mar 2010 15:52:27 -0700 (PDT) Received: (from johansen@localhost) by kotuk.sfbay.sun.com (8.14.4+Sun/8.14.4/Submit) id o2JMqQ2O012378; Fri, 19 Mar 2010 15:52:26 -0700 (PDT) Date: Fri, 19 Mar 2010 15:52:26 -0700 From: johansen@sun.com Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA394AC.3040608@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <20100319225226.GG11718@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1573 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 business and architecture cases for having the default userland be approachable by the majority of users of other popular unix-like operating systems. The /usr/gnu isn't the default in my path either, but it makes a lot of sense to present a userland that's familiar to users of Linux, and similar environments. Anyone is free to create a distro with a different default shell, or default path. Anyone is free to change their path as well as their shell. Your fixation on /usr/gnu's presence in the default path isn't productive. Why make it harder to get users from Linux and elsewhere to adopt Solaris? > ... in which case much of the motivation behind *this* case comes into > question. (If /usr/gnu isn't the default for most users, then there > is little motivation to provide builtin wrappers for them.) I disagree. Modulo the issues about the profile shell, I see no reason why it matters that the ARC delve into the minutia of shell builtins. In general, that's an implementation or configuration detail of the shell. I would recommend against derailing this case in favor of one about a grand shell [re-]architecture. We should be making it easier add different shells for Solaris. Using this case as an opportunity to rail about Gnu is just divisive. -j From gdamore@sun.com Fri Mar 19 16:08:13 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JN8Cfw006635 for ; Fri, 19 Mar 2010 16:08:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2JN8BYi056589 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 19 Mar 2010 17:08:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ0062HXLOC700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 16:08:12 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ00GY7XLNUCB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 16:08:11 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2JN8BtJ023956 for ; Fri, 19 Mar 2010 16:08:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZJ00G00XA0WY00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 19 Mar 2010 16:08:11 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZJ00I6JXLMZGE0@fe-sfbay-09.sun.com>; Fri, 19 Mar 2010 16:08:11 -0700 (PDT) Date: Fri, 19 Mar 2010 16:08:09 -0700 From: "Garrett D'Amore" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <20100319225226.GG11718@eng.sun.com> Sender: Garrett.Damore@sun.com To: johansen@sun.com Cc: PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <4BA403D9.5060108@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> <20100319225226.GG11718@eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3439 On 03/19/10 03:52 PM, johansen@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... >> > This is merely one opinion. There are compelling business and > architecture cases for having the default userland be approachable by > the majority of users of other popular unix-like operating systems. The > /usr/gnu isn't the default in my path either, but it makes a lot of > sense to present a userland that's familiar to users of Linux, and > similar environments. > Approachable (and even familiar) does not necessarily == /usr/gnu. It does mean having the main command flags work the same way that people coming from foreign environments (and not just Linux, but also *BSD and maybe other platforms like AIX or HPUX) are used to. > Anyone is free to create a distro with a different default shell, or > default path. Anyone is free to change their path as well as their > shell. Your fixation on /usr/gnu's presence in the default path isn't > productive. Why make it harder to get users from Linux and elsewhere to > adopt Solaris? > I'm not proposing that it should be. I'm proposing that putting /usr/gnu first is not necessarily the only way to achieve that goal. 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 these goals is to provide these 3rd party tools. Its more offensive to me specifically because there is no good reason why we can't use tools from the ksh93 community (who seems to be a lot more willing to work with us on key engineering issues than the GNU folks who are mostly fixated on Linux) to achieve this. 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. Which group do you think contributes more towards the $$ that pay our salaries? > >> ... in which case much of the motivation behind *this* case comes into >> question. (If /usr/gnu isn't the default for most users, then there >> is little motivation to provide builtin wrappers for them.) >> > I disagree. Modulo the issues about the profile shell, I see no reason > why it matters that the ARC delve into the minutia of shell builtins. > In general, that's an implementation or configuration detail of the shell. > I guess reasonable people can disagree here. The points have been made that these drop ins are not 100% compatible drop ins... they have ever so slightly differing interfaces. While normal folks should not care about the differences (they are so tiny, like the format of --version's output), there are situations where it can matter. That makes it a matter of concern for ARC. > I would recommend against derailing this case in favor of one about a > grand shell [re-]architecture. We should be making it easier add > different shells for Solaris. Using this case as an opportunity to rail > about Gnu is just divisive. > The case isn't derailed. Its waiting need spec. At the (more or less) request of the upstream technology supplier. - Garrett From johansen@sun.com Fri Mar 19 16:26:43 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2JNQhp4006892 for ; Fri, 19 Mar 2010 16:26:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2JNQgE5001420; Fri, 19 Mar 2010 17:26:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZJ00203YGI9C00@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 16:26:42 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZJ000G4YGHWW10@nwk-avmta-2.sfbay.sun.com>; Fri, 19 Mar 2010 16:26:41 -0700 (PDT) Received: from kotuk.sfbay.sun.com (kotuk.SFBay.Sun.COM [129.146.228.79]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2JNQfo0011802; Fri, 19 Mar 2010 16:26:41 -0700 (PDT) Received: from kotuk.sfbay.sun.com (kotuk.local [127.0.0.1]) by kotuk.sfbay.sun.com (8.14.4+Sun/8.14.4) with ESMTP id o2JNQfSS012415; Fri, 19 Mar 2010 16:26:41 -0700 (PDT) Received: (from johansen@localhost) by kotuk.sfbay.sun.com (8.14.4+Sun/8.14.4/Submit) id o2JNQf2b012406; Fri, 19 Mar 2010 16:26:41 -0700 (PDT) Date: Fri, 19 Mar 2010 16:26:41 -0700 From: johansen@sun.com Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA403D9.5060108@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: <20100319232641.GH11718@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> <20100319225226.GG11718@eng.sun.com> <4BA403D9.5060108@sun.com> User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1831 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 these goals is to provide > these 3rd party tools. Its more offensive to me specifically > because there is no good reason why we can't use tools from the > ksh93 community (who seems to be a lot more willing to work with us > on key engineering issues than the GNU folks who are mostly fixated > on Linux) to achieve this. Instead of re-inventing the wheel at every opportunity, it makes more sense to take the open source projects that have wide acceptance and incorporate them into our product. I think that both ksh93 and gnu fall into this category. It's much better for us to focus our engineering efforts on areas where we can actually differentiate our product from our competitors. I don't have a problem with ksh93 or the builtins, nor am I advocating an entirely GNU userland. What I am suggesting, however, is that the folks who decided to put /usr/gnu in the default path did talk to our customers, and also took note of the fact that Linux is widely adoped across the industry. > 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. This is a false dilemma. It should be entirely possible for customers to configure whatever default path they desire and deploy that in their enterprise via AI. > Which group do you think contributes more towards the $$ that pay our > salaries? I would love to argue this point with you, but it's not appropriate to discuss it on a public mailing list. -j From iszczesniak@gmail.com Mon Mar 22 05:31:44 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2MCVhKS005858 for ; Mon, 22 Mar 2010 05:31:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2MCVgdn028339; Mon, 22 Mar 2010 05:31:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZO00H09O4V5600@brm-avmta-1.central.sun.com>; Mon, 22 Mar 2010 06:31:43 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZO00FIXO4TA210@brm-avmta-1.central.sun.com>; Mon, 22 Mar 2010 06:31:41 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2MC9xWh002005; Mon, 22 Mar 2010 12:31:40 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay11i.sun.com with ESMTP id BT-MMP-1940244; Mon, 22 Mar 2010 12:31:40 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-80041072; Mon, 22 Mar 2010 12:31:40 +0000 (Z) Received: from mail-bw0-f225.google.com ([209.85.218.225] [209.85.218.225]) by relay1i.sun.com with ESMTP id BT-MMP-14146932; Mon, 22 Mar 2010 12:31:40 +0000 (Z) Received: by bwz25 with SMTP id 25so3740961bwz.8 for ; Mon, 22 Mar 2010 05:31:39 -0700 (PDT) Received: by 10.204.2.210 with SMTP id 18mr2557664bkk.15.1269261098846; Mon, 22 Mar 2010 05:31:38 -0700 (PDT) Date: Mon, 22 Mar 2010 13:31:38 +0100 From: "I. Szczesniak" Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA40F33.1030408@oracle.com> To: Shells discussion Cc: johansen@sun.com, PSARC-EXT@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2r5YO1UvJEdmiGgnJi155jI1vhve3clMW/nUOZz58ls=; b=uBoPkI/7KnooMTt44UjQXbI1rxtQFRDewHaNMtHMxY02s1CdDkaF/7xz22qFPG6SP/ jsOmNJhJpxZa2hsRAOeLtvTxSx0ERdWOlpb55pSrRvIABoMwK1Fe+gJtt4YIPOmB3heJ oyMUQr4ypbSDsRpluGs01iZELDVkxzxL1ukF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gG22r5ZHWKVDLYk8Yf27SEEcCC56Zzz/kSUQkV+2HdHdu6WSg4jX+Jxbrc2ODL182t kY5J6DoYEm0IuAqOCLtNd9zjODzT2KNtFNF50lTT84cF8Mjq+SiyyzKvzl6vKONmQrqt veaBuwD6qROC0PFJTfJyD3j1qQB3Yb9No3Xd0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> <20100319225226.GG11718@eng.sun.com> <4BA403D9.5060108@sun.com> <20100319232641.GH11718@eng.sun.com> <4BA40D2F.2040601@sun.com> <4BA40F33.1030408@oracle.com> Status: RO Content-Length: 693 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 forward >> a case to change this if only to cause the conversation (that I think >> didn't happen) to occur. > > PSARC already has that case under review - PSARC 2010/067. Does a closed ARC case even matter? I don't think a non-public ARC case should be allowed to affect an open source project at all. Not at least if ARC wants to be taken serious in the future. Irek From iszczesniak@gmail.com Mon Mar 22 05:35:51 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2MCZptZ005900 for ; Mon, 22 Mar 2010 05:35:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2MCZmlk019085; Mon, 22 Mar 2010 07:35:50 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZO00331OBPZF00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Mar 2010 05:35:49 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZO001VWOBN1700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Mar 2010 05:35:47 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2MCZlPf007792; Mon, 22 Mar 2010 12:35:47 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay44i.sun.com with ESMTP id BT-MMP-2750530; Mon, 22 Mar 2010 12:35:47 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-51394834; Mon, 22 Mar 2010 12:35:47 +0000 (Z) Received: from mail-bw0-f225.google.com ([209.85.218.225] [209.85.218.225]) by relay4i.sun.com with ESMTP id BT-MMP-21323638; Mon, 22 Mar 2010 12:35:46 +0000 (Z) Received: by mail-bw0-f225.google.com with SMTP id 25so3744197bwz.8 for ; Mon, 22 Mar 2010 05:35:32 -0700 (PDT) Received: by 10.204.32.77 with SMTP id b13mr8063735bkd.113.1269261330267; Mon, 22 Mar 2010 05:35:30 -0700 (PDT) Date: Mon, 22 Mar 2010 13:35:30 +0100 From: "I. Szczesniak" Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: To: Shells discussion Cc: johansen@sun.com, "Garrett D'Amore" , PSARC-EXT@sun.com, =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xZO0IFdwo2u7P9BolZaPo/W+dMHQc8cKHfRuAxCjOtg=; b=aMqPg7h9WdwnxzT0v53lL8G2Enpr71UKsVJC9DFrVPFsNqirmWu9kawG6ME7kmYAgE SkdUY38RNmOfAOkDNvUOlXjYU/LaIHvZkLVBvELaKhHrDHfliQcIaODcD+cvtWqQMS+N 5WFp4nDvOc+4quSaZdkI5mVBgwzkv3glnyZvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MsZr7lojAqsnE9XyYzk57t0To9qU7ZR84Pzpd1/CdAMu4SShEHE03rxPVMXiryR3z6 n64CJ+FVe6WXDkcgGv+7HTkG5TOzXk/b5LFxAP81csZJjoLSuf79xU44iGfRR2+nKuQr zLEv4CyCKKmJZUZ9j5HzXxusPNr0joCq5gC9Q= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.072sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> <20100319225226.GG11718@eng.sun.com> <4BA403D9.5060108@sun.com> <20100319232641.GH11718@eng.sun.com> Status: RO Content-Length: 2033 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 good >>> innovations (like shell builtins) because some people feel its >>> critical that the only way to achieve these goals is to provide >>> these 3rd party tools. Its more offensive to me specifically >>> because there is no good reason why we can't use tools from the >>> ksh93 community (who seems to be a lot more willing to work with us >>> on key engineering issues than the GNU folks who are mostly fixated >>> on Linux) to achieve this. >> >> Instead of re-inventing the wheel at every opportunity, it makes more >> sense to take the open source projects that have wide acceptance and >> incorporate them into our product. I think that both ksh93 and gnu fall >> into this category. It's much better for us to focus our engineering >> efforts on areas where we can actually differentiate our product from >> our competitors. >> >> I don't have a problem with ksh93 or the builtins, nor am I advocating >> an entirely GNU userland. What I am suggesting, however, is that the >> folks who decided to put /usr/gnu in the default path did talk to our >> customers, and also took note of the fact that Linux is widely adoped >> across the industry. > > Yet now, I see (at least online) complaints because the 'default' > (GNU) tools can't actually make use of the features that differentiate > Opensolaris. Why are we encouraging defaults that hide the features > that set us apart from the others? The long term goal [1] for the POSIX community is to add the missing features from BSD and GNU to the utilities in /usr/bin, using the AST tools as template. I do not think that /usr/gnu/bin in $PATH matters then. [1] Depending how fast Oracle will sponsor the putbacks from Olga. Irek From iszczesniak@gmail.com Mon Mar 22 06:11:48 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2MDBmtI006434 for ; Mon, 22 Mar 2010 06:11:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2MDBkhp015604; Mon, 22 Mar 2010 07:11:46 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZO00C09PZMZC00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Mar 2010 06:11:46 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZO0018LPZK1G30@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Mar 2010 06:11:44 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2MD7exM005839; Mon, 22 Mar 2010 13:11:44 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-1942961; Mon, 22 Mar 2010 13:11:44 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-77896900; Mon, 22 Mar 2010 13:11:44 +0000 (Z) Received: from mail-bw0-f225.google.com ([209.85.218.225] [209.85.218.225]) by relay1i.sun.com with ESMTP id BT-MMP-12863322; Mon, 22 Mar 2010 13:11:43 +0000 (Z) Received: by mail-bw0-f225.google.com with SMTP id 25so3779509bwz.8 for ; Mon, 22 Mar 2010 06:11:34 -0700 (PDT) Received: by 10.204.32.15 with SMTP id a15mr3775820bkd.117.1269263494503; Mon, 22 Mar 2010 06:11:34 -0700 (PDT) Date: Mon, 22 Mar 2010 14:11:34 +0100 From: "I. Szczesniak" Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <20100319232641.GH11718@eng.sun.com> To: johansen@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, shell-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/sIdoFH7yUXz5BABdPSpRcIXvbb12NO7wR8giO6bg0M=; b=bTm4vObphE+oAPiPqoS1TuvSTgp2Jhx4YFpdosxpHIipmFrYrNt9eoAdynJAw/s6c7 DLYqp9Xrnl8U4+dHu4gPd74Eh2yDl4Wf9JwMg+j33aZNRNf6LVYeulT3QXBbIHA6MJh+ Qa6Q4v+rqWX8y2RtwO5Vv6ZUw4mGJapyeRqIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SJB6b45eefXCJWES1ptvumR3aUmKw0N/IPxjDbt1A4ka74PshXPrbiz84AJ8+tL2Dk JnzRZ+LplDrKpGnn8nStmF55H8S3arbTiNPs1X1iB/wnuKhvVucbXjajGPYaqveCpb+c NDKRvt2WOFd8tigzdbReG1pLRKr8P5D6HcZqE= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.090sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> <20100319225226.GG11718@eng.sun.com> <4BA403D9.5060108@sun.com> <20100319232641.GH11718@eng.sun.com> Status: RO Content-Length: 3518 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 people feel its >> critical that the only way to achieve these goals is to provide >> these 3rd party tools. Its more offensive to me specifically >> because there is no good reason why we can't use tools from the >> ksh93 community (who seems to be a lot more willing to work with us >> on key engineering issues than the GNU folks who are mostly fixated >> on Linux) to achieve this. > > Instead of re-inventing the wheel at every opportunity, it makes more > sense to take the open source projects that have wide acceptance and > incorporate them into our product. I think that both ksh93 and gnu fall > into this category. It's much better for us to focus our engineering > efforts on areas where we can actually differentiate our product from > our competitors. > > I don't have a problem with ksh93 or the builtins, nor am I advocating > an entirely GNU userland. What I am suggesting, however, is that the > folks who decided to put /usr/gnu in the default path did talk to our > customers, Yes, they did. But they ignored our counsel. Adopting GNU coreutils as default or replacements for /usr/bin is not the answer (and never was). Sun needs a community centric progressive development and adopt POSIX, BSD and GNU features and semantics and not drop in GNU coreutils in the current swallow&die manner. > and also took note of the fact that Linux is widely adoped > across the industry. BSD is widely adopted in the industry, too. Many servers run FreeBSD and many embedded machines run NetBSD. Why was /usr/bsd/bin not adopted instead of /usr/gnu/bin? Sun's management seems to have a obsession with Linux, doesn't bother to look at alternatives and abandoned its own development of the userland utilities (there won't be a UNIX certification for Opensolaris) and now even starts to beat the community which has developed an alternative solution. The real strength of Linux is its community, the *OPEN* development process (not the behind-the-closed-curtain ARC process, i.e. 2010/067) and cooperation. Sun's management still has to learn that. Or Opensolaris will FAIL. >> 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. > > This is a false dilemma. It should be entirely possible for customers > to configure whatever default path they desire and deploy that in their > enterprise via AI. Possible. Yes. Yet it's the *default* configuration we're discussing here. A *default* which broke too many things on my companies side. Guess why we did not port our applications from Solaris 10 to Opensolaris yet? The costs are too high. >> Which group do you think contributes more towards the $$ that pay our >> salaries? > > I would love to argue this point with you, but it's not appropriate to > discuss it on a public mailing list. What is cheaper for Sun? Put /usr/gnu/bin in front of PATH and break almost all user scripts or progressively enhance the utilities in /usr/bin to adopt BSD and GNU features with POSIX as foundation. The latter sounds like the better (and cheaper!) alternative as Opensolaris has already the POSIX community for that purpose. Irek From iszczesniak@gmail.com Mon Mar 22 06:27:22 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2MDRM3d006560 for ; Mon, 22 Mar 2010 06:27:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2MDRL5V015112; Mon, 22 Mar 2010 06:27:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZO00G07QPLXJ00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Mar 2010 06:27:21 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZO001DLQPK1G40@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Mar 2010 06:27:20 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2MDM6i6018958; Mon, 22 Mar 2010 13:27:19 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-2845311; Mon, 22 Mar 2010 13:27:19 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-80161733; Mon, 22 Mar 2010 13:27:19 +0000 (Z) Received: from mail-bw0-f225.google.com ([209.85.218.225] [209.85.218.225]) by relay1i.sun.com with ESMTP id BT-MMP-31704108; Mon, 22 Mar 2010 13:27:17 +0000 (Z) Received: by bwz25 with SMTP id 25so3795073bwz.8 for ; Mon, 22 Mar 2010 06:26:28 -0700 (PDT) Received: by 10.204.25.209 with SMTP id a17mr2590914bkc.104.1269264387378; Mon, 22 Mar 2010 06:26:27 -0700 (PDT) Date: Mon, 22 Mar 2010 14:26:27 +0100 From: "I. Szczesniak" Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA398AB.1060701@sun.com> To: Shells discussion Cc: Glenn Fowler , Norm.Jacobs@oracle.com, PSARC-ext@sun.com, Sebastien.Roy@sun.com, sebastien.roy@oracle.com, gd78059@sac.sfbay.sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sB4P0pbqvshcviYCnDNZXdiw8pc6z47F3Pg0JRykOA0=; b=MvMBGeocuBVSwaNj5FCAW3M5C3iWncAjXWsx3SAcgeW5GMT+PyCM5r80roYCn29YVD rcH+nQ9R6ohVKAcucRN8bk1qdZ51YagJdiAY1nK9HXOJEOYI4d1q3dFfNQLOUQYlF6Kx cTBiUiYByvfxHPODZHPh0hMzihEqhFIoK1J6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KQ0Ph65tfIn4jBBq0YYSmFh7wVlKvP6D6SAbWLAJpfJPDzkgXmT25ON8ZFLo5EF9Zc wLK86iBOC5EyMygoyYDCU+lDnTW/jW6ekm7DV6hmfgb7Fh33eCnGJalTbK6+tH4xy/DZ Et8hRfg0mC1wr6ieGYfUXcFvTiFcbaDrrrYF4= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.075sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA2BDCC.3090607@Oracle.COM> <4BA2E774.5050701@sun.com> <4BA33718.5010905@Oracle.COM> <4BA36BEA.6020407@oracle.com> <4BA390F9.70203@Oracle.COM> <4BA394AC.3040608@sun.com> <201003191527.o2JFRwOV017870@penguin.research.att.com> <4BA398AB.1060701@sun.com> Status: RO Content-Length: 2245 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 new case to examine >>> userland shell architecture be created. 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, >>> in which case much of the motivation behind *this* case comes into >>> question. (If /usr/gnu isn't the default for most users, then there is >>> little motivation to provide builtin wrappers for them.) >>> >> >> >>> >>> 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 GNU warts. >>> >> >> dgk are discussing this right now >> we had somehow missed the detail that the proposed ksh builtin binding dir >> is "/usr/gnu/bin" >> >> just because a libcmd builtin handles some gnu options does not make it >> gnu >> there are most likely gnu features that libcmd builtins will never >> implement >> e.g., the gnu getopt(3) "feature" that allows options to appear after >> operands >> >> once we solidify the ideas where should we post, and under what subject? >> > > Reply to this message. I'm going to put this case on waiting-needs-spec. > My guess is that ultimately the thing to do will be to "not" override the > GNU builtins, because you're not providing truly 100% compatible drop-ins. > (And it sounds like unless you're willing to introduce any bugs that are > present in the GNU versions, you never will be.) Glenn may be confusing glibc getopt(3) with coreutils getopt. I've been experimenting with ksh93 and its shell builtins and I am not able to find a difference except that cut, paste and friends accept multibyte characters (GNU coreutils spew errors like /usr/gnu/bin/cut: the delimiter must be a single character) while GNU coreutils do not. Irek From iszczesniak@gmail.com Mon Mar 22 06:38:13 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2MDcDxE006601 for ; Mon, 22 Mar 2010 06:38:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2MDcCjQ024902 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 22 Mar 2010 08:38:12 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZO00J2RR7OAY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 22 Mar 2010 06:38:12 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZO001SYR7N1A50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 22 Mar 2010 06:38:12 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2MDZLvo022581 for ; Mon, 22 Mar 2010 13:38:11 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-2775462 for PSARC-ext@sun.com; Mon, 22 Mar 2010 13:38:11 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-51681150 for PSARC-ext@sun.com; Mon, 22 Mar 2010 13:38:11 +0000 (Z) Received: from mail-bw0-f225.google.com ([209.85.218.225] [209.85.218.225]) by relay4i.sun.com with ESMTP id BT-MMP-21416934 for PSARC-ext@sun.com; Mon, 22 Mar 2010 13:38:11 +0000 (Z) Received: by bwz25 with SMTP id 25so3806637bwz.8 for ; Mon, 22 Mar 2010 06:37:21 -0700 (PDT) Received: by 10.204.9.23 with SMTP id j23mr797820bkj.132.1269265041237; Mon, 22 Mar 2010 06:37:21 -0700 (PDT) Date: Mon, 22 Mar 2010 14:37:21 +0100 From: "I. Szczesniak" Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: To: Shells discussion Cc: Darren J Moffat , PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AaGICqcvE2geGPzdoYP0mHK6LtsLxwhaQnct4KFNuCg=; b=YBHb7xlS7qzd3KCtl4pjDAheJcgNaUY4N5xskgu8uGFPVW+t14S9/XbvK3UihB3gfv U2j9e7UNRu9IytQCFPI99PjmKQFCquBx0CISeJZ2YCYatnaTJpCR8Rt8CCsgPYWdRgTt LtbXcR+xT1sacY0+Hx0qcPe44Up7bbCkKT19A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ds81j6+W3SxArVlHaXrLRCohcNuZnSTp/zCOdFUNpFEoQV7PNCG0UCVskrncQoQWa3 0nvM++ANU5cV4Sx8f/wEfDP4Z+bcfMkN3Ssj2Oaxd8BPrZsL1QIW1BomqubXoFeEj1ZE uixcfo9jrLzzhX54nJOCKyOOtNjDkpmwevcKQ= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.065sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> Status: RO Content-Length: 1128 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 ? > > No. It's explicitly stated that --version in particular is worded differently. > I've seen configure scripts and applications take apart --version output > in order to divine version-specific behaviour This will break anyway in the future. GNU coreutils changed the 'wording' of the --version output a couple of times in the past. ARC...ARC... the ARC case for GNU coreutils nor the manpages specify a specific wording 'syntax'. Sounds like from an ARC perspective this does not matter. >> If so then I wonder why we are even shipping the GNU >> ones. > > Because that's what many users and applications expect. And there's > a world outside ksh93. Right. But within ksh93 scripts this optimization makes sense. And the tools in /usr/bin still require modernisation. Irek From iszczesniak@gmail.com Mon Mar 22 06:58:51 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2MDwpw3006947 for ; Mon, 22 Mar 2010 06:58:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2MDwn8J048324 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 22 Mar 2010 07:58:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZO0014TS622H00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 22 Mar 2010 06:58:50 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZO001GGS611L60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 22 Mar 2010 06:58:49 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2MDoida008759 for ; Mon, 22 Mar 2010 13:58:49 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-376627 for PSARC-ext@sun.com; Mon, 22 Mar 2010 13:58:49 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-79970680 for PSARC-ext@sun.com; Mon, 22 Mar 2010 13:58:49 +0000 (Z) Received: from mail-bw0-f225.google.com ([209.85.218.225] [209.85.218.225]) by relay1i.sun.com with ESMTP id BT-MMP-31765175 for PSARC-ext@sun.com; Mon, 22 Mar 2010 13:58:48 +0000 (Z) Received: by bwz25 with SMTP id 25so3829779bwz.8 for ; Mon, 22 Mar 2010 06:58:38 -0700 (PDT) Received: by 10.204.152.17 with SMTP id e17mr4409847bkw.105.1269266318027; Mon, 22 Mar 2010 06:58:38 -0700 (PDT) Date: Mon, 22 Mar 2010 14:58:37 +0100 From: "I. Szczesniak" Subject: Re: [shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA25A39.4030804@sun.com> To: Shells discussion Cc: Peter Tribble , PSARC-ext@sun.com, Darren J Moffat , "Garrett D'Amore - sun microsystems" , =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= , Roland Mainz Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jTfVZz3oKn9y97QiN/asvgxUeoxd8B++2C7DE4U1gwU=; b=GqV5J/OyEoRavyBR6/SnK86jqFgNYe902pcDcPRSD1X8iM1NkPTsWMi7fPwKbwHKZS w2Ypf8rMSmo4iebPletI4E23i5p1rB4pfK5S7Dg2/DFwfq2EkO7dRTH8pHfCrAvW/30I 1x3bxjslo4WncHVBmlZqsJBoa7quPu2iSkLl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=joh17UTMHcaAOEM0oz9Eayx2tM/udYvv4WcIDCznSSb5I6HhMdRYLcPJntoMF5S/WY MjjyjyfpUNyXBqcfjzBi3diwP3BOVmekKzPpzhGmuWLmeztoNRVY5ZAKPZWQMcpHjtMU +yFRBkNPNqe81jUaWH8i2O+Ew6ooO7owxjUvI= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> <4BA25A39.4030804@sun.com> Status: RO Content-Length: 1859 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 most well-maintained POSIX > conforming implementation, and offers all the features people seem to want, > so that seems like the best choice. +1 > 2) /usr/gnu versions would still ship for people who *insist*, but we should > not be advocating GNU versions in preference to the POSIX conforming > versions. /usr/gnu has no place (IMO) on the default user's path. The fact > that we put it there at all now is just a crutch to workaround the lack of > investment in the aging (rotting!) Sun userland (ksh93 not included) Oracle could hire either Olga Kryzhanovska or Roland Mainz to work on the Solaris userland. Both are experts in the area and the driving force behind the ksh93 and POSIX community efforts. > 3) IMO, the configuration of builtins should be enabled the same way that > other PATH elements are enabled -- via a new PATH element. I would not mind > seeing /usr/ksh93/bin. This could be prepended to the default PATH for new > users. It would provide POSIX conforming (plus any of the popular desired > features from GNU, BSD, etc.) implementations of commands, but would also > allow for simple builtins to be used by libcmd and ksh93. Since ksh93 uses > libcmd, there would be *zero* functional difference apart from the savings > of a fork/exec, and everyone would be happy. > > This whole nonsense IMO, comes about because the ksh93 folks want to enable > higher performance, but someone decided that /usr/gnu should be at the front > of default users PATHs. I think *that* decision was busted. Right. +1 Irek From pickychris@googlemail.com Sat Mar 27 08:39:41 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2RFdeVg023658 for ; Sat, 27 Mar 2010 08:39:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2RFde9O028982 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 27 Mar 2010 08:39:40 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZY00803664VD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 27 Mar 2010 08:39:40 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZY002KV65S8H30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 27 Mar 2010 08:39:40 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2RFSgO5022408 for ; Sat, 27 Mar 2010 15:39:27 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-741816 for PSARC-ext@sun.com; Sat, 27 Mar 2010 15:39:27 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-93060111 for PSARC-ext@sun.com; Sat, 27 Mar 2010 15:39:27 +0000 (Z) Received: from mail-gw0-f49.google.com ([74.125.83.49] [74.125.83.49]) by relay1i.sun.com with ESMTP id BT-MMP-14949916 for PSARC-ext@sun.com; Sat, 27 Mar 2010 15:39:27 +0000 (Z) Received: by gwb20 with SMTP id 20so623130gwb.8 for ; Sat, 27 Mar 2010 08:39:27 -0700 (PDT) Received: by 10.100.45.8 with HTTP; Sat, 27 Mar 2010 08:39:27 -0700 (PDT) Received: by 10.101.148.6 with SMTP id a6mr4040421ano.150.1269704367170; Sat, 27 Mar 2010 08:39:27 -0700 (PDT) Date: Sat, 27 Mar 2010 16:39:27 +0100 From: Chris Pickett Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: <4BA24991.5080201@opensolaris.org> Sender: pickychris@googlemail.com To: Darren J Moffat Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, shell-discuss@opensolaris.org, Roland Mainz Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=j45ivRFg0H8L8eaEpc0MziuFe3DmLiyVME7t+uHq9CI=; b=mvUi3YOcY7quCLu0b+N8TLi+q3Eyparu5Skw25UyzNG3W3vQQnWC85vngFPlkw2byD Rad+lu0hTxQazoXgEN8cxF8sKLLD5HSMwTFRfYQJI3hMEi3PXEzkwMyuJJKZfyFeMM3t lSd2eZR1iQ5iXkYvlBJwcRvES6Yg2AxzISpts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=EhSQhfRLhpacrcECS9WT/Iex+/vRmfBzTGDVjG7Y3Poy2izLp7J94vAOo4Pm6rKnIm rePXsslw5eB4y+lmRB3sgXFstsCGa/12SqKq6EapqlWpTBHc730Uvs3TdUPu+8abqGq/ 11sjpLaxiHCtaONe3AYIxTa2a/HNmG9RY485g= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: ae4d4737a7668487 X-Antispam: No, score=0.0/5.0, scanned in 0.160sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> Status: RO Content-Length: 835 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 faster. Second you do not have ARG_MAX and other process-based limitations, e.g. the list and size of arguments passed to builtin commands and shell functions is only limited by memory (thank again Roland for giving us a 64bit ksh93 :) ). With builtin our scripts can't trip over the ancient Solaris limits for ARG_MAX (if anyone has time, please file a bug to get ARG_MAX removed completely.). Chris -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris@users.sourceforge.net From garrett.damore@oracle.com Wed Mar 31 09:20:30 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2VGKU6k018249 for ; Wed, 31 Mar 2010 09:20:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2VGKSRb009858 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 31 Mar 2010 10:20:30 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0500D0TMQ5O400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 31 Mar 2010 09:20:29 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L050051VMQ35S70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 31 Mar 2010 09:20:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2VGKROR007717 for ; Wed, 31 Mar 2010 16:20:27 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2V1oWgO026007 for ; Wed, 31 Mar 2010 16:20:25 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 127452711270052383; Wed, 31 Mar 2010 09:19:43 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Mar 2010 09:19:43 -0700 Date: Wed, 31 Mar 2010 09:19:41 -0700 From: "Garrett D'Amore" Subject: PSARC 2010/095 More ksh93 builtins To: PSARC-ext@sun.com Message-id: <4BB3761D.8040107@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BB3764B.0087:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 4307 The project team has decided to change the proposal to remove the contentious builtins for /usr/gnu. Instead, only /usr/bin and /usr/xpg4,xpg6 utilities are being provided as builtins. As these utilities will hopefully one day be converted to use the same underlying libcmd interface, this should not be contentious. I'm restarting the timeout for one week from today (timeout expires April 7). The revised spec follows. - Garrett I'm sponsoring this fast-track request on behalf of the ksh93-integration project. Please note that this is an *open* case. The release binding is the same as with the ksh93 project: a patch/micro release of Solaris delivering through ON Stability levels are as described below. 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/xpg6/bin, /usr/xpg4/bin and /usr/bin built in mappings in ksh93 This case supersets PSARC/2010/095 (it is identical sans built in mappings for /usr/gnu/bin). Bug/RFE Number(s): 6935110 ksh93 needs (more) XPG built ins This case proposes to deliver the following features as a set of independent putbacks as they become available. Each feature is self contained and independent of the others, so out of order and partial putbacks at this granularity should have no adverse impact on the functionality and behavior of the system as a whole. Part 1: ksh93 built in mappings for /usr/xpg4/bin utilities ---------------------------------------------------------- The case proposes to enable the following mappings to ksh93 built in commands for utilities in /usr/xpg4/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/xpg4/bin binary. Interface Stability Description --------- --------- ----------- ksh93 '/usr/xpg4/bin/basename' built in Committed POSIX basename utility ksh93 '/usr/xpg4/bin/egrep' built in Committed POSIX egrep utility ksh93 '/usr/xpg4/bin/fgrep' built in Committed POSIX fgrep utility ksh93 '/usr/xpg4/bin/grep' built in Committed POSIX grep utility ksh93 '/usr/xpg4/bin/id' built in Committed POSIX id utility ksh93 '/usr/xpg4/bin/rm' built in Committed POSIX rm utility Part 2: ksh93 built in mappings for /usr/xpg6/bin utilities ---------------------------------------------------------- The case proposes to enable the following mappings to ksh93 built in commands for utilities in /usr/xpg6/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/xpg6/bin binary. Interface Stability Description --------- --------- ----------- ksh93 '/usr/xpg6/bin/expr' built in Committed POSIX expr utility Part 3: ksh93 built in mappings for /usr/bin utilities ---------------------------------------------------------- The case proposes to enable the following mappings to ksh93 built in commands for utilities in /usr/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/xpg4/bin binary. Interface Stability Description --------- --------- ----------- ksh93 '/usr/bin/dirname' built in Committed POSIX dirname utility General comments ---------------- This case heavily builds on PSARC/2006/550 which was the first PSARC case to introduce the concept of shell built ins bound to a path. Future development ------------------ The shell project team will file separate ARC case to add the same shell built ins to bash4, reusing the same code as ksh93 (libcmd.so.1). The shell project will later provide an API within libcmd.so.1 for other shells (e.g. bash4) and applications to call the built ins directly. This API will be available as contracted API until sufficient experience has been collected and then opened as Committed interface. From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Apr 1 05:36:27 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o31CaRf3024935 for ; Thu, 1 Apr 2010 05:36:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o31CaPIB011036 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Apr 2010 06:36:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0700B3D70Q8G00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 05:36:26 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L07009MQ70PU000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 05:36:26 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o31CXv8E019210 for ; Thu, 01 Apr 2010 12:36:25 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-3418058 for PSARC-ext@sun.com; Thu, 01 Apr 2010 12:34:24 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-67272223 for PSARC-ext@sun.com; Thu, 01 Apr 2010 12:34:23 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-20502490 for PSARC-ext@sun.com; Thu, 01 Apr 2010 12:34:23 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 2F7D363C1B9; Thu, 01 Apr 2010 14:34:21 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id C39B663C10D; Thu, 01 Apr 2010 14:34:20 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o31CYK8r013993; Thu, 01 Apr 2010 14:34:20 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 01 Apr 2010 14:34:20 +0200 Date: Thu, 01 Apr 2010 14:34:20 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010] In-reply-to: Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: pkchris@users.sourceforge.net, darrenm@opensolaris.org Cc: shell-discuss@opensolaris.org, PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com Message-id: <4bb492cc.3xnB77YvMWW2hLKi%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 1.067sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201003181524.o2IFOvCI021257@sac.sfbay.sun.com> <4BA24991.5080201@opensolaris.org> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 01 Apr 2010 12:34:20.0595 (UTC) FILETIME=[A7063830:01CAD197] Status: RO Content-Length: 1037 Chris Pickett wrote: > First at all you do not go through fork() and be a lot faster. > > Second you do not have ARG_MAX and other process-based limitations, > e.g. the list and size of arguments passed to builtin commands and > shell functions is only limited by memory (thank again Roland for > giving us a 64bit ksh93 :) ). > With builtin our scripts can't trip over the ancient Solaris limits > for ARG_MAX (if anyone has time, please file a bug to get ARG_MAX > removed completely.). Then it would make sense to define a standard for the interface of a reentrant utility in a shared library. Not a bad idea but there are currently different and partially incompatible models for such an interface. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From sebastien.roy@oracle.com Wed Apr 21 07:52:38 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3LEqckt005815 for ; Wed, 21 Apr 2010 07:52:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3LEqZp1049188 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Apr 2010 08:52:38 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1800LFDENPEF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 07:52:37 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1800L7BENN1B90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 07:52:36 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3LEqZZF017612 for ; Wed, 21 Apr 2010 14:52:35 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3LEqVtH018847 for ; Wed, 21 Apr 2010 14:52:32 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 178142531271861538; Wed, 21 Apr 2010 07:52:18 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Apr 2010 07:52:17 -0700 Date: Wed, 21 Apr 2010 10:52:16 -0400 From: Sebastien Roy Subject: Re: PSARC 2010/095 More ksh93 builtins In-reply-to: <4BB3761D.8040107@oracle.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <4BCF1120.8020207@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BCF1132.007C:SCFMA4539814,ss=1,fgs=0 References: <4BB3761D.8040107@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1096 On 03/31/10 12:19 PM, Garrett D'Amore wrote: > The project team has decided to change the proposal to remove the > contentious builtins for /usr/gnu. Instead, only /usr/bin and > /usr/xpg4,xpg6 utilities are being provided as builtins. As these > utilities will hopefully one day be converted to use the same underlying > libcmd interface, this should not be contentious. > > I'm restarting the timeout for one week from today (timeout expires > April 7). The revised spec follows. Given that this case is building upon pre-existing built-in architecture, I don't have any issues specific to this case that should hold it up. +1 That said, I think one thread of substance from the lengthy discussion this case spawned relates to the duplicity of code between the commands and their built-in equivalents. This is more a commentary of the implementation of built-ins in general, and not of the specific built-ins introduced by this case. Having architecture introduced to allow a shared implementation (as Garrett hopes will be the case with libcmd above) would be a good thing. -Seb From olga.kryzhanovska@gmail.com Wed Apr 21 13:23:40 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3LKNekW020393 for ; Wed, 21 Apr 2010 13:23:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3LKNd7v064749 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Apr 2010 14:23:40 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L180014LTZF7U00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 13:23:39 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1800KNYTZEZP30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 13:23:38 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3LKHB5S011062 for ; Wed, 21 Apr 2010 20:23:38 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-687121 for PSARC-ext@sun.com; Wed, 21 Apr 2010 20:23:38 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-152434698 for PSARC-ext@sun.com; Wed, 21 Apr 2010 20:23:38 +0000 (Z) Received: from mail-bw0-f215.google.com ([209.85.218.215] [209.85.218.215]) by relay1i.sun.com with ESMTP id BT-MMP-33142897 for PSARC-ext@sun.com; Wed, 21 Apr 2010 20:23:37 +0000 (Z) Received: by bwz7 with SMTP id 7so7648309bwz.36 for ; Wed, 21 Apr 2010 13:23:36 -0700 (PDT) Received: by 10.204.102.74 with HTTP; Wed, 21 Apr 2010 13:23:36 -0700 (PDT) Received: by 10.204.39.206 with SMTP id h14mr7514705bke.50.1271881416717; Wed, 21 Apr 2010 13:23:36 -0700 (PDT) Date: Wed, 21 Apr 2010 22:23:36 +0200 From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= Subject: Re: PSARC 2010/095 More ksh93 builtins In-reply-to: <4BCF1120.8020207@oracle.com> To: Sebastien Roy Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=k6ZW4dptLwSNbDcjtQlvrrN1W6Swsg/paWFOMFMBkTo=; b=e1qd6jh1CvCFU+nNoBMv0wEwsKU8YxGLpS5EZY0EHwM9WbIkR7NTPKiZR8qsl48tfm hTuhGAaWgMg7QEG2p6nJRHA2PzRDykYh3sgomAA6R2O8Eo1eAQSqZFRmgHm4TqjTkTuD AI7C/lR5m+t0+d57Rgtj3ezneWa9dlZUvxYHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IqptFKSDcIkNANzDlPQvImAsoihbqh7k+AdiwwP6T8Es5cl7bIm5PXcMx730ILnNcH 0aeSMkekAF7G+yNBpO0cSLXIx5ddvp3y3LhrbJATjnnp/B015LyMpJ0YjMLry6NfHHSU +mn62ZT6hNKNrxZ5UMnrI/Egba4zsnlMcmz08= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BB3761D.8040107@oracle.com> <4BCF1120.8020207@oracle.com> Status: RO Content-Length: 2132 Sebastien, the goal is to have only one implementation at the end (lets call it SUNWposix-core), one which is a maintained, modern, very fast, conforms to POSIX, SUS, passes UNIX branding requirements (some people have voiced concerns about this, I can say as current project lead in charge that this is nothing to worry about as we indent to pass all tests and requirements required by the UNIX brand), implements commonly used BSD and GNU features and supports a wide range of systems from very small 16 MB ARM embedded machines scaling up to very large servers with 16 TB or more. Olga On Wed, Apr 21, 2010 at 4:52 PM, Sebastien Roy wrote: > On 03/31/10 12:19 PM, Garrett D'Amore wrote: >> >> The project team has decided to change the proposal to remove the >> contentious builtins for /usr/gnu. Instead, only /usr/bin and >> /usr/xpg4,xpg6 utilities are being provided as builtins. As these >> utilities will hopefully one day be converted to use the same underlying >> libcmd interface, this should not be contentious. >> >> I'm restarting the timeout for one week from today (timeout expires >> April 7). The revised spec follows. > > Given that this case is building upon pre-existing built-in architecture, I > don't have any issues specific to this case that should hold it up. +1 > > That said, I think one thread of substance from the lengthy discussion this > case spawned relates to the duplicity of code between the commands and their > built-in equivalents. This is more a commentary of the implementation of > built-ins in general, and not of the specific built-ins introduced by this > case. Having architecture introduced to allow a shared implementation (as > Garrett hopes will be the case with libcmd above) would be a good thing. > > -Seb > > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--`