From carlsonj@phorcys.east.sun.com Tue Jan 16 10:46:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0GIkpli008815 for ; Tue, 16 Jan 2007 10:46:52 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0GIjmjg009918; Tue, 16 Jan 2007 18:46:49 GMT 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 <0JBZ00A2D5HXOD00@brm-avmta-1.central.sun.com>; Tue, 16 Jan 2007 11:46:45 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBZ000QQ5HVG290@brm-avmta-1.central.sun.com>; Tue, 16 Jan 2007 11:46:43 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0GIkhJV028511; Tue, 16 Jan 2007 13:46:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0GIkhb4028508; Tue, 16 Jan 2007 13:46:43 -0500 (EST) Date: Tue, 16 Jan 2007 13:46:42 -0500 From: James Carlson Subject: 2007/035 ksh93 Amendments To: psarc-ext@sun.com Cc: "April D. Chin" Message-id: <17837.7570.832139.435888@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5002 I'm sponsoring this fast-track request on behalf of April Chin and the ksh93 project team. Please note that this is an *open* case. The release binding is the same as with the previous ksh93 project: a patch/micro release of Solaris delivering through ON. ksh93 has not yet delivered into any release of Solaris. Stability levels are as described below. Additional materials (man pages and diffs) can be found in the 'materials' subdirectory. This project is an amendment to the Korn Shell 93 Integration project (PSARC/2006/550) specifying the following additional interfaces: 1) a ksh93 built-in getconf command and 2) AT&T components for building message files for localization Bug/RFE Number(s): 6505835 AST tools and library (libpp) required for creating l10n messages for ksh93 Description The AT&T built-in version of the getconf utility in ksh93 contains extensions not present in the Solaris getconf utility, which are required to run the AT&T ksh93 tests; these tests are critical to the verification of ksh93 builds. The getconf built-in allows users to write ksh93 scripts which are portable across different systems and which can take advantage of AT&T extensions to ksh93 [1,2]. Like other built-in commands named in PSARC/2006/550, the getconf built-in in ksh93 will be bound to the /bin pathname. The built-in getconf in ksh93 will only be invoked if called with no pathname prefix, and if a /bin/getconf or /usr/bin/getconf executable is found first on the user's path. The stability of the getconf built-in command-line interface and the system variables documented in getconf(1) is Committed; its pathname binding to /bin is Volatile. The getconf built-in supports additional system variables not available for /usr/bin/getconf; these variables are Project Private, and include names prefixed with "AST" and "_AST". All options and system variables supported by /usr/bin/getconf produce identical output values using the ksh93 built-in getconf. Additions to the ksh93 test suite and to /usr/bin/getconf testing will ensure that ksh93 built-in getconf continues to provide functionality compatible with /usr/bin/getconf. The second portion of this project specifies the addition of AT&T message-building components--a library, ksh93 scripts, and a set of binaries--required for the ksh93 project to build its message files for localization. The message-building tools and proposed AT&T library, libpp, have a strong dependency on libast, one of the new AT&T libraries specified in PSARC/2006/550. Therefore these components should be kept in sync with libast on Solaris. These components will initially be used only by the Korn Shell 93 Integration Project (PSARC/2006/550). The proposed location of the tools in /usr/ast/bin is consistent with the location used within AT&T. If the interface stability level of the shared libraries listed in PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from Project Private, the stability of the /usr/ast/bin components listed below should be promoted to at least the same level, to allow consumers of the former to build the appropriate message files. Interface Description Stability --------- ----------- --------- /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private /usr/ast/bin directory for AT&T commands Volatile /usr/ast/bin/msgadmin ksh93 script for message catalog Volatile file administration /usr/ast/bin/msgcc ksh93 script for generating message Volatile catalog files binaries used by msgcc and msgadmin for message formatting, converting: /usr/ast/bin/msgcpp Volatile /usr/ast/bin/msgcvt Volatile /usr/ast/bin/msggen Volatile /usr/ast/bin/msgget Volatile A new package for AST (Advanced Software Technology) developer tools, SUNWastdev, will be created, which includes all of the above message-building components. These tools have a dependency on ksh93 and its libraries, as listed in PSARC/2006/550, and shall not be integrated before the Korn Shell 93 Integration project. Dynamic library dependencies of msgcpp, msgcvt, msggen, and msgget: libpp.so.1 => /usr/lib/libpp.so.1 libast.so.1 => /usr/lib/libast.so.1 libm.so.2 => /lib/libm.so.2 libc.so.1 => /usr/lib/libc.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libmd.so.1 => /usr/lib/libmd.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-V890/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-V890/lib/libmd_psr.so.1 References: [1] getconf background from Glenn Fowler of AT&T http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-November/001863.html [2] more getconf background from Glenn Fowler http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-November/001864.html From carlsonj@phorcys.east.sun.com Tue Jan 16 10:56:50 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0GIunCO009750 for ; Tue, 16 Jan 2007 10:56:49 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0GIunWc024068; Tue, 16 Jan 2007 10:56:49 -0800 (PST) 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 <0JBZ0010P5YO3D00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Jan 2007 10:56:48 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBZ009XX5YOY380@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Jan 2007 10:56:48 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0GIumLv028568; Tue, 16 Jan 2007 13:56:48 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0GIumhG028565; Tue, 16 Jan 2007 13:56:48 -0500 (EST) Date: Tue, 16 Jan 2007 13:56:47 -0500 From: James Carlson Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <17837.7570.832139.435888@gargle.gargle.HOWL> To: psarc-ext@sun.com Cc: "April D. Chin" Message-id: <17837.8175.713454.985376@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> Status: RO Content-Length: 646 James Carlson writes: > I'm sponsoring this fast-track request on behalf of April Chin and the > ksh93 project team. Please note that this is an *open* case. One possible point of concern here is the `getconf' duplication. This project delivers a separate implementation of that feature, so that we end up having two (the ksh93 one is a strict superset), and they are to be kept in sync by means of additional testing. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From glenn@ivrel.sfbay.sun.com Tue Jan 16 17:19:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0H1JpbC021789 for ; Tue, 16 Jan 2007 17:19:52 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0H1JkDt029419 for <@sunmail3.sfbay.sun.com:psarc-ext@sun.com>; Wed, 17 Jan 2007 01:19:51 GMT 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 <0JBZ00203NP16600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Jan 2007 17:19:49 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBZ00GJUNP0WN80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Jan 2007 17:19:49 -0800 (PST) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0H1JmcN025966; Tue, 16 Jan 2007 17:19:48 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l0H1IfQd010306; Tue, 16 Jan 2007 17:18:41 -0800 (PST) Date: Tue, 16 Jan 2007 17:18:41 -0800 (PST) From: Glenn Skinner Subject: Re: 2007/035 ksh93 Amendments To: psarc-ext@sun.com Cc: april.chin@sun.com Reply-to: Glenn Skinner Message-id: <200701170118.l0H1IfQd010306@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: GO3nCFwxxGNz3ifxNo9GGA== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 932 Date: Tue, 16 Jan 2007 13:56:47 -0500 From: James Carlson Subject: Re: 2007/035 ksh93 Amendments James Carlson writes: > I'm sponsoring this fast-track request on behalf of April Chin and the > ksh93 project team. Please note that this is an *open* case. One possible point of concern here is the `getconf' duplication. This project delivers a separate implementation of that feature, so that we end up having two (the ksh93 one is a strict superset), and they are to be kept in sync by means of additional testing. And this observation prompts the obvious question of whether it would be feasible to unify the two getconf implementations. Presumably such a unification would have to be based on the ksh93/AST version, with provisions made to hide the extra functionality when invoked in an outside-of-ksh (or perhaps traditional Solaris) context. -- Glenn From roland.mainz@nrubsig.org Wed Jan 17 03:28:58 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HBSuCQ002419 for ; Wed, 17 Jan 2007 03:28:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HBSXS0022117; Wed, 17 Jan 2007 19:28:53 +0800 (SGT) 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 <0JC000K01FW1XI00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 03:28:49 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC000FBMFW1KB10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 03:28:49 -0800 (PST) Received: from relay12.sun.com (relay12.sun.com [217.140.40.34] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0HBSmNW029148; Wed, 17 Jan 2007 04:28:48 -0700 (MST) Received: from mms11es.sun.com ([160.41.223.14] [160.41.223.14]) by relay12.sun.com with ESMTP; Wed, 17 Jan 2007 11:28:47 +0000 (Z) Received: from relay12.sun.com (relay12.sun.com [217.140.40.34]) by mms11es.sun.com with ESMTP; Wed, 17 Jan 2007 11:28:47 +0000 (Z) Received: from mail-in-03.arcor-online.net ([151.189.21.43] [151.189.21.43]) by relay12.sun.com with ESMTP; Wed, 17 Jan 2007 11:28:47 +0000 (Z) Received: from mail-in-01-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 0385C2CABDA; Wed, 17 Jan 2007 12:28:47 +0100 (CET) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id EB28B23D460; Wed, 17 Jan 2007 12:28:46 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-058-207-218.pools.arcor-ip.net [84.58.207.218]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id B5F701C71CB; Wed, 17 Jan 2007 12:28:46 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l0HBShfb001709; Wed, 17 Jan 2007 12:28:44 +0100 (CET) Date: Wed, 17 Jan 2007 12:28:43 +0100 From: Roland Mainz Subject: Re: 2007/035 ksh93 Amendments Sender: gisburn@jupiterb48.nrubsig.org To: Glenn Skinner Cc: psarc-ext@sun.com, april.chin@sun.com Message-id: <45AE086B.FB822AB0@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <200701170118.l0H1IfQd010306@ivrel.sfbay.sun.com> Status: RO Content-Length: 2341 Glenn Skinner wrote: > > James Carlson writes: > > > I'm sponsoring this fast-track request on behalf of April Chin and the > > > ksh93 project team. Please note that this is an *open* case. > > > > One possible point of concern here is the `getconf' duplication. > > This project delivers a separate implementation of that feature, so > > that we end up having two (the ksh93 one is a strict superset), and > > they are to be kept in sync by means of additional testing. > > And this observation prompts the obvious question of whether it would > be feasible to unify the two getconf implementations. Presumably such > a unification would have to be based on the ksh93/AST version, with > provisions made to hide the extra functionality when invoked in an > outside-of-ksh (or perhaps traditional Solaris) context. AFAIK this is not possible. The problem is that /usr/bin/getconf is compiled as normal application while ksh93 in Solaris is explicitly compiled as XPG6/C99 application (to enable various features and avoid that the ksh93 code enables workaronds for older standards functions (which result in both loss of features and performance)). The problem is that compiling a Solaris application with the XPG6 flags changes some "secret" libc master switches (|_xpg4| and |_xpg6|) which change the behaviour of many libc functions to match the XPG6 standards, including |sysconf()|, |pathconf()| etc. - which would make the "getconf" builtin command work like /usr/xpg6/bin/getconf instead of /usr/bin/getconf (and there is no workaround, neither running the "getconf" builtin in a seperate child process with |_xpg4|+|_xpg6| set to "0" (this doesn't work because it doesn't alter the different header contents (and I doubt that code review would allow such a horrible abuse of C64-style "poke"'ing)) or poking these values only at runtime of the "getconf" builtin (end reset it in an exit trap) will work (this would not be threadsafe)). The current (and likely only working) approach is to let the ksh93 "getconf" builtin forward all keys which are not owned by AST to the native /usr/bin/getconf command (that's what we're currently doing). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From carlsonj@phorcys.east.sun.com Wed Jan 17 04:57:12 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HCvBjj003861 for ; Wed, 17 Jan 2007 04:57:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HCuvg0001706; Wed, 17 Jan 2007 20:57:08 +0800 (SGT) 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 <0JC000E09JZ4L500@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 04:57:04 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC000F92JZ4JR50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 04:57:04 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HCv32r001489; Wed, 17 Jan 2007 07:57:03 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0HCv3fN001486; Wed, 17 Jan 2007 07:57:03 -0500 (EST) Date: Wed, 17 Jan 2007 07:57:01 -0500 From: James Carlson Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <45AE086B.FB822AB0@nrubsig.org> To: Roland Mainz Cc: Glenn Skinner , psarc-ext@sun.com, april.chin@sun.com Message-id: <17838.7453.813208.927541@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200701170118.l0H1IfQd010306@ivrel.sfbay.sun.com> <45AE086B.FB822AB0@nrubsig.org> Status: RO Content-Length: 540 Roland Mainz writes: > The current (and likely only working) approach is to let the ksh93 > "getconf" builtin forward all keys which are not owned by AST to the > native /usr/bin/getconf command (that's what we're currently doing). As long as "forward" here actually means "exec," that eliminates the issues I see. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gsf@research.att.com Wed Jan 17 09:29:05 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HHT4YT009519 for ; Wed, 17 Jan 2007 09:29:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HHSwEe023311; Wed, 17 Jan 2007 17:29:01 GMT 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 <0JC000I0LWKBBG00@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 10:28:59 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC000H8PWKAEA60@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 10:28:58 -0700 (MST) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0HG615X012498; Wed, 17 Jan 2007 10:28:58 -0700 (MST) Received: from mms05es.sun.com ([150.143.104.94] [150.143.104.94]) by relay2.sun.com with ESMTP; Wed, 17 Jan 2007 17:28:57 +0000 (Z) Received: from relay4.sun.com (relay4.sun.com [150.143.103.74]) by mms05es.sun.com with ESMTP; Wed, 17 Jan 2007 17:28:56 +0000 (Z) Received: from mail-red.research.att.com ([192.20.225.110] [192.20.225.110]) by relay4.sun.com with ESMTP; Wed, 17 Jan 2007 17:28:51 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-blue.research.att.com (Postfix) with ESMTP id 03380147C91; Wed, 17 Jan 2007 12:28:45 -0500 (EST) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id l0HHSeHQ029711; Wed, 17 Jan 2007 12:28:40 -0500 Date: Wed, 17 Jan 2007 12:28:40 -0500 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] Re: 2007/035 ksh93 Amendments To: ksh93-integration-discuss@opensolaris.org, roland.mainz@nrubsig.org Cc: april.chin@sun.com, glenn@ivrel.sfbay.sun.com, psarc-ext@sun.com Message-id: <200701171728.l0HHSeHQ029711@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2006-04-17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200701170118.l0H1IfQd010306@ivrel.sfbay.sun.com> <45AE086B.FB822AB0@nrubsig.org> <17838.7453.813208.927541@gargle.gargle.HOWL> Status: RO Content-Length: 1324 On Wed, 17 Jan 2007 07:57:01 -0500 James Carlson wrote: > Roland Mainz writes: > > The current (and likely only working) approach is to let the ksh93 > > "getconf" builtin forward all keys which are not owned by AST to the > > native /usr/bin/getconf command (that's what we're currently doing). > As long as "forward" here actually means "exec," that eliminates the > issues I see. "forward" means "exec" (the implementation uses "defer") the conditions for deferring to the native getconf on $PATH are any of: (1) key unknown to builtin (2) key known to have different values between { bin xpg4 xpg6 } (3) any of { -a -v } options present this lists the builtin getconf table getconf -t this lists the deferred (C:syscall D:minmax) keys getconf -t | grep '[0-9] *[CD]' | grep -v 'VERSION_[0-9][0-9]' the rationale for -last doing all this work is that it provides char* astconf(char* name, char* path, char* value); that (a) keeps ast code #ifdef _SC_* free (b) allows default minmax values to be synthesized on systems that don't support specific keys but do support the feature named by the keys (c) allows ast specific keys, like pathconf "directory is case ignorant" for uwin/windows (d) allows writable ast specific keys (listed by getconf -w) -- Glenn Fowler -- AT&T Research, Florham Park NJ -- From jek3@sun.com Wed Jan 17 12:34:05 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HKY3VA016380 for ; Wed, 17 Jan 2007 12:34:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HKXjKP009873; Wed, 17 Jan 2007 20:34:00 GMT 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 <0JC100H0154L1F00@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 13:33:57 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC100JWZ54KYY90@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 13:33:57 -0700 (MST) Received: from [129.150.12.40] (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HKXxwN817340; Wed, 17 Jan 2007 12:33:59 -0800 (PST) Date: Wed, 17 Jan 2007 10:32:27 -1000 From: Joseph Kowalski Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <17837.7570.832139.435888@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@sun.com, "April D. Chin" Message-id: <45AE87DB.8050009@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 2932 There are a couple of things I don't understand about this proposal. I'm not suggesting a change, simply additional rationale/clarification. James Carlson wrote: > The stability of the getconf built-in command-line interface and the > system variables documented in getconf(1) is Committed; its pathname > binding to /bin is Volatile. The getconf built-in supports additional > system variables not available for /usr/bin/getconf; these variables > are Project Private, and include names prefixed with "AST" and "_AST". > What does "its pathname binding" actually mean and is it /bin or /usr/bin? > These components will initially be used only by the Korn Shell 93 > Integration Project (PSARC/2006/550). The proposed location of the > tools in /usr/ast/bin is consistent with the location used within > AT&T. > Ah, battling communities - my favorite. We get some degree of flack from the Linux FSH crowd about creating project specific directories in /usr. The charming FSH spec simply says, "don't do this" without saying what to do. It seems like the standard response is to put such things either in /opt (reasonable, but a problem for Solaris diskless/zones) or under /usr/lib (completely silly in all respects, IMHO, it just moves the problem to another directory, one that is repeatedly scanned by ld.so - go figure). I guess if ksh93 installed on a Linux system installs into /usr/ast, with the resultant wrath of the FSH zelots, we have no problem. If it installs elsewhere, we need to have the discussion as to if we should be like Linux or be like legacy Solaris. Aside: For those who don't know, I personally view the FSH document to be one of the worst specifications ever created, but there are zelots out there who think it was written on stone tablets. Sigh,... > If the interface stability level of the shared libraries listed in > PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from > Project Private, the stability of the /usr/ast/bin components listed > below should be promoted to at least the same level, to allow > consumers of the former to build the appropriate message files. > This isn't declarative. It starts with "If". Are the promoted, and if so, to what? Volatile I guess, but it needs to be explicit. > Interface Description Stability > --------- ----------- --------- > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private > Why is this interesting to list? (No harm, but I fear I might be missing something.) > A new package for AST (Advanced Software Technology) developer tools, > SUNWastdev, will be created, which includes all of the above > message-building components. These tools have a dependency on ksh93 > and its libraries, as listed in PSARC/2006/550, and shall not be > integrated before the Korn Shell 93 Integration project. > What Metacluster is this package to be added to? - thanks, - jek3 From jek3@sun.com Wed Jan 17 12:36:25 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HKaOQr016400 for ; Wed, 17 Jan 2007 12:36:25 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HKaJFD011275; Wed, 17 Jan 2007 20:36:21 GMT 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 <0JC100H0L58LDR00@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 13:36:21 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC100J7Q58KYSB0@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 13:36:20 -0700 (MST) Received: from [129.150.12.40] (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HKaMAM818015; Wed, 17 Jan 2007 12:36:23 -0800 (PST) Date: Wed, 17 Jan 2007 10:34:47 -1000 From: Joseph Kowalski Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <17837.8175.713454.985376@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@sun.com, "April D. Chin" Message-id: <45AE8867.7060100@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <17837.8175.713454.985376@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 715 James Carlson wrote: > James Carlson writes: > >> I'm sponsoring this fast-track request on behalf of April Chin and the >> ksh93 project team. Please note that this is an *open* case. >> > > One possible point of concern here is the `getconf' duplication. This > project delivers a separate implementation of that feature, so that we > end up having two (the ksh93 one is a strict superset), and they are > to be kept in sync by means of additional testing. > I recall a longer term plan would be to have a single implementation of this (and many of the builtin commands). Is this still the plan and getconf would be part of that? (Basically, is this duplication a short term expedient?) - jek3 From roland.mainz@nrubsig.org Wed Jan 17 13:12:05 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLC4bF017342 for ; Wed, 17 Jan 2007 13:12:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HLAdqS003094; Wed, 17 Jan 2007 21:12:01 GMT 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 <0JC100KAV6VZUO10@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:11:59 -0800 (PST) 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 <0JC100C4L6RO2P80@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:09:28 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0HL6joo026247; Wed, 17 Jan 2007 13:09:24 -0800 (PST) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP; Wed, 17 Jan 2007 21:09:24 +0000 (Z) Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by mms48es.sun.com with ESMTP; Wed, 17 Jan 2007 21:09:24 +0000 (Z) Received: from mail-in-07.arcor-online.net ([151.189.21.47] [151.189.21.47]) by relay4i.sun.com with ESMTP; Wed, 17 Jan 2007 21:09:23 +0000 (Z) Received: from mail-in-01-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 1ABD824B17F; Wed, 17 Jan 2007 22:09:23 +0100 (CET) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 0D3C634667A; Wed, 17 Jan 2007 22:09:23 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-003-125.pools.arcor-ip.net [84.59.3.125]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id CD668106673; Wed, 17 Jan 2007 22:09:22 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l0HL9JLd001846; Wed, 17 Jan 2007 22:09:20 +0100 (CET) Date: Wed, 17 Jan 2007 22:09:19 +0100 From: Roland Mainz Subject: Re: 2007/035 ksh93 Amendments Sender: gisburn@jupiterb48.nrubsig.org To: Joseph Kowalski Cc: James Carlson , psarc-ext@sun.com, "April D. Chin" Message-id: <45AE907F.965E3E58@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <45AE87DB.8050009@sun.com> Status: RO Content-Length: 5482 Joseph Kowalski wrote: [snip] > James Carlson wrote: > > The stability of the getconf built-in command-line interface and the > > system variables documented in getconf(1) is Committed; its pathname > > binding to /bin is Volatile. The getconf built-in supports additional > > system variables not available for /usr/bin/getconf; these variables > > are Project Private, and include names prefixed with "AST" and "_AST". > > What does "its pathname binding" actually mean (Somewhere April wrote a better (and shorter explanation) but I can't find it right now... ;-( ) Path name binding means that a builtin is bound to a specific path. The shell will execute the command in place of the "native" command in the filesystem if it's found at the path lookup in ${PATH}. For example if you have a builtin command "grabvictim" bound to /opt/tentaclemonster/bin/grabvictim then the builtin "grabvictim" will only be executed if ${PATH} contains /opt/tentaclemonster/bin/ and no other version of "grabvictim" was found in a ${PATH} element before this point (="/opt/tentaclemonster/bin/"). As alternative builtin commands can be added without a path binding which means they will be executed immediately ("print" and "sleep" are examples for such builtin commands). > and is it /bin or /usr/bin? It is both /bin/ and /usr/bin/ - the code detects whether "/bin" is a softlink to "/usr/bin" and then binds commands bound to "/bin" automagically to "/usr/bin", too (they're the same filesystem objects anyway and a different behaviour would be confusing for script authors). > > These components will initially be used only by the Korn Shell 93 > > Integration Project (PSARC/2006/550). The proposed location of the > > tools in /usr/ast/bin is consistent with the location used within > > AT&T. > > > Ah, battling communities - my favorite. Uh-oh... ;-( > We get some degree of flack from the Linux FSH crowd about creating project > specific directories in /usr. How else should the "namespaces" between different projects be defined ? The ${PATH}/${FPATH} stuff was exactly invented to avoid collisions between projects and give full control over the lookup order (which is quite usefull if you want to implement multiple different standards (e.g. XPG4 in /usr/xpg4/bin, XPG6 in /usr/xpg6/bin, AST in /usr/ast/bin, UCB in /usr/ucb etc.)). and use them in a mix&match way in the same operating system instance. > The charming FSH spec simply says, "don't > do this" > without saying what to do. It seems like the standard response is to > put such things > either in /opt (reasonable, but a problem for Solaris diskless/zones) or > under /usr/lib > (completely silly in all respects, IMHO, it just moves the problem to > another > directory, one that is repeatedly scanned by ld.so - go figure). > > I guess if ksh93 installed on a Linux system installs into /usr/ast, > with the resultant > wrath of the FSH zelots, we have no problem. If it installs elsewhere, > we need to > have the discussion as to if we should be like Linux or be like legacy > Solaris. Usually the AST tools are installed in either /usr/ast/ or /opt/ast/ depending on the preference of the package builder. We'd like to go for /usr/ast/ since ksh93 should be a more integral part of Solaris (we're building it as part of OS/Net, remember ? :-) ) and not some kind of external software which is tacked-on later (all stuff which goes into /opt). > Aside: For those who don't know, I personally view the FSH document to > be one of the > worst specifications ever created, but there are zelots out there who > think it was > written on stone tablets. Sigh,... ... yeah... it's funny to see how they try to deal with the problem that some tools have the same name... =:-) > > If the interface stability level of the shared libraries listed in > > PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from > > Project Private, the stability of the /usr/ast/bin components listed > > below should be promoted to at least the same level, to allow > > consumers of the former to build the appropriate message files. > > > This isn't declarative. It starts with "If". Are the promoted, and if > so, to what? Uhm... to the same level as needed by the consumers of libshell/libcmd/libast etc. ? > Volatile I guess, but it needs to be explicit. > > Interface Description Stability > > --------- ----------- --------- > > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private > > > Why is this interesting to list? (No harm, but I fear I might be > missing something.) It's a new filesystem object... AFAIK the ARC case must list them, right ? > > A new package for AST (Advanced Software Technology) developer tools, > > SUNWastdev, will be created, which includes all of the above > > message-building components. These tools have a dependency on ksh93 > > and its libraries, as listed in PSARC/2006/550, and shall not be > > integrated before the Korn Shell 93 Integration project. > > > What Metacluster is this package to be added to? AFAIK April can answer that better than I... but I guess it belongs to the development cluster (e,g, similar to the packages which deliver into /usr/css/bin/). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From carlsonj@phorcys.east.sun.com Wed Jan 17 13:15:06 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLF6El017366 for ; Wed, 17 Jan 2007 13:15:06 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0HLEScd010029; Wed, 17 Jan 2007 13:15:05 -0800 (PST) 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 <0JC100KWZ715PI10@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 14:15:05 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC100J7C6XSYLE0@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 14:13:04 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HLD4wt003959; Wed, 17 Jan 2007 16:13:04 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0HLD4qa003956; Wed, 17 Jan 2007 16:13:04 -0500 (EST) Date: Wed, 17 Jan 2007 16:13:04 -0500 From: James Carlson Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <45AE87DB.8050009@sun.com> To: Joseph Kowalski Cc: psarc-ext@sun.com, "April D. Chin" Message-id: <17838.37216.43596.545010@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <17837.8175.713454.985376@gargle.gargle.HOWL> <45AE8867.7060100@sun.com> <45AE87DB.8050009@sun.com> Status: RO Content-Length: 3892 Joseph Kowalski writes: > > The stability of the getconf built-in command-line interface and the > > system variables documented in getconf(1) is Committed; its pathname > > binding to /bin is Volatile. The getconf built-in supports additional > > system variables not available for /usr/bin/getconf; these variables > > are Project Private, and include names prefixed with "AST" and "_AST". > > > What does "its pathname binding" actually mean and is it /bin or /usr/bin? Refer to the previous ksh93 case (2006/550). The "pathname binding" feature is a mechanism by which ksh93 knows whether to invoke an internal ("built-in") implementation of the function or an external one. > > These components will initially be used only by the Korn Shell 93 > > Integration Project (PSARC/2006/550). The proposed location of the > > tools in /usr/ast/bin is consistent with the location used within > > AT&T. > > > Ah, battling communities - my favorite. I don't think it's an issue here. This is the location that was _already_ discussed and approved as part of the previous project. > > If the interface stability level of the shared libraries listed in > > PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from > > Project Private, the stability of the /usr/ast/bin components listed > > below should be promoted to at least the same level, to allow > > consumers of the former to build the appropriate message files. > > > This isn't declarative. It starts with "If". Are the promoted, and if > so, to what? No promotion, no change. It's a statement about what must occur in the future _if_ any such project is undertaken. In other words, these things are functionally linked -- if you promote one, then you need to promote the other, or have a very good reason not to. If it helps, just ignore that paragraph. It's not delivering anything. > Volatile I guess, but it needs to be explicit. They remain as they are. > > Interface Description Stability > > --------- ----------- --------- > > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private > > > Why is this interesting to list? (No harm, but I fear I might be > missing something.) It just stakes out turf; that's all. > > A new package for AST (Advanced Software Technology) developer tools, > > SUNWastdev, will be created, which includes all of the above > > message-building components. These tools have a dependency on ksh93 > > and its libraries, as listed in PSARC/2006/550, and shall not be > > integrated before the Korn Shell 93 Integration project. > > > What Metacluster is this package to be added to? Good question -- Roland? My guess would be that it doesn't belong in *any* metacluster, as it's really only needed for ksh93 development. If you're going to put it into one, then I think it goes in SUNWCall. Joseph Kowalski writes: > > One possible point of concern here is the `getconf' duplication. This > > project delivers a separate implementation of that feature, so that we > > end up having two (the ksh93 one is a strict superset), and they are > > to be kept in sync by means of additional testing. > > > I recall a longer term plan would be to have a single implementation of > this (and > many of the builtin commands). Is this still the plan and getconf would > be part > of that? (Basically, is this duplication a short term expedient?) As pointed out in a follow-up message, the duplication is much less significant than I'd previously thought. The ksh93 built-in "getconf" looks at the arguments and, if they're not ones it recognizes, it execs the existing implementation on the user's $PATH. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Wed Jan 17 13:19:48 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLJm53017490 for ; Wed, 17 Jan 2007 13:19:48 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0HLJV08018037; Wed, 17 Jan 2007 13:19:47 -0800 (PST) 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 <0JC10010R78X7600@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 14:19:45 -0700 (MST) Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC100JR978JYME0@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 14:19:45 -0700 (MST) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0HJ0mk2016422; Wed, 17 Jan 2007 13:19:31 -0800 (PST) Received: from mms07es.sun.com ([150.143.104.134] [150.143.104.134]) by relay1.sun.com with ESMTP; Wed, 17 Jan 2007 21:19:31 +0000 (Z) Received: from relay3.sun.com (relay3.sun.com [150.143.103.54]) by mms07es.sun.com with ESMTP; Wed, 17 Jan 2007 21:19:30 +0000 (Z) Received: from mail-in-08.arcor-online.net ([151.189.21.48] [151.189.21.48]) by relay3.sun.com with ESMTP; Wed, 17 Jan 2007 21:19:30 +0000 (Z) Received: from mail-in-01-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id 59FB5229F8F; Wed, 17 Jan 2007 22:19:29 +0100 (CET) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 4E03F3461FC; Wed, 17 Jan 2007 22:19:29 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-003-125.pools.arcor-ip.net [84.59.3.125]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 283218C462; Wed, 17 Jan 2007 22:19:26 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l0HLJOlG001851; Wed, 17 Jan 2007 22:19:25 +0100 (CET) Date: Wed, 17 Jan 2007 22:19:24 +0100 From: Roland Mainz Subject: Re: [ksh93-integration-discuss] Re: 2007/035 ksh93 Amendments Sender: gisburn@jupiterb48.nrubsig.org To: Korn Shell 93 integration/migration project discussion Cc: James Carlson , psarc-ext@sun.com, "April D. Chin" Message-id: <45AE92DC.EA2B38ED@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <17837.8175.713454.985376@gargle.gargle.HOWL> <45AE8867.7060100@sun.com> Status: RO Content-Length: 1455 Joseph Kowalski wrote: > James Carlson wrote: > > James Carlson writes: > >> I'm sponsoring this fast-track request on behalf of April Chin and the > >> ksh93 project team. Please note that this is an *open* case. > > > > One possible point of concern here is the `getconf' duplication. This > > project delivers a separate implementation of that feature, so that we > > end up having two (the ksh93 one is a strict superset), and they are > > to be kept in sync by means of additional testing. > > > I recall a longer term plan would be to have a single implementation of > this (and > many of the builtin commands). Is this still the plan and getconf would > be part > of that? (Basically, is this duplication a short term expedient?) Yes... we'd like to do that (we just got the approval to contribute parts of Solaris to upstream on demand) however the "getconf" will likely remain a seperate command. The Solaris implementation of /usr/bin/getconf and the related libc functions are very special and delicate to handle (see my earler comment about compiling an application with XPG/C99 flags - this changes the behaviour of many libc functions including |sysconf()| and cannot be handled within the same library code, even if we |fork()| a new child process). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From gsf@research.att.com Wed Jan 17 13:20:32 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLKWYX017507 for ; Wed, 17 Jan 2007 13:20:32 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0HLKTPe018687; Wed, 17 Jan 2007 13:20:31 -0800 (PST) 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 <0JC100KLZ7A2UQ20@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:20:26 -0800 (PST) Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC100C5C79O23A0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:20:12 -0800 (PST) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0HLH14i026922; Wed, 17 Jan 2007 13:20:12 -0800 (PST) Received: from mms09es.sun.com ([150.143.104.174] [150.143.104.174]) by relay1.sun.com with ESMTP; Wed, 17 Jan 2007 21:20:10 +0000 (Z) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14]) by mms09es.sun.com with ESMTP; Wed, 17 Jan 2007 21:20:10 +0000 (Z) Received: from mail-red.research.att.com ([192.20.225.110] [192.20.225.110]) by relay1.sun.com with ESMTP; Wed, 17 Jan 2007 21:20:10 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-green.research.att.com (Postfix) with ESMTP id 1554D8762; Wed, 17 Jan 2007 16:20:09 -0500 (EST) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id l0HLK8ew020264; Wed, 17 Jan 2007 16:20:08 -0500 Date: Wed, 17 Jan 2007 16:20:08 -0500 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] Re: 2007/035 ksh93 Amendments To: jek3@sun.com, ksh93-integration-discuss@opensolaris.org Cc: april.chin@sun.com, james.d.carlson@sun.com, psarc-ext@sun.com Message-id: <200701172120.l0HLK8ew020264@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2006-04-17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <45AE87DB.8050009@sun.com> <45AE907F.965E3E58@nrubsig.org> Status: RO Content-Length: 635 On Wed, 17 Jan 2007 22:09:19 +0100 Roland Mainz wrote: > Joseph Kowalski wrote: > > Volatile I guess, but it needs to be explicit. > > > Interface Description Stability > > > --------- ----------- --------- > > > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private > > > > > Why is this interesting to list? (No harm, but I fear I might be > > missing something.) libpp is used by the commands that extract message text from source for localization into message catalogs -- Glenn Fowler -- AT&T Research, Florham Park NJ -- From roland.mainz@nrubsig.org Wed Jan 17 13:31:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLVh5e017660 for ; Wed, 17 Jan 2007 13:31:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HLVWQI019364; Wed, 17 Jan 2007 21:31:38 GMT 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 <0JC10020V7SOGG00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:31:36 -0800 (PST) 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 <0JC100CEX7SO27A0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:31:36 -0800 (PST) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0HKg7d3023175; Wed, 17 Jan 2007 14:31:35 -0700 (MST) Received: from mms09es.sun.com ([150.143.104.174] [150.143.104.174]) by relay2.sun.com with ESMTP; Wed, 17 Jan 2007 21:30:49 +0000 (Z) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14]) by mms09es.sun.com with ESMTP; Wed, 17 Jan 2007 21:30:49 +0000 (Z) Received: from mail-in-13.arcor-online.net ([151.189.21.53] [151.189.21.53]) by relay1.sun.com with ESMTP; Wed, 17 Jan 2007 21:30:49 +0000 (Z) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id A29421E50A6; Wed, 17 Jan 2007 22:30:48 +0100 (CET) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 886D92D3653; Wed, 17 Jan 2007 22:30:48 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-003-125.pools.arcor-ip.net [84.59.3.125]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 5DF891C71C7; Wed, 17 Jan 2007 22:30:48 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l0HLUjN5001856; Wed, 17 Jan 2007 22:30:46 +0100 (CET) Date: Wed, 17 Jan 2007 22:30:45 +0100 From: Roland Mainz Subject: Re: [ksh93-integration-discuss] Re: 2007/035 ksh93 Amendments Sender: gisburn@jupiterb48.nrubsig.org To: Korn Shell 93 integration/migration project discussion Cc: Joseph Kowalski , psarc-ext@sun.com, "April D. Chin" Message-id: <45AE9585.69105B2C@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <17837.8175.713454.985376@gargle.gargle.HOWL> <45AE8867.7060100@sun.com> <45AE87DB.8050009@sun.com> <17838.37216.43596.545010@gargle.gargle.HOWL> Status: RO Content-Length: 1468 James Carlson wrote: > Joseph Kowalski writes: [snip] > > > A new package for AST (Advanced Software Technology) developer tools, > > > SUNWastdev, will be created, which includes all of the above > > > message-building components. These tools have a dependency on ksh93 > > > and its libraries, as listed in PSARC/2006/550, and shall not be > > > integrated before the Korn Shell 93 Integration project. > > > > > What Metacluster is this package to be added to? > > Good question -- Roland? > > My guess would be that it doesn't belong in *any* metacluster, as it's > really only needed for ksh93 development. If you're going to put it > into one, then I think it goes in SUNWCall. In theory I would prefer that "SUNWastdevl" should go into the same metacluster as the packages which fill /usr/ccs/bin/. That way we make sure that the AST l10n generation tools are available when building OS/Net (otherwise gatekeepers may hear complains about built failure over and over again just because one package is missing (which happens near the end of the build, making it an even more nasty "suprise" ... ;-( )) and save any future changes in the package database if we promote the stabilty to something higher (e.g. less paperwork in the future... :-) ). April: What do you think ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From April.Chin@eng.sun.com Wed Jan 17 13:36:08 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLa8eg017737 for ; Wed, 17 Jan 2007 13:36:08 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0HLa4ng019788; Wed, 17 Jan 2007 13:36:06 -0800 (PST) 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 <0JC10000B8069800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 13:36:06 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC10098Q8053WA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 13:36:05 -0800 (PST) Received: from aragon (aragon.SFBay.Sun.COM [129.146.226.123]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l0HLa5Ix836034; Wed, 17 Jan 2007 13:36:05 -0800 (PST) Date: Wed, 17 Jan 2007 13:33:56 -0800 (PST) From: April Chin Subject: Re: 2007/035 ksh93 Amendments To: james.d.carlson@sun.com, jek3@sun.com Cc: psarc-ext@sun.com, april.chin@sun.com Reply-to: April Chin Message-id: <200701172136.l0HLa5Ix836034@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_31 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: n/06znl889dZBy7Ye5oGNQ== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 4384 Roland & James have already replied, so I'll try not to be redundant. I have just a few in-line comments, below. April > Date: Wed, 17 Jan 2007 10:32:27 -1000 > From: Joseph Kowalski > Subject: Re: 2007/035 ksh93 Amendments > To: James Carlson > Cc: psarc-ext@sun.com, "April D. Chin" > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.2.0.264296 > User-Agent: Thunderbird 1.5.0.5 (X11/20060925) > > > There are a couple of things I don't understand about this proposal. > I'm not > suggesting a change, simply additional rationale/clarification. > > James Carlson wrote: > > The stability of the getconf built-in command-line interface and the > > system variables documented in getconf(1) is Committed; its pathname > > binding to /bin is Volatile. The getconf built-in supports additional > > system variables not available for /usr/bin/getconf; these variables > > are Project Private, and include names prefixed with "AST" and "_AST". > > > What does "its pathname binding" actually mean and is it /bin or /usr/bin? I started to write an explanation of pathname binding...but please refer to Roland's email... At some point, (but, given the conflicting requirements of /usr/bin/getconf vs. xpg4 and xpg6 standards, maybe never), the pathname binding of the ksh93 getconf built-in could go away. No pathname binding would mean that executing "getconf" without a pathname prefix would always execute the getconf built-in, regardless of $PATH. > > These components will initially be used only by the Korn Shell 93 > > Integration Project (PSARC/2006/550). The proposed location of the > > tools in /usr/ast/bin is consistent with the location used within > > AT&T. > > > Ah, battling communities - my favorite. > > We get some degree of flack from the Linux FSH crowd about creating project > specific directories in /usr. The charming FSH spec simply says, "don't > do this" > without saying what to do. It seems like the standard response is to > put such things > either in /opt (reasonable, but a problem for Solaris diskless/zones) or > under /usr/lib > (completely silly in all respects, IMHO, it just moves the problem to > another > directory, one that is repeatedly scanned by ld.so - go figure). > > I guess if ksh93 installed on a Linux system installs into /usr/ast, > with the resultant > wrath of the FSH zelots, we have no problem. If it installs elsewhere, > we need to > have the discussion as to if we should be like Linux or be like legacy > Solaris. Linux may install these utilities under /opt/ast, but this does not work for us because on Solaris, /opt is for unbundled products only, and the AT&T messaging components will be bundled. They are required for the ON build for ksh93, so they must be installed onto build systems. > > Aside: For those who don't know, I personally view the FSH document to > be one of the > worst specifications ever created, but there are zelots out there who > think it was > written on stone tablets. Sigh,... > > If the interface stability level of the shared libraries listed in > > PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from > > Project Private, the stability of the /usr/ast/bin components listed > > below should be promoted to at least the same level, to allow > > consumers of the former to build the appropriate message files. > > > This isn't declarative. It starts with "If". Are the promoted, and if > so, to what? > > Volatile I guess, but it needs to be explicit. > > Interface Description Stability > > --------- ----------- --------- > > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private > > > Why is this interesting to list? (No harm, but I fear I might be > missing something.) > > A new package for AST (Advanced Software Technology) developer tools, > > SUNWastdev, will be created, which includes all of the above > > message-building components. These tools have a dependency on ksh93 > > and its libraries, as listed in PSARC/2006/550, and shall not be > > integrated before the Korn Shell 93 Integration project. > > > What Metacluster is this package to be added to? We would like to add this to the Developer cluster, since it needs to be installed onto build machines. > > - thanks, > > - jek3 > From carlsonj@phorcys.east.sun.com Wed Jan 17 13:42:01 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLg0qK017794 for ; Wed, 17 Jan 2007 13:42:00 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HLft1v020992; Thu, 18 Jan 2007 05:41:56 +0800 (SGT) 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 <0JC10030189V5A00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:41:55 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC100CQ989U2MA0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 13:41:54 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HLfrqr004146; Wed, 17 Jan 2007 16:41:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0HLfrT2004143; Wed, 17 Jan 2007 16:41:53 -0500 (EST) Date: Wed, 17 Jan 2007 16:41:53 -0500 From: James Carlson Subject: Re: [ksh93-integration-discuss] Re: 2007/035 ksh93 Amendments In-reply-to: <45AE9585.69105B2C@nrubsig.org> To: Roland Mainz Cc: Korn Shell 93 integration/migration project discussion , psarc-ext@sun.com, Joseph Kowalski , "April D. Chin" Message-id: <17838.38945.225584.31238@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <17837.8175.713454.985376@gargle.gargle.HOWL> <45AE8867.7060100@sun.com> <45AE87DB.8050009@sun.com> <17838.37216.43596.545010@gargle.gargle.HOWL> <45AE9585.69105B2C@nrubsig.org> Status: RO Content-Length: 1950 Roland Mainz writes: > > My guess would be that it doesn't belong in *any* metacluster, as it's > > really only needed for ksh93 development. If you're going to put it > > into one, then I think it goes in SUNWCall. > > In theory I would prefer that "SUNWastdevl" should go into the same > metacluster as the packages which fill /usr/ccs/bin/. That way we make > sure that the AST l10n generation tools are available when building > OS/Net (otherwise gatekeepers may hear complains about built failure > over and over again just because one package is missing (which happens > near the end of the build, making it an even more nasty "suprise" ... > ;-( )) and save any future changes in the package database if we promote > the stabilty to something higher (e.g. less paperwork in the future... > :-) ). I think that concern is misplaced. There are many packages that are required parts of the ON build process -- this doesn't mean that a default install of the system ought to get them, or that _any_ install should get them. That's why all gates (including ON) include a "common build environment" that specifies what's required in order to do a build. Such as, for instance, SUNWonbld. Getting this package on the list as required for ON builds is a different issue from deciding what metacluster should hold it. Given that developers working on Solaris don't need it (and can't really use its private interfaces), I can't really support having it in anything less than SUNWCall. I'm not sure it belongs there, though. It's more like SUNWwbint or SUNWzoneint than it's like anything else -- it's certainly not in the same class as `/usr/ccs/bin/make', which can be used to build things other than Solaris itself. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Wed Jan 17 13:45:03 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLj3Nv017865 for ; Wed, 17 Jan 2007 13:45:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HLixej024811; Wed, 17 Jan 2007 21:44:59 GMT 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 <0JC1004038EZB900@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 14:44:59 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC1002S88EX2L00@brm-avmta-1.central.sun.com>; Wed, 17 Jan 2007 14:44:58 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HLiu5L004184; Wed, 17 Jan 2007 16:44:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0HLiuBQ004181; Wed, 17 Jan 2007 16:44:56 -0500 (EST) Date: Wed, 17 Jan 2007 16:44:56 -0500 From: James Carlson Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <200701172136.l0HLa5Ix836034@jurassic.eng.sun.com> To: April Chin Cc: jek3@sun.com, psarc-ext@sun.com, Mark Nelson Message-id: <17838.39128.596045.689968@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200701172136.l0HLa5Ix836034@jurassic.eng.sun.com> Status: RO Content-Length: 705 April Chin writes: > > What Metacluster is this package to be added to? > > We would like to add this to the Developer cluster, since it needs > to be installed onto build machines. As this really gets into gate management issues, I'd rather see one of the gatestaff contributing to this thread. The package has nothing to do with developers who happen to work on Solaris. It's needed only by those who build the ON consolidation. Thus, I don't think it belongs in SUNWCprog. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Wed Jan 17 13:51:15 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HLpE9t017897 for ; Wed, 17 Jan 2007 13:51:15 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HLpAjv026330; Wed, 17 Jan 2007 21:51:11 GMT 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 <0JC1002018PBRU00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 13:51:11 -0800 (PST) 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 <0JC1009PJ8PA3MA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 13:51:10 -0800 (PST) Received: from relay13.sun.com (relay13.sun.com [217.140.40.54] (may be forged)) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0HLp9Y1017273; Wed, 17 Jan 2007 13:51:10 -0800 (PST) Received: from mms13es.sun.com ([160.41.223.54] [160.41.223.54]) by relay13.sun.com with ESMTP; Wed, 17 Jan 2007 21:51:09 +0000 (Z) Received: from relay13.sun.com (relay13.sun.com [217.140.40.54]) by mms13es.sun.com with ESMTP; Wed, 17 Jan 2007 21:51:08 +0000 (Z) Received: from mail-in-11.arcor-online.net ([151.189.21.51] [151.189.21.51]) by relay13.sun.com with ESMTP; Wed, 17 Jan 2007 21:51:06 +0000 (Z) Received: from mail-in-02-z2.arcor-online.net (mail-in-02-z2.arcor-online.net [151.189.8.14]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id 8B9D2114EE; Wed, 17 Jan 2007 22:51:06 +0100 (CET) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-02-z2.arcor-online.net (Postfix) with ESMTP id 4B23111385D; Wed, 17 Jan 2007 22:51:06 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-003-125.pools.arcor-ip.net [84.59.3.125]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id BFFB8275776; Wed, 17 Jan 2007 22:51:01 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l0HLouEe001865; Wed, 17 Jan 2007 22:50:58 +0100 (CET) Date: Wed, 17 Jan 2007 22:50:55 +0100 From: Roland Mainz Subject: Re: [ksh93-integration-discuss] Re: 2007/035 ksh93 Amendments Sender: gisburn@jupiterb48.nrubsig.org To: April Chin , Korn Shell 93 integration/migration project discussion Cc: james.d.carlson@sun.com, jek3@sun.com, psarc-ext@sun.com, april.chin@sun.com, gatekeeper@onnv.eng.sun.com Message-id: <45AE9A3F.788BA5D3@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <200701172136.l0HLa5Ix836034@jurassic.eng.sun.com> Status: RO Content-Length: 1965 April Chin wrote: [snip] > > Aside: For those who don't know, I personally view the FSH document to > > be one of the > > worst specifications ever created, but there are zelots out there who > > think it was > > written on stone tablets. Sigh,... > > > If the interface stability level of the shared libraries listed in > > > PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from > > > Project Private, the stability of the /usr/ast/bin components listed > > > below should be promoted to at least the same level, to allow > > > consumers of the former to build the appropriate message files. > > > > > This isn't declarative. It starts with "If". Are the promoted, and if > > so, to what? > > > > Volatile I guess, but it needs to be explicit. > > > Interface Description Stability > > > --------- ----------- --------- > > > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private > > > > > Why is this interesting to list? (No harm, but I fear I might be > > missing something.) > > > A new package for AST (Advanced Software Technology) developer tools, > > > SUNWastdev, will be created, which includes all of the above > > > message-building components. These tools have a dependency on ksh93 > > > and its libraries, as listed in PSARC/2006/550, and shall not be > > > integrated before the Korn Shell 93 Integration project. > > > > > What Metacluster is this package to be added to? > > We would like to add this to the Developer cluster, since it needs > to be installed onto build machines. Alternatively we could ask gatekeepers what they prefer (CC:'ing gatekeeper@onnv.eng.sun.com)... they're likely the first victims if we get this wrong... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From jek3@sun.com Wed Jan 17 14:06:25 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HM6O4q018728 for ; Wed, 17 Jan 2007 14:06:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HM6KMI000019; Wed, 17 Jan 2007 22:06:22 GMT 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 <0JC10050Z9EL5P00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 14:06:21 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC1009RV9EK3MB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 14:06:20 -0800 (PST) Received: from [129.150.12.40] (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HM6EYJ845811; Wed, 17 Jan 2007 14:06:15 -0800 (PST) Date: Wed, 17 Jan 2007 12:04:43 -1000 From: Joseph Kowalski Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <45AE086B.FB822AB0@nrubsig.org> To: Roland Mainz Cc: Glenn Skinner , psarc-ext@sun.com, april.chin@sun.com Message-id: <45AE9D7B.2040204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200701170118.l0H1IfQd010306@ivrel.sfbay.sun.com> <45AE086B.FB822AB0@nrubsig.org> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1637 Roland Mainz wrote: > AFAIK this is not possible. The problem is that /usr/bin/getconf is > compiled as normal application while ksh93 in Solaris is explicitly > compiled as XPG6/C99 application (to enable various features and avoid > that the ksh93 code enables workaronds for older standards functions > (which result in both loss of features and performance)). > The problem is that compiling a Solaris application with the XPG6 flags > changes some "secret" libc master switches (|_xpg4| and |_xpg6|) which > change the behaviour of many libc functions to match the XPG6 standards, > including |sysconf()|, |pathconf()| etc. - which would make the > "getconf" builtin command work like /usr/xpg6/bin/getconf instead of > /usr/bin/getconf (and there is no workaround, neither running the > "getconf" builtin in a seperate child process with |_xpg4|+|_xpg6| set > to "0" (this doesn't work because it doesn't alter the different header > contents (and I doubt that code review would allow such a horrible abuse > of C64-style "poke"'ing)) or poking these values only at runtime of the > "getconf" builtin (end reset it in an exit trap) will work (this would > not be threadsafe)). > Maybe I'm just confused, but this seems to be a good explanation why /usr/bin/getconf can't be a tiny wrapper linking with the library which implements the builtins for ksh93 (I forgot name of said library - probably blocking it in the Freudian sense.) Why couldn't the same *source* be compiled not in xpg mode to produce /usr/bin/getconf. I believe the concern was about sharing source, not about sharing the binary implementation. - jek3 From jek3@sun.com Wed Jan 17 14:33:03 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HMX2Pn019164 for ; Wed, 17 Jan 2007 14:33:02 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HMWuIZ010113; Wed, 17 Jan 2007 22:32:59 GMT 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 <0JC10090FAMWA600@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 14:32:56 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC1009YOAMW3OD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jan 2007 14:32:56 -0800 (PST) Received: from [129.150.12.40] (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0HMWtU2853146; Wed, 17 Jan 2007 14:32:55 -0800 (PST) Date: Wed, 17 Jan 2007 12:31:22 -1000 From: Joseph Kowalski Subject: Re: 2007/035 ksh93 Amendments In-reply-to: <45AE907F.965E3E58@nrubsig.org> To: Roland Mainz Cc: James Carlson , psarc-ext@sun.com, "April D. Chin" Message-id: <45AEA3BA.8040408@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tr1q1dDT+GEn5WKNjpnwDA)" X-PMX-Version: 5.2.0.264296 References: <17837.7570.832139.435888@gargle.gargle.HOWL> <45AE87DB.8050009@sun.com> <45AE907F.965E3E58@nrubsig.org> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 14994 This is a multi-part message in MIME format. --Boundary_(ID_tr1q1dDT+GEn5WKNjpnwDA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Roland Mainz wrote: > Joseph Kowalski wrote: > [snip] > >> James Carlson wrote: >> >>> The stability of the getconf built-in command-line interface and the >>> system variables documented in getconf(1) is Committed; its pathname >>> binding to /bin is Volatile. The getconf built-in supports additional >>> system variables not available for /usr/bin/getconf; these variables >>> are Project Private, and include names prefixed with "AST" and "_AST". >>> >> What does "its pathname binding" actually mean >> > > (Somewhere April wrote a better (and shorter explanation) but I can't > find it right now... ;-( ) > Path name binding means that a builtin is bound to a specific path. The > shell will execute the command in place of the "native" command in the > filesystem if it's found at the path lookup in ${PATH}. > For example if you have a builtin command "grabvictim" bound to > /opt/tentaclemonster/bin/grabvictim then the builtin "grabvictim" will > only be executed if ${PATH} contains /opt/tentaclemonster/bin/ and no > other version of "grabvictim" was found in a ${PATH} element before this > point (="/opt/tentaclemonster/bin/"). > As alternative builtin commands can be added without a path binding > which means they will be executed immediately ("print" and "sleep" are > examples for such builtin commands). > > >> and is it /bin or /usr/bin? >> > > It is both /bin/ and /usr/bin/ - the code detects whether "/bin" is a > softlink to "/usr/bin" and then binds commands bound to "/bin" > automagically to "/usr/bin", too (they're the same filesystem objects > anyway and a different behaviour would be confusing for script authors). > OK. Thanks for the explanation. > >>> These components will initially be used only by the Korn Shell 93 >>> Integration Project (PSARC/2006/550). The proposed location of the >>> tools in /usr/ast/bin is consistent with the location used within >>> AT&T. >>> >>> >> Ah, battling communities - my favorite. >> > > Uh-oh... ;-( > > >> We get some degree of flack from the Linux FSH crowd about creating project >> specific directories in /usr. >> > > How else should the "namespaces" between different projects be defined ? > The ${PATH}/${FPATH} stuff was exactly invented to avoid collisions > between projects and give full control over the lookup order (which is > quite usefull if you want to implement multiple different standards > (e.g. XPG4 in /usr/xpg4/bin, XPG6 in /usr/xpg6/bin, AST in /usr/ast/bin, > UCB in /usr/ucb etc.)). and use them in a mix&match way in the same > operating system instance. > > >> The charming FSH spec simply says, "don't >> do this" >> without saying what to do. It seems like the standard response is to >> put such things >> either in /opt (reasonable, but a problem for Solaris diskless/zones) or >> under /usr/lib >> (completely silly in all respects, IMHO, it just moves the problem to >> another >> directory, one that is repeatedly scanned by ld.so - go figure). >> >> I guess if ksh93 installed on a Linux system installs into /usr/ast, >> with the resultant >> wrath of the FSH zelots, we have no problem. If it installs elsewhere, >> we need to >> have the discussion as to if we should be like Linux or be like legacy >> Solaris. >> > > Usually the AST tools are installed in either /usr/ast/ or /opt/ast/ > depending on the preference of the package builder. We'd like to go for > /usr/ast/ since ksh93 should be a more integral part of Solaris (we're > building it as part of OS/Net, remember ? :-) ) and not some kind of > external software which is tacked-on later (all stuff which goes into > /opt). > > >> Aside: For those who don't know, I personally view the FSH document to >> be one of the >> worst specifications ever created, but there are zelots out there who >> think it was >> written on stone tablets. Sigh,... >> > > ... yeah... it's funny to see how they try to deal with the problem that > some tools have the same name... =:-) > I'm OK with this response. I wanted to be sure it had been considered. Aside,... I always thought PATH was a great idea. I guess the FSH authors (and Linux developers in general) don't. Certainly throwing everything into /usr/bin makes things easy for the newbee, but it takes a great tool away from the (even slightly) experienced user. > >>> If the interface stability level of the shared libraries listed in >>> PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from >>> Project Private, the stability of the /usr/ast/bin components listed >>> below should be promoted to at least the same level, to allow >>> consumers of the former to build the appropriate message files. >>> >>> >> This isn't declarative. It starts with "If". Are the promoted, and if >> so, to what? >> > > Uhm... to the same level as needed by the consumers of > libshell/libcmd/libast etc. ? > > I think what I'm asking for is simply that that "If" be deleted from the first sentence. They *are* promoted, right? (Also, "is" then changed to "are".) >> Volatile I guess, but it needs to be explicit. >> >>> Interface Description Stability >>> --------- ----------- --------- >>> /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private >>> >>> >> Why is this interesting to list? (No harm, but I fear I might be >> missing something.) >> > > It's a new filesystem object... AFAIK the ARC case must list them, right > ? > OK. The ARC case isn't required to list everything private, but it never hurts. Since this goes in a well known directory, it was probably a very good idea to list it. As I said, I was just making sure I hadn't missed something. > >>> A new package for AST (Advanced Software Technology) developer tools, >>> SUNWastdev, will be created, which includes all of the above >>> message-building components. These tools have a dependency on ksh93 >>> and its libraries, as listed in PSARC/2006/550, and shall not be >>> integrated before the Korn Shell 93 Integration project. >>> >>> >> What Metacluster is this package to be added to? >> > > AFAIK April can answer that better than I... but I guess it belongs to > the development cluster (e,g, similar to the packages which deliver into > /usr/css/bin/). > That's the answer I expected. Thanks. - jek3 --Boundary_(ID_tr1q1dDT+GEn5WKNjpnwDA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Roland Mainz wrote: 
Joseph Kowalski wrote:
[snip]
  
James Carlson wrote:
    
The stability of the getconf built-in command-line interface and the
system variables documented in getconf(1) is Committed; its pathname
binding to /bin is Volatile.  The getconf built-in supports additional
system variables not available for /usr/bin/getconf; these variables
are Project Private, and include names prefixed with "AST" and "_AST".
      
What does "its pathname binding" actually mean
    

(Somewhere April wrote a better (and shorter explanation) but I can't
find it right now... ;-( )
Path name binding means that a builtin is bound to a specific path. The
shell will execute the command in place of the "native" command in the
filesystem if it's found at the path lookup in ${PATH}.
For example if you have a builtin command "grabvictim" bound to
/opt/tentaclemonster/bin/grabvictim then the builtin "grabvictim" will
only be executed if ${PATH} contains /opt/tentaclemonster/bin/ and no
other version of "grabvictim" was found in a ${PATH} element before this
point (="/opt/tentaclemonster/bin/").
As alternative builtin commands can be added without a path binding
which means they will be executed immediately ("print" and "sleep" are
examples for such builtin commands).

  
and is it /bin or /usr/bin?
    

It is both /bin/ and /usr/bin/ - the code detects whether "/bin" is a
softlink to "/usr/bin" and then binds commands bound to "/bin"
automagically to "/usr/bin", too (they're the same filesystem objects
anyway and a different behaviour would be confusing for script authors).
OK.  Thanks for the explanation.
  
These components will initially be used only by the Korn Shell 93
Integration Project (PSARC/2006/550).  The proposed location of the
tools in /usr/ast/bin is consistent with the location used within
AT&T.

      
Ah, battling communities - my favorite.
    

Uh-oh... ;-(

  
We get some degree of flack from the Linux FSH crowd about creating project
specific directories in /usr.
    

How else should the "namespaces" between different projects be defined ?
The ${PATH}/${FPATH} stuff was exactly invented to avoid collisions
between projects and give full control over the lookup order (which is
quite usefull if you want to implement multiple different standards
(e.g. XPG4 in /usr/xpg4/bin, XPG6 in /usr/xpg6/bin, AST in /usr/ast/bin,
UCB in /usr/ucb etc.)). and use them in a mix&match way in the same
operating system instance.

  
The charming FSH spec simply says, "don't
do this"
without saying what to do.  It seems like the standard response is to
put such things
either in /opt (reasonable, but a problem for Solaris diskless/zones) or
under /usr/lib
(completely silly in all respects, IMHO, it just moves the problem to
another
directory, one that is repeatedly scanned by ld.so - go figure).

I guess if ksh93 installed on a Linux system installs into /usr/ast,
with the resultant
wrath of the FSH zelots, we have no problem.  If it installs elsewhere,
we need to
have the discussion as to if we should be like Linux or be like legacy
Solaris.
    

Usually the AST tools are installed in either /usr/ast/ or /opt/ast/
depending on the preference of the package builder. We'd like to go for
/usr/ast/ since ksh93 should be a more integral part of Solaris (we're
building it as part of OS/Net, remember ? :-) ) and not some kind of
external software which is tacked-on later (all stuff which goes into
/opt).

  
Aside: For those who don't know, I personally view the FSH document to
be one of the
worst specifications ever created, but there are zelots out there who
think it was
written on stone tablets.  Sigh,...
    

... yeah... it's funny to see how they try to deal with the problem that
some tools have the same name... =:-)
I'm OK with this response.  I wanted to be sure it had been considered.

Aside,... I always thought PATH was a great idea.  I guess the FSH authors (and Linux
developers in general) don't.  Certainly throwing everything into /usr/bin makes things
easy for the newbee, but it takes a great tool away from the (even slightly) experienced
user.
  
If the interface stability level of the shared libraries listed in
PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from
Project Private, the stability of the /usr/ast/bin components listed
below should be promoted to at least the same level, to allow
consumers of the former to build the appropriate message files.

      
This isn't declarative.  It starts with "If".  Are the promoted, and if
so, to what?
    

Uhm... to the same level as needed by the consumers of
libshell/libcmd/libast etc. ?
I think what I'm asking for is simply that that "If" be deleted from the first sentence.
They *are* promoted, right?  (Also, "is" then changed to "are".)


  

    
Volatile I guess, but it needs to be explicit.
    

    

      
Interface             Description                             Stability
---------             -----------                             ---------
/usr/lib/libpp.so.1   AT&T ANSI C preprocessor library        Project Private

      

    

    
Why is this interesting to list?  (No harm, but I fear I might be
missing something.)
    

  

  

It's a new filesystem object... AFAIK the ARC case must list them, right
?
  



OK.



The ARC case isn't required to list everything private, but it never
hurts.  Since this goes

in a well known directory, it was probably a very good idea to list
it.  As I said, I was

just making sure I hadn't missed something.



  
  

  

    

      
A new package for AST (Advanced Software Technology) developer tools,
SUNWastdev, will be created, which includes all of the above
message-building components. These tools have a dependency on ksh93
and its libraries, as listed in PSARC/2006/550, and shall not be
integrated before the Korn Shell 93 Integration project.

      

    

    
What Metacluster is this package to be added to?
    

  

  

AFAIK April can answer that better than I... but I guess it belongs to
the development cluster (e,g, similar to the packages which deliver into
/usr/css/bin/).
  



That's the answer I expected.  Thanks.



- jek3








--Boundary_(ID_tr1q1dDT+GEn5WKNjpnwDA)--

From roland.mainz@nrubsig.org Wed Jan 17 14:34:05 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HMY35T019261
	for ; Wed, 17 Jan 2007 14:34:04 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HMXv2v026951;
	Thu, 18 Jan 2007 06:34:00 +0800 (SGT)
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 <0JC100A0HAOM8500@brm-avmta-1.central.sun.com>; Wed,
 17 Jan 2007 15:33:58 -0700 (MST)
Received: from sca-ea-mail-2.sun.com ([192.18.43.25])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC1002HBAOJ2H40@brm-avmta-1.central.sun.com>; Wed,
 17 Jan 2007 15:33:55 -0700 (MST)
Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged))
	by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0HMOG1B001855;
 Wed, 17 Jan 2007 14:33:55 -0800 (PST)
Received: from mms06es.sun.com ([150.143.104.114] [150.143.104.114])
 by relay1.sun.com with ESMTP; Wed, 17 Jan 2007 22:33:54 +0000 (Z)
Received: from relay3.sun.com (relay3.sun.com [150.143.103.54])
 by mms06es.sun.com with ESMTP; Wed, 17 Jan 2007 22:33:54 +0000 (Z)
Received: from mail-in-05.arcor-online.net ([151.189.21.45] [151.189.21.45])
 by relay3.sun.com with ESMTP; Wed, 17 Jan 2007 22:33:54 +0000 (Z)
Received: from mail-in-01-z2.arcor-online.net
 (mail-in-05-z2.arcor-online.net [151.189.8.17])	by mail-in-05.arcor-online.net
 (Postfix) with ESMTP id AA39F12E901; Wed, 17 Jan 2007 23:33:53 +0100 (CET)
Received: from mail-in-05.arcor-online.net
 (mail-in-05.arcor-online.net [151.189.21.45])
	by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 9D6F72DAA26; Wed,
 17 Jan 2007 23:33:53 +0100 (CET)
Received: from jupiterb48.nrubsig.org
 (dslb-084-059-003-125.pools.arcor-ip.net [84.59.3.125])
	by mail-in-05.arcor-online.net (Postfix) with ESMTP id 5C7C512E88C; Wed,
 17 Jan 2007 23:33:53 +0100 (CET)
Received: from nrubsig.org (localhost [127.0.0.1])	by jupiterb48.nrubsig.org
 (8.13.8+Sun/8.13.8) with ESMTP id l0HMXmNv001878; Wed,
 17 Jan 2007 23:33:51 +0100 (CET)
Date: Wed, 17 Jan 2007 23:33:48 +0100
From: Roland Mainz 
Subject: Re: 2007/035 ksh93 Amendments
Sender: gisburn@jupiterb48.nrubsig.org
To: Joseph Kowalski 
Cc: Glenn Skinner , psarc-ext@sun.com,
        april.chin@sun.com
Message-id: <45AEA44C.99827147@nrubsig.org>
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-PMX-Version: 5.2.0.264296
References: <200701170118.l0H1IfQd010306@ivrel.sfbay.sun.com>
 <45AE086B.FB822AB0@nrubsig.org> <45AE9D7B.2040204@sun.com>
Status: RO
Content-Length: 2076

Joseph Kowalski wrote:
> Roland Mainz wrote:
[snip]
> Maybe I'm just confused, but this seems to be a good explanation why
> /usr/bin/getconf
> can't be a tiny wrapper linking with the library which implements the
> builtins for ksh93
> (I forgot name of said library - probably blocking it in the Freudian
> sense.)
> 
> Why couldn't the same *source* be compiled not in xpg mode to produce
> /usr/bin/getconf.
> I believe the concern was about sharing source, not about sharing the
> binary implementation.

Ouch... the getconf builtin needs libast (see Glenn's earlier email
about |astconf()|&co.) which means we would need two versions of libast
(compiled for both 32bit and 64bit (= four binaries)). Quick look at the
codebase:
$ du -ks src/lib/libast/common 
9505    src/lib/libast/common
...which means it's not really "small".
Another problem is that we would have to generate the libast headers
four times: One time 32bit XPG6/C99, one time 64bit XPG6/C99, one time
32bit "normal" and one time 64bit "normal". And we would have to test
the resulting ... uhm... "thing".
Once this is done we still hit the problem that the current process
defines the |_xpg4| and |_xpg6| variables and not the current library
we're currently executing. This means we need to |fork()|+|exec()| a new
process which uses these "special" XPG6-less libraries. At this point I
try t stop to imagine the horror of such a design... we would need to
ARC the new extra versions of the various AST libraries, need extra
testing etc. etc. And this doesn't even handle the siblings of
/usr/bin/getconf, e.g. /usr/xpg4/bin/getconf and /usr/xpg6/bin/getconf
(which are build from the same sources as /usr/bin/getconf (only using
different build flags)) - how should we deal with these binaries ?
Create another set of AST libraries compiled for specific for XPG4 ?
What happens if we get a XPG8 or XPG10 some day ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

From jek3@sun.com Wed Jan 17 14:40:57 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HMeuIo019802
	for ; Wed, 17 Jan 2007 14:40:57 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HMejs5028866;
	Thu, 18 Jan 2007 06:40:50 +0800 (SGT)
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 <0JC100A05AZZR000@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 17 Jan 2007 14:40:47 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.108.38])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC1009X9AZZ3OE0@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 17 Jan 2007 14:40:47 -0800 (PST)
Received: from [129.150.12.40]
 (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40])	by jurassic.eng.sun.com
 (8.13.8+Sun/8.13.8) with ESMTP id l0HMekMr856016; Wed,
 17 Jan 2007 14:40:46 -0800 (PST)
Date: Wed, 17 Jan 2007 12:39:17 -1000
From: Joseph Kowalski 
Subject: Re: 2007/035 ksh93 Amendments
In-reply-to: <17838.37216.43596.545010@gargle.gargle.HOWL>
To: James Carlson 
Cc: psarc-ext@sun.com, "April D. Chin" 
Message-id: <45AEA595.7090703@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Z2TRIlYVO8E9w6c/oyBlYA)"
X-PMX-Version: 5.2.0.264296
References: <17837.7570.832139.435888@gargle.gargle.HOWL>
 <17837.8175.713454.985376@gargle.gargle.HOWL> <45AE8867.7060100@sun.com>
 <45AE87DB.8050009@sun.com> <17838.37216.43596.545010@gargle.gargle.HOWL>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 4272

This is a multi-part message in MIME format.

--Boundary_(ID_Z2TRIlYVO8E9w6c/oyBlYA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

James Carlson wrote:
>>> If the interface stability level of the shared libraries listed in
>>> PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from
>>> Project Private, the stability of the /usr/ast/bin components listed
>>> below should be promoted to at least the same level, to allow
>>> consumers of the former to build the appropriate message files.
>>>   
>>>       
>> This isn't declarative.  It starts with "If".  Are the promoted, and if 
>> so, to what?
>>     
>
> No promotion, no change.  It's a statement about what must occur in
> the future _if_ any such project is undertaken.  In other words, these
> things are functionally linked -- if you promote one, then you need to
> promote the other, or have a very good reason not to.
>
> If it helps, just ignore that paragraph.  It's not delivering
> anything.
>
>   
>> Volatile I guess, but it needs to be explicit.
>>     
>
> They remain as they are.
>   
I'm getting more confused.  The paragraph says:

    Stability(libraries) = Project Private
    Stability(libraries) >= Stability(utilities)

And the table then asserts that the utilities are Volatile.

That doesn't seem to make sense to me.  What part am I misreading?

> Good question -- Roland?
>
> My guess would be that it doesn't belong in *any* metacluster, as it's
> really only needed for ksh93 development.  If you're going to put it
> into one, then I think it goes in SUNWCall.
>   
I prefer Rolands SUNWCdev answer.  It really doesn't matter much because the
delta between Cdev and Call is so minimal, I don't think anybody 
actually uses
Cdev.

- jek3

--Boundary_(ID_Z2TRIlYVO8E9w6c/oyBlYA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT




  


James Carlson wrote:



  

    

      
If the interface stability level of the shared libraries listed in
PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from
Project Private, the stability of the /usr/ast/bin components listed
below should be promoted to at least the same level, to allow
consumers of the former to build the appropriate message files.
  
      

    

    
This isn't declarative.  It starts with "If".  Are the promoted, and if 
so, to what?
    

  

  

No promotion, no change.  It's a statement about what must occur in
the future _if_ any such project is undertaken.  In other words, these
things are functionally linked -- if you promote one, then you need to
promote the other, or have a very good reason not to.

If it helps, just ignore that paragraph.  It's not delivering
anything.

  

  

    
Volatile I guess, but it needs to be explicit.
    

  

  

They remain as they are.
  



I'm getting more confused.  The paragraph says:



    Stability(libraries) = Project Private

    Stability(libraries) >= Stability(utilities)



And the table then asserts that the utilities are Volatile.



That doesn't seem to make sense to me.  What part am I misreading?





  
Good question -- Roland?

My guess would be that it doesn't belong in *any* metacluster, as it's
really only needed for ksh93 development.  If you're going to put it
into one, then I think it goes in SUNWCall.
  



I prefer Rolands SUNWCdev answer.  It really doesn't matter much
because the

delta between Cdev and Call is so minimal, I don't think anybody
actually uses

Cdev.



- jek3




--Boundary_(ID_Z2TRIlYVO8E9w6c/oyBlYA)--

From April.Chin@eng.sun.com Wed Jan 17 15:07:36 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HN7a8Y020714
	for ; Wed, 17 Jan 2007 15:07:36 -0800 (PST)
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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0HN7YWB007538;
	Wed, 17 Jan 2007 15:07:34 -0800 (PST)
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 <0JC10090BC8MD400@nwk-avmta-2.sfbay.sun.com>; Wed,
 17 Jan 2007 15:07:34 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.224.130])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC100C3GC8M27F0@nwk-avmta-2.sfbay.sun.com>; Wed,
 17 Jan 2007 15:07:34 -0800 (PST)
Received: from aragon (aragon.SFBay.Sun.COM [129.146.226.123])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l0HN7X14863866; Wed,
 17 Jan 2007 15:07:33 -0800 (PST)
Date: Wed, 17 Jan 2007 15:05:24 -0800 (PST)
From: April Chin 
Subject: Re: 2007/035 ksh93 Amendments
To: James.D.Carlson@sun.com, jek3@sun.com
Cc: psarc-ext@sun.com, april.chin@sun.com
Reply-to: April Chin 
Message-id: <200701172307.l0HN7X14863866@jurassic.eng.sun.com>
MIME-version: 1.0
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_31 SunOS 5.11 sun4u sparc
Content-type: TEXT/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-MD5: qM4dMhpruo09DV5BFotxJg==
X-PMX-Version: 5.2.0.264296
Status: RO
Content-Length: 2324


> Date: Wed, 17 Jan 2007 12:39:17 -1000
> From: Joseph Kowalski 
> Subject: Re: 2007/035 ksh93 Amendments
> To: James Carlson 
> Cc: psarc-ext@sun.com, "April D. Chin" 
> MIME-version: 1.0
> X-PMX-Version: 5.2.0.264296
> User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
> 
> James Carlson wrote:
> >>> If the interface stability level of the shared libraries listed in
> >>> PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from
> >>> Project Private, the stability of the /usr/ast/bin components listed
> >>> below should be promoted to at least the same level, to allow
> >>> consumers of the former to build the appropriate message files.
> >>>   
> >>>       
> >> This isn't declarative.  It starts with "If".  Are the promoted, and if 
> >> so, to what?
> >>     
> >
> > No promotion, no change.  It's a statement about what must occur in
> > the future _if_ any such project is undertaken.  In other words, these
> > things are functionally linked -- if you promote one, then you need to
> > promote the other, or have a very good reason not to.
> >
> > If it helps, just ignore that paragraph.  It's not delivering
> > anything.
> >
> >   
> >> Volatile I guess, but it needs to be explicit.
> >>     
> >
> > They remain as they are.
> >   
> I'm getting more confused.  The paragraph says:
> 
>     Stability(libraries) = Project Private
>     Stability(libraries) >= Stability(utilities)
> 
> And the table then asserts that the utilities are Volatile.
> 
> That doesn't seem to make sense to me.  What part am I misreading?

Actually, it is
    Stability(libraries) = Project Private
    Stability(utilities) must be >= Stability(libraries)
    
The /usr/ast/bin message-building utilities are needed by users who
compile using the library interfaces in libcmd, libshell, libast, libdll.
Right now, the only consumer is the ksh93 project.
The libraries have a dependency on the message-building utilities.

The utilities have a stability level of Volatile, so they are a form
of Public which is several steps above the Project Private level
of the libraries.  So maybe the case would be clearer if it said: 
"If the interface stability level of the libraries 
is promoted above the current stability level of the utilities..."

	April


From roland.mainz@nrubsig.org Wed Jan 17 15:14:48 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HNElGb021444
	for ; Wed, 17 Jan 2007 15:14:48 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HNEYTQ019225;
	Wed, 17 Jan 2007 23:14:44 GMT
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 <0JC100G0BCKI7H00@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 17 Jan 2007 15:14:42 -0800 (PST)
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 <0JC100CV2CKIIW10@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 17 Jan 2007 15:14:42 -0800 (PST)
Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged))
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0HL5XSg029464; Wed,
 17 Jan 2007 16:14:42 -0700 (MST)
Received: from mms06es.sun.com ([150.143.104.114] [150.143.104.114])
 by relay3.sun.com with ESMTP; Wed, 17 Jan 2007 23:14:38 +0000 (Z)
Received: from relay3.sun.com (relay3.sun.com [150.143.103.54])
 by mms06es.sun.com with ESMTP; Wed, 17 Jan 2007 23:14:38 +0000 (Z)
Received: from mail-in-06.arcor-online.net ([151.189.21.46] [151.189.21.46])
 by relay3.sun.com with ESMTP; Wed, 17 Jan 2007 23:14:38 +0000 (Z)
Received: from mail-in-08-z2.arcor-online.net
 (mail-in-08-z2.arcor-online.net [151.189.8.20])	by mail-in-06.arcor-online.net
 (Postfix) with ESMTP id 8715E97B73; Thu, 18 Jan 2007 00:14:37 +0100 (CET)
Received: from mail-in-12.arcor-online.net
 (mail-in-12.arcor-online.net [151.189.21.52])
	by mail-in-08-z2.arcor-online.net (Postfix) with ESMTP id 7B927212FA8; Thu,
 18 Jan 2007 00:14:37 +0100 (CET)
Received: from jupiterb48.nrubsig.org
 (dslb-084-059-003-125.pools.arcor-ip.net [84.59.3.125])
	by mail-in-12.arcor-online.net (Postfix) with ESMTP id 5608EA4521; Thu,
 18 Jan 2007 00:14:37 +0100 (CET)
Received: from nrubsig.org (localhost [127.0.0.1])	by jupiterb48.nrubsig.org
 (8.13.8+Sun/8.13.8) with ESMTP id l0HNEU1d001887; Thu,
 18 Jan 2007 00:14:35 +0100 (CET)
Date: Thu, 18 Jan 2007 00:14:29 +0100
From: Roland Mainz 
Subject: Re: 2007/035 ksh93 Amendments
Sender: gisburn@jupiterb48.nrubsig.org
To: Joseph Kowalski 
Cc: James Carlson , psarc-ext@sun.com,
        "April D. Chin" 
Message-id: <45AEADD5.73D24031@nrubsig.org>
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-PMX-Version: 5.2.0.264296
References: <17837.7570.832139.435888@gargle.gargle.HOWL>
 <45AE87DB.8050009@sun.com> <45AE907F.965E3E58@nrubsig.org>
 <45AEA3BA.8040408@sun.com>
Status: RO
Content-Length: 1203

> Joseph Kowalski wrote:
> Roland Mainz wrote:
> > Joseph Kowalski wrote:
[snip]
> > Uhm... to the same level as needed by the consumers of
> > libshell/libcmd/libast etc. ?
>
> I think what I'm asking for is simply that that "If" be deleted from
> the first sentence.
> They *are* promoted, right?  (Also, "is" then changed to "are".)

(Usual disclaimer: I am no expert for interface taxonomity and usually
cause havoc and destruction with my answers... ;-( )
If someone wants to use libshell adn/or libast in their application and
needs localisation (=l10n) support (which is mandatory for applications
in OS/Net) then the ASR l10n tools are needed, too. AFAIK this means
that both the interface stabilty level of the AST libraries and the AST
l10n tools needs to be in sync (or at least part of them needs to be in
sync where stability_of_ast_library <= stabilty_of_ast_l10n_utility
(assuming that we only bump parts of the library API to a higher
stability status while other parts remain at less stable levels)).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

From jek3@sun.com Wed Jan 17 15:36:34 2007
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HNaYgj023217
	for ; Wed, 17 Jan 2007 15:36:34 -0800 (PST)
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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0HNaXrA012361;
	Wed, 17 Jan 2007 15:36:33 -0800 (PST)
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 <0JC100B01DKWFM00@nwk-avmta-2.sfbay.sun.com>; Wed,
 17 Jan 2007 15:36:32 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.56.144])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC100B6IDKWA400@nwk-avmta-2.sfbay.sun.com>; Wed,
 17 Jan 2007 15:36:32 -0800 (PST)
Received: from [129.150.12.40]
 (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40])	by jurassic.eng.sun.com
 (8.13.8+Sun/8.13.8) with ESMTP id l0HNaP3N874910; Wed,
 17 Jan 2007 15:36:26 -0800 (PST)
Date: Wed, 17 Jan 2007 13:34:53 -1000
From: Joseph Kowalski 
Subject: Re: 2007/035 ksh93 Amendments
In-reply-to: <45AEA44C.99827147@nrubsig.org>
To: Roland Mainz 
Cc: Glenn Skinner , psarc-ext@sun.com,
        april.chin@sun.com
Message-id: <45AEB29D.9090007@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_t5Gp7ZbFjnM7qaN9YIWq2Q)"
X-PMX-Version: 5.2.0.264296
References: <200701170118.l0H1IfQd010306@ivrel.sfbay.sun.com>
 <45AE086B.FB822AB0@nrubsig.org> <45AE9D7B.2040204@sun.com>
 <45AEA44C.99827147@nrubsig.org>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 5770

This is a multi-part message in MIME format.

--Boundary_(ID_t5Gp7ZbFjnM7qaN9YIWq2Q)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT


I think we've pursued this "shared source" issue enough in the context 
of this thread/case.
I'd hoped to get some type of assurance that the getconf duplication was 
a short tem
problem, but it seems not to be.  That said, I'm not going to object to 
this proposal on
the basis that it replicates a bit of source.  Besides, if I understand 
the issues here, the
cure of extensive Makefile munging may be worse than the disease.

thread closed.

- jek3

Roland Mainz wrote:
> Joseph Kowalski wrote:
>   
>> Roland Mainz wrote:
>>     
> [snip]
>   
>> Maybe I'm just confused, but this seems to be a good explanation why
>> /usr/bin/getconf
>> can't be a tiny wrapper linking with the library which implements the
>> builtins for ksh93
>> (I forgot name of said library - probably blocking it in the Freudian
>> sense.)
>>
>> Why couldn't the same *source* be compiled not in xpg mode to produce
>> /usr/bin/getconf.
>> I believe the concern was about sharing source, not about sharing the
>> binary implementation.
>>     
>
> Ouch... the getconf builtin needs libast (see Glenn's earlier email
> about |astconf()|&co.) which means we would need two versions of libast
> (compiled for both 32bit and 64bit (= four binaries)). Quick look at the
> codebase:
> $ du -ks src/lib/libast/common 
> 9505    src/lib/libast/common
> ...which means it's not really "small".
> Another problem is that we would have to generate the libast headers
> four times: One time 32bit XPG6/C99, one time 64bit XPG6/C99, one time
> 32bit "normal" and one time 64bit "normal". And we would have to test
> the resulting ... uhm... "thing".
> Once this is done we still hit the problem that the current process
> defines the |_xpg4| and |_xpg6| variables and not the current library
> we're currently executing. This means we need to |fork()|+|exec()| a new
> process which uses these "special" XPG6-less libraries. At this point I
> try t stop to imagine the horror of such a design... we would need to
> ARC the new extra versions of the various AST libraries, need extra
> testing etc. etc. And this doesn't even handle the siblings of
> /usr/bin/getconf, e.g. /usr/xpg4/bin/getconf and /usr/xpg6/bin/getconf
> (which are build from the same sources as /usr/bin/getconf (only using
> different build flags)) - how should we deal with these binaries ?
> Create another set of AST libraries compiled for specific for XPG4 ?
> What happens if we get a XPG8 or XPG10 some day ?
>
> ----
>
> Bye,
> Roland
>
>   


--Boundary_(ID_t5Gp7ZbFjnM7qaN9YIWq2Q)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT




  




I think we've pursued this "shared source" issue enough in the context
of this thread/case.

I'd hoped to get some type of assurance that the getconf duplication
was a short tem

problem, but it seems not to be.  That said, I'm not going to object to
this proposal on

the basis that it replicates a bit of source.  Besides, if I understand
the issues here, the

cure of extensive Makefile munging may be worse than the disease.



thread closed.



- jek3



Roland Mainz wrote:


  
Joseph Kowalski wrote:
  

  

    
Roland Mainz wrote:
    

  

  
[snip]
  

  

    
Maybe I'm just confused, but this seems to be a good explanation why
/usr/bin/getconf
can't be a tiny wrapper linking with the library which implements the
builtins for ksh93
(I forgot name of said library - probably blocking it in the Freudian
sense.)

Why couldn't the same *source* be compiled not in xpg mode to produce
/usr/bin/getconf.
I believe the concern was about sharing source, not about sharing the
binary implementation.
    

  

  

Ouch... the getconf builtin needs libast (see Glenn's earlier email
about |astconf()|&co.) which means we would need two versions of libast
(compiled for both 32bit and 64bit (= four binaries)). Quick look at the
codebase:
$ du -ks src/lib/libast/common 
9505    src/lib/libast/common
...which means it's not really "small".
Another problem is that we would have to generate the libast headers
four times: One time 32bit XPG6/C99, one time 64bit XPG6/C99, one time
32bit "normal" and one time 64bit "normal". And we would have to test
the resulting ... uhm... "thing".
Once this is done we still hit the problem that the current process
defines the |_xpg4| and |_xpg6| variables and not the current library
we're currently executing. This means we need to |fork()|+|exec()| a new
process which uses these "special" XPG6-less libraries. At this point I
try t stop to imagine the horror of such a design... we would need to
ARC the new extra versions of the various AST libraries, need extra
testing etc. etc. And this doesn't even handle the siblings of
/usr/bin/getconf, e.g. /usr/xpg4/bin/getconf and /usr/xpg6/bin/getconf
(which are build from the same sources as /usr/bin/getconf (only using
different build flags)) - how should we deal with these binaries ?
Create another set of AST libraries compiled for specific for XPG4 ?
What happens if we get a XPG8 or XPG10 some day ?

----

Bye,
Roland

  








--Boundary_(ID_t5Gp7ZbFjnM7qaN9YIWq2Q)--

From jek3@sun.com Wed Jan 17 15:40:56 2007
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HNeu3h023913
	for ; Wed, 17 Jan 2007 15:40:56 -0800 (PST)
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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0HNesaC012793;
	Wed, 17 Jan 2007 15:40:55 -0800 (PST)
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 <0JC100G05DS6T300@brm-avmta-1.central.sun.com>; Wed,
 17 Jan 2007 16:40:54 -0700 (MST)
Received: from jurassic.eng.sun.com ([129.146.226.130])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC1002RWDS62R80@brm-avmta-1.central.sun.com>; Wed,
 17 Jan 2007 16:40:54 -0700 (MST)
Received: from [129.150.12.40]
 (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40])	by jurassic.eng.sun.com
 (8.13.8+Sun/8.13.8) with ESMTP id l0HNer9w876843; Wed,
 17 Jan 2007 15:40:53 -0800 (PST)
Date: Wed, 17 Jan 2007 13:39:25 -1000
From: Joseph Kowalski 
Subject: Re: 2007/035 ksh93 Amendments
In-reply-to: <200701172307.l0HN7X14863866@jurassic.eng.sun.com>
To: April Chin 
Cc: James.D.Carlson@sun.com, psarc-ext@sun.com, april.chin@sun.com
Message-id: <45AEB3AD.7080905@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <200701172307.l0HN7X14863866@jurassic.eng.sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 814

April Chin wrote:
> Actually, it is
>     Stability(libraries) = Project Private
>     Stability(utilities) must be >= Stability(libraries)
>     
> The /usr/ast/bin message-building utilities are needed by users who
> compile using the library interfaces in libcmd, libshell, libast, libdll.
> Right now, the only consumer is the ksh93 project.
> The libraries have a dependency on the message-building utilities.
>   
Oh, I get it.
> The utilities have a stability level of Volatile, so they are a form
> of Public which is several steps above the Project Private level
> of the libraries.  So maybe the case would be clearer if it said: 
> "If the interface stability level of the libraries 
> is promoted above the current stability level of the utilities..."
>   
Please make this change.

- thanks,

- jek3


From April.Chin@eng.sun.com Wed Jan 17 15:52:31 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HNqUSS024536
	for ; Wed, 17 Jan 2007 15:52:30 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0HNq9c5026317;
	Wed, 17 Jan 2007 23:52:27 GMT
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 <0JC100I05EBCKA00@brm-avmta-1.central.sun.com>; Wed,
 17 Jan 2007 16:52:24 -0700 (MST)
Received: from jurassic.eng.sun.com ([129.146.104.45])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC1002FEEBC2R90@brm-avmta-1.central.sun.com>; Wed,
 17 Jan 2007 16:52:24 -0700 (MST)
Received: from aragon (aragon.SFBay.Sun.COM [129.146.226.123])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l0HNqNOo880529; Wed,
 17 Jan 2007 15:52:23 -0800 (PST)
Date: Wed, 17 Jan 2007 15:50:14 -0800 (PST)
From: April Chin 
Subject: Re: 2007/035 ksh93 Amendments
To: April.Chin@eng.sun.com, jek3@sun.com
Cc: James.D.Carlson@sun.com, psarc-ext@sun.com, april.chin@sun.com
Reply-to: April Chin 
Message-id: <200701172352.l0HNqNOo880529@jurassic.eng.sun.com>
MIME-version: 1.0
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_31 SunOS 5.11 sun4u sparc
Content-type: TEXT/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-MD5: rXusBJrT8qYGzXa2/FM3bg==
X-PMX-Version: 5.2.0.264296
Status: RO
Content-Length: 1237


> Date: Wed, 17 Jan 2007 13:39:25 -1000
> From: Joseph Kowalski 
> User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
> MIME-Version: 1.0
> To: April Chin 
> CC: James.D.Carlson@sun.com, psarc-ext@sun.com, april.chin@sun.com
> Subject: Re: 2007/035 ksh93 Amendments
> Content-Transfer-Encoding: 7bit
> 
> April Chin wrote:
> > Actually, it is
> >     Stability(libraries) = Project Private
> >     Stability(utilities) must be >= Stability(libraries)
> >     
> > The /usr/ast/bin message-building utilities are needed by users who
> > compile using the library interfaces in libcmd, libshell, libast, libdll.
> > Right now, the only consumer is the ksh93 project.
> > The libraries have a dependency on the message-building utilities.
> >   
> Oh, I get it.
> > The utilities have a stability level of Volatile, so they are a form
> > of Public which is several steps above the Project Private level
> > of the libraries.  So maybe the case would be clearer if it said: 
> > "If the interface stability level of the libraries 
> > is promoted above the current stability level of the utilities..."
> >   
> Please make this change.

Okay, I'll fix this.

Thanks,
	April
> 
> - thanks,
> 
> - jek3
> 


From April.Chin@eng.sun.com Wed Jan 17 16:46:43 2007
Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0I0khFw028201
	for ; Wed, 17 Jan 2007 16:46:43 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0I0kfR18073;
	Wed, 17 Jan 2007 17:46:41 -0700 (MST)
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 <0JC100903GTTW100@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 17 Jan 2007 16:46:41 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.228.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC100COFGTSJB60@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 17 Jan 2007 16:46:40 -0800 (PST)
Received: from aragon (aragon.SFBay.Sun.COM [129.146.226.123])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l0I0keJ5902722; Wed,
 17 Jan 2007 16:46:40 -0800 (PST)
Date: Wed, 17 Jan 2007 16:44:29 -0800 (PST)
From: April Chin 
Subject: 2007/035 ksh93 Amendments: updated 1-pager
To: psarc-ext@sun.com
Cc: james.d.carlson@sun.com, april.chin@sun.com, roland.mainz@nrubsig.org
Reply-to: April Chin 
Message-id: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
MIME-version: 1.0
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_31 SunOS 5.11 sun4u sparc
Content-type: TEXT/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-MD5: qVePzf76mrpt5g7bvNOa2g==
X-PMX-Version: 5.2.0.264296
Status: RO
Content-Length: 5045

Below is the updated 1-pager for the case.
The only significant change is the rewording of the paragraph on interface
stability levels, immediately before the listing of Interface, Description,
and Stability.

	April


Project/Component Working Name: 
	Amendments to Korn Shell 93 Integration

Name of Document Author/Supplier: 
	april.chin@sun.com, roland.mainz@nrubsig.org

Date of This Document:
	1/17/07

Project Summary

This case is an amendment to the Korn Shell 93 Integration case,
PSARC/2006/550, specifying the following additional interfaces:
1) a ksh93 built-in getconf command and
2) AT&T components for building message files for localization

Bug/RFE Number(s):

6505835 AST tools and library (libpp) required for creating l10n messages 
	for ksh93
    
Description

The AT&T built-in version of the getconf
utility in ksh93 contains extensions not present 
in the Solaris getconf utility, which are required to
run the AT&T ksh93 tests; these tests are critical to 
the verification of ksh93 builds.  The getconf built-in
allows users to write ksh93 scripts which are portable
across different systems and which can take advantage
of AT&T extensions to ksh93 [1,2].

Like other built-in commands named in PSARC/2006/550, the getconf 
built-in in ksh93 will be bound to the /bin pathname.  The built-in 
getconf in ksh93 will only be invoked if called with no pathname prefix,
and if a /bin/getconf or /usr/bin/getconf executable is 
found first on the user's path.  

The stability of the getconf built-in command-line interface and 
the system variables documented in getconf(1) is Committed; 
its pathname binding to /bin is Volatile.
The getconf built-in supports additional system variables not available for 
/usr/bin/getconf; these variables are Project Private, and include
names prefixed with "AST" and "_AST".

All options and system variables supported by /usr/bin/getconf produce 
identical output values using the ksh93 built-in getconf.
Additions to the ksh93 test suite and to /usr/bin/getconf testing
will ensure that ksh93 built-in getconf continues to provide functionality 
compatible with /usr/bin/getconf.


The second portion of this case specifies the addition of
AT&T message-building components--a library, ksh93 scripts,
and a set of binaries--required for the ksh93 project 
to build its message files for localization.

The message-building tools and proposed AT&T library, libpp, 
have a strong dependency on libast, one of the new AT&T 
libraries specified in PSARC/2006/550.  Therefore 
these components should be kept in sync with libast on Solaris.
	
These components will initially be used only by the
Korn Shell 93 Integration Project (PSARC/2006/550).
The proposed location of the tools in /usr/ast/bin
is consistent with the location used within AT&T. 

If the interface stability level of the shared libraries 
listed in PSARC/2006/550--libshell, libast, libdll, and libcmd--
is promoted above the current stability level of the /usr/ast/bin
utilities listed below, the stability level of the latter should 
be promoted to at least the same level as the libraries, to 
allow consumers of the former to build the appropriate message files.  


Interface		Description				Stability
---------		-----------				---------
/usr/lib/libpp.so.1	AT&T ANSI C preprocessor library	Project Private
/usr/ast/bin		directory for AT&T commands		Volatile
/usr/ast/bin/msgadmin	ksh93 script for message catalog 	Volatile
			file administration
/usr/ast/bin/msgcc	ksh93 script for generating message 	Volatile
			catalog files

			binaries used by msgcc and msgadmin 
			for message formatting, converting:
/usr/ast/bin/msgcpp						Volatile
/usr/ast/bin/msgcvt						Volatile
/usr/ast/bin/msggen						Volatile
/usr/ast/bin/msgget						Volatile

A new package for AST (Advanced Software Technology) developer tools, 
SUNWastdev, will be created, which includes all of the above message-building 
components. These tools have a dependency on ksh93 and its libraries, as
listed in PSARC/2006/550, and shall not be integrated before 
the Korn Shell 93 Integration project.

Dynamic library dependencies of msgcpp, msgcvt, msggen, and msgget:

        libpp.so.1 =>    /usr/lib/libpp.so.1
        libast.so.1 =>   /usr/lib/libast.so.1
        libm.so.2 =>     /lib/libm.so.2
        libc.so.1 =>     /usr/lib/libc.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libmd.so.1 =>    /usr/lib/libmd.so.1
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        /platform/SUNW,Sun-Fire-V890/lib/libc_psr.so.1
        /platform/SUNW,Sun-Fire-V890/lib/libmd_psr.so.1


References:

[1] getconf background from Glenn Fowler of AT&T
http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-November/00
1863.html
[2] more getconf background from Glenn Fowler
http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-November/00
1864.html


From carlsonj@phorcys.east.sun.com Wed Jan 17 16:58:43 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0I0wg3n029218
	for ; Wed, 17 Jan 2007 16:58:43 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0I0wcHw011261
	for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 18 Jan 2007 00:58:42 GMT
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 <0JC100B0JHDSWY00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com
 (ORCPT psarc-ext@sun.com); Wed, 17 Jan 2007 16:58:40 -0800 (PST)
Received: from phorcys.east.sun.com ([129.148.174.143])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC100C3FHDRJB70@nwk-avmta-1.sfbay.Sun.COM> for
 psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed,
 17 Jan 2007 16:58:40 -0800 (PST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0I0wc44005592; Wed,
 17 Jan 2007 19:58:38 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0I0wcmg005589; Wed,
 17 Jan 2007 19:58:38 -0500 (EST)
Date: Wed, 17 Jan 2007 19:58:37 -0500
From: James Carlson 
Subject: Re: 2007/035 ksh93 Amendments: updated 1-pager
In-reply-to: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
To: April Chin 
Cc: psarc-ext@sun.com, roland.mainz@nrubsig.org
Message-id: <17838.50749.663413.467414@gargle.gargle.HOWL>
MIME-version: 1.0
X-Mailer: VM 7.01 under Emacs 21.3.1
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
Status: RO
Content-Length: 556

April Chin writes:
> Below is the updated 1-pager for the case.
> The only significant change is the rewording of the paragraph on interface
> stability levels, immediately before the listing of Interface, Description,
> and Stability.

Given the new specification, this fast-track request was approved
during today's ARC business.

-- 
James Carlson, Solaris Networking              
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From jek3@sun.com Wed Jan 17 18:21:32 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0I2LUSV001195
	for ; Wed, 17 Jan 2007 18:21:31 -0800 (PST)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0I2LDYN021947;
	Thu, 18 Jan 2007 10:21:24 +0800 (SGT)
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 <0JC100109L7MGR00@nwk-avmta-2.sfbay.sun.com>; Wed,
 17 Jan 2007 18:21:22 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.106.31])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC100B94L7MA6C0@nwk-avmta-2.sfbay.sun.com>; Wed,
 17 Jan 2007 18:21:22 -0800 (PST)
Received: from [129.150.12.40]
 (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40])	by jurassic.eng.sun.com
 (8.13.8+Sun/8.13.8) with ESMTP id l0I2LHen923488; Wed,
 17 Jan 2007 18:21:17 -0800 (PST)
Date: Wed, 17 Jan 2007 16:19:47 -1000
From: Joseph Kowalski 
Subject: Re: 2007/035 ksh93 Amendments: updated 1-pager
In-reply-to: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
To: April Chin 
Cc: psarc-ext@sun.com, james.d.carlson@sun.com, april.chin@sun.com,
        roland.mainz@nrubsig.org
Message-id: <45AED943.3050704@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 589

April Chin wrote:
> Below is the updated 1-pager for the case.
> The only significant change is the rewording of the paragraph on interface
> stability levels, immediately before the listing of Interface, Description,
> and Stability.
>   
Since we've been discussing it, a statement as to which meta-cluster 
this package
is to be included in should be part of the spec.  Roland, myself and I 
think you (April)
believe it should be SUNWdev while Jim (and perhaps others) have a 
different view.

Anyway, we should have a stake in the sand here, so we know what were 
approving.

- jek3


From carlsonj@phorcys.east.sun.com Thu Jan 18 05:12:39 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0IDCcPK011615
	for ; Thu, 18 Jan 2007 05:12:39 -0800 (PST)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0IDCXOM012297;
	Thu, 18 Jan 2007 13:12:36 GMT
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 <0JC20010JFCXGY00@nwk-avmta-2.sfbay.sun.com>; Thu,
 18 Jan 2007 05:12:33 -0800 (PST)
Received: from phorcys.east.sun.com ([129.148.174.143])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC2004LLFCWNIE0@nwk-avmta-2.sfbay.sun.com>; Thu,
 18 Jan 2007 05:12:32 -0800 (PST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0IDCVVn008834; Thu,
 18 Jan 2007 08:12:31 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id l0IDCU5C008831; Thu,
 18 Jan 2007 08:12:30 -0500 (EST)
Date: Thu, 18 Jan 2007 08:12:30 -0500
From: James Carlson 
Subject: Re: 2007/035 ksh93 Amendments: updated 1-pager
In-reply-to: <45AED943.3050704@sun.com>
To: Joseph Kowalski 
Cc: April Chin , psarc-ext@sun.com, april.chin@sun.com,
        roland.mainz@nrubsig.org
Message-id: <17839.29246.871228.377068@gargle.gargle.HOWL>
MIME-version: 1.0
X-Mailer: VM 7.01 under Emacs 21.3.1
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
 <45AED943.3050704@sun.com>
Status: RO
Content-Length: 1381

Joseph Kowalski writes:
> April Chin wrote:
> > Below is the updated 1-pager for the case.
> > The only significant change is the rewording of the paragraph on interface
> > stability levels, immediately before the listing of Interface, Description,
> > and Stability.
> >   
> Since we've been discussing it, a statement as to which meta-cluster 
> this package
> is to be included in should be part of the spec.  Roland, myself and I 
> think you (April)
> believe it should be SUNWdev

Is that SUNWCprog?  We're talking about metaclusters and not packages.

> while Jim (and perhaps others) have a 
> different view.
> 
> Anyway, we should have a stake in the sand here, so we know what were 
> approving.

Except for the definitions of metaclusters, I don't know of much
precedent in ARC review of individual packaging choices.  I'm not
saying it's the wrong thing to do, it's just new by me.  It feels like
approving a particular release vehicle content.

I'm more than willing to leave the metacluster assignments (if any)
out of the case, and work with the team (and the gate staff) offline
to make sure the right thing happens.

Is that acceptable?

-- 
James Carlson, Solaris Networking              
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From jek3@sun.com Thu Jan 18 12:02:08 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0IK279Y024266
	for ; Thu, 18 Jan 2007 12:02:08 -0800 (PST)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0IK1wcZ011358;
	Thu, 18 Jan 2007 20:02:03 GMT
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 <0JC200607YBDVO00@nwk-avmta-2.sfbay.sun.com>; Thu,
 18 Jan 2007 12:02:01 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.56.36])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JC200JOJYBCKVE0@nwk-avmta-2.sfbay.sun.com>; Thu,
 18 Jan 2007 12:02:01 -0800 (PST)
Received: from [129.150.12.40]
 (vpn-129-150-12-40.SFBay.Sun.COM [129.150.12.40])	by jurassic.eng.sun.com
 (8.13.8+Sun/8.13.8) with ESMTP id l0IK1ufC375599; Thu,
 18 Jan 2007 12:01:56 -0800 (PST)
Date: Thu, 18 Jan 2007 10:00:26 -1000
From: Joseph Kowalski 
Subject: Re: 2007/035 ksh93 Amendments: updated 1-pager
In-reply-to: <17839.29246.871228.377068@gargle.gargle.HOWL>
To: James Carlson 
Cc: April Chin , psarc-ext@sun.com, april.chin@sun.com,
        roland.mainz@nrubsig.org
Message-id: <45AFD1DA.4030800@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
 <45AED943.3050704@sun.com> <17839.29246.871228.377068@gargle.gargle.HOWL>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1542

James Carlson wrote:
> Joseph Kowalski writes:
>   
>> April Chin wrote:
>>     
>>> Below is the updated 1-pager for the case.
>>> The only significant change is the rewording of the paragraph on interface
>>> stability levels, immediately before the listing of Interface, Description,
>>> and Stability.
>>>   
>>>       
>> Since we've been discussing it, a statement as to which meta-cluster 
>> this package
>> is to be included in should be part of the spec.  Roland, myself and I 
>> think you (April)
>> believe it should be SUNWdev
>>     
>
> Is that SUNWCprog?  We're talking about metaclusters and not packages.
>   
Yea.
>   
>> while Jim (and perhaps others) have a 
>> different view.
>>
>> Anyway, we should have a stake in the sand here, so we know what were 
>> approving.
>>     
>
> Except for the definitions of metaclusters, I don't know of much
> precedent in ARC review of individual packaging choices.  I'm not
> saying it's the wrong thing to do, it's just new by me.  It feels like
> approving a particular release vehicle content.
>
> I'm more than willing to leave the metacluster assignments (if any)
> out of the case, and work with the team (and the gate staff) offline
> to make sure the right thing happens.
>
> Is that acceptable?
>   
Its not only acceptable, but its what we usually do.  I just thought it 
might be good
to include it, because we had discussed it.   However, omitting it saves 
us the task
of closing on the discussion on an already closed and approved case.  
I'm all for
that!

- jek3


From roland.mainz@nrubsig.org Thu Jan 18 15:51:18 2007
Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0INpHm9029469
	for ; Thu, 18 Jan 2007 15:51:17 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0INp3aJ028136;
	Fri, 19 Jan 2007 07:51:10 +0800 (SGT)
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 <0JC3004018X7FZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 18 Jan 2007 15:51:07 -0800 (PST)
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 <0JC300CIN8X61V50@nwk-avmta-1.sfbay.Sun.COM>; Thu,
 18 Jan 2007 15:51:06 -0800 (PST)
Received: from relay3.sun.com (relay3.sun.com [150.143.103.54] (may be forged))
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0INXp5e008838; Thu,
 18 Jan 2007 16:51:06 -0700 (MST)
Received: from mms0bes.sun.com ([150.143.104.214] [150.143.104.214])
 by relay3.sun.com with ESMTP; Thu, 18 Jan 2007 23:50:43 +0000 (Z)
Received: from relay2.sun.com (relay2.sun.com [150.143.103.24])
 by mms0bes.sun.com with ESMTP; Thu, 18 Jan 2007 23:50:43 +0000 (Z)
Received: from mail-in-02.arcor-online.net ([151.189.21.42] [151.189.21.42])
 by relay2.sun.com with ESMTP; Thu, 18 Jan 2007 23:50:43 +0000 (Z)
Received: from mail-in-01-z2.arcor-online.net
 (mail-in-01-z2.arcor-online.net [151.189.8.13])	by mail-in-02.arcor-online.net
 (Postfix) with ESMTP id E0FD92D7D01; Fri, 19 Jan 2007 00:50:41 +0100 (CET)
Received: from mail-in-04.arcor-online.net
 (mail-in-04.arcor-online.net [151.189.21.44])
	by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id D418CCDECF; Fri,
 19 Jan 2007 00:50:41 +0100 (CET)
Received: from jupiterb48.nrubsig.org
 (dslb-084-059-019-041.pools.arcor-ip.net [84.59.19.41])
	by mail-in-04.arcor-online.net (Postfix) with ESMTP id 4264D1C71C1; Fri,
 19 Jan 2007 00:50:41 +0100 (CET)
Received: from nrubsig.org (localhost [127.0.0.1])	by jupiterb48.nrubsig.org
 (8.13.8+Sun/8.13.8) with ESMTP id l0INocHe002134; Fri,
 19 Jan 2007 00:50:38 +0100 (CET)
Date: Fri, 19 Jan 2007 00:50:38 +0100
From: Roland Mainz 
Subject: Re: 2007/035 ksh93 Amendments: updated 1-pager
Sender: gisburn@jupiterb48.nrubsig.org
To: James Carlson ,
        ksh93-integration-discuss 
Cc: Joseph Kowalski , April Chin ,
        psarc-ext@sun.com, april.chin@sun.com
Message-id: <45B007CE.F3F3E127@nrubsig.org>
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-PMX-Version: 5.2.0.264296
References: <200701180046.l0I0keJ5902722@jurassic.eng.sun.com>
 <45AED943.3050704@sun.com> <17839.29246.871228.377068@gargle.gargle.HOWL>
Status: RO
Content-Length: 935

James Carlson wrote:
> Joseph Kowalski writes:
> > April Chin wrote:
[snip]
> I'm more than willing to leave the metacluster assignments (if any)
> out of the case, and work with the team (and the gate staff) offline
> to make sure the right thing happens.
> 
> Is that acceptable?

Yes...
... note that the resulting scripts+binaries are quite small, e.g. IMO
it won't harm to include them in the developers cluster.
If there is still no consens about the cluster then I'd suggest to let
gatekeepers do the decision... they're likely the first victims if we
implement it somehow the "wrong" way (worst case result may be something
like
http://mail.opensolaris.org/pipermail/onnv-notify/2006-December/006508.html
and I'd like to avoid such a thing).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

From April.Chin@sun.com Fri Mar 30 16:42:53 2007
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2UNgpD3023377
	for ; Fri, 30 Mar 2007 16:42:53 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2UIt2CW004467;
	Fri, 30 Mar 2007 19:55:06 +0100 (BST)
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 <0JFQ00501CJTJU00@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 30 Mar 2007 11:55:05 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JFQ00AH9CJTKKB0@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 30 Mar 2007 11:55:05 -0700 (PDT)
Received: from aragon (aragon.SFBay.Sun.COM [129.146.226.123])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0)
 with SMTP id l2UIt44g284726; Fri, 30 Mar 2007 11:55:04 -0700 (PDT)
Date: Fri, 30 Mar 2007 11:51:24 -0700 (PDT)
From: April Chin 
Subject: 2007/035 ksh93 Amendments
To: psarc-ext@sun.com
Cc: roland.mainz@nrubsig.org, April.Chin@sun.com, james.d.carlson@sun.com
Reply-to: April Chin 
Message-id: <200703301855.l2UIt44g284726@jurassic-x4600.sfbay.sun.com>
MIME-version: 1.0
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_31 SunOS 5.11 sun4u sparc
Content-type: TEXT/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-MD5: +67nmhZpX+3R4X4Dy5qaDw==
X-PMX-Version: 5.2.0.264296
Status: RO
Content-Length: 321

This is a small update to
PSARC 2007/035 ksh93 Amendments

The project team has decided that one of the deliverables from
the original case, /usr/ast/bin/msgadmin, is not usable and is not
required by this project.  It will not be included for 
this project but may be included for a subsequent project.

Thanks,
	April