From alanc@sac.sfbay.sun.com Fri Jul 24 15:48:51 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6OMmoC1014598 for ; Fri, 24 Jul 2009 15:48:51 -0700 (PDT) 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 n6OMmhpA027326; Sat, 25 Jul 2009 06:48:49 +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 <0KNB00L0561BAU00@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Jul 2009 15:48:47 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00BQN61B5C60@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Jul 2009 15:48:47 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6OMmlnD015138; Fri, 24 Jul 2009 15:48:47 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6OMmkRw014593; Fri, 24 Jul 2009 15:48:46 -0700 (PDT) Received: (from alanc@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n6OMmkhp014589; Fri, 24 Jul 2009 15:48:46 -0700 (PDT) Date: Fri, 24 Jul 2009 15:48:46 -0700 (PDT) From: Alan Coopersmith Subject: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: PSARC-ext@sun.com Cc: busybox-dev@opensolaris.org, ksh93-integration-discuss@opensolaris.org Message-id: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5749 I'm sponsoring this fast-track request on behalf of the ksh93-integration and busybox projects. The timeout is set for Friday, July 31, 2009. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: AST versions of fold, mktemp, pathchk, & tty 1.2. Name of Document Author/Supplier: Author: Roland Mainz 1.3 Date of This Document: 24 July, 2009 4. Technical Description The release binding is the same as with the previous ksh93 project: a patch/micro release of Solaris delivering through OS/Net 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, PSARC/2006/587, PSARC/2007/035, PSARC/2008/094, PSARC/2008/344, PSARC/2009/063 and PSARC/2009/248) and depends on PSARC/2009/248, specifying the following additional interfaces: 1) An enhanced version of the "fold" utility and an identical ksh93 built-in command 2) An enhanced version of the "mktemp" utility and an identical ksh93 built-in command 3) An enhanced version of the "pathchk" utility and an identical ksh93 built-in command 4) An enhanced version of the "tty" utility and an identical ksh93 built-in command Bug/RFE Number(s): 6863449 RFE: Update /usr/bin/fold to AT&T AST "fold" 6861633 RFE: Update /usr/bin/mktemp to AT&T AST "mktemp" 6863450 RFE: Update /usr/bin/pathchk to AT&T AST "pathchk" 6861634 RFE: Update /usr/bin/tty to AT&T AST "tty" Interface Stability Description --------- --------- ----------- /usr/bin/fold Committed fold command /usr/bin/mktemp Committed mktemp command /usr/bin/tty Committed tty command /usr/bin/pathchk Committed pathchk command ##### Introduction: This case proposes to deliver the following features as a set of independent putbacks as they become available. Each feature is self contained and independent of the others, so out of order and partial putbacks at this granularity should have no adverse impact on the functionality and behavior of the system as a whole. #### Part 1: Enhancement of /usr/bin/fold The first part of this project specifies an enhancement to /usr/bin/fold based on the AT&T AST "fold" command. The AT&T AST version of the "fold" utility provides support for the following additional options found commonly in other implementations such as GNU and BSD: -- snip -- --bytes (same as existing "-b" option) -c, --continue=text -d, --delimiter=delim --spaces (same as existing "-s" option) --width=width (same as existing "-w"/"-" option) --man, --html, --nroff, --help, --version -- snip -- The stability of the "/usr/bin/fold" command and built-in command-line interface (including the new options) and system variables documented in fold(1) and specified by IEEE Std 1003.1-2008 is "Committed". For further information/specifications see the materials/-folder. #### Part 2: Enhancement of /usr/bin/mktemp The second part of this project specifies an enhancement to /usr/bin/mktemp based on the AT&T AST "mktemp" command. The AT&T AST version of the "mktemp" utility provides support for the following additional options found commonly in other implementations such as GNU and BSD: -- snip -- --directory (same as existing "-d") -m, --mode --default (same as existing "-p") --quiet (same as existing "-q") --tmp, --temporary-directory (same as existing "-t") --unsafe, --dry-run (same as existing "-u") --man, --html, --nroff, --help, --version -- snip -- The stability of the "/usr/bin/mktemp" command and built-in command-line interface (including the new options) and system variables documented in mktemp(1) is "Committed". For further information/specifications see the materials/-folder. #### Part 3: Enhancement of /usr/bin/pathchk The third part of this project specifies an enhancement to /usr/bin/pathchk based on the AT&T AST "pathchk" command. The AT&T AST version of the "pathchk" utility provides support for the following additional options found commonly in other implementations such as GNU and BSD: -- snip -- --portability (same as existing "-p" option) -P --man, --html, --nroff, --help, --version -- snip -- The stability of the "/usr/bin/pathchk" command and built-in command-line interface (including the new options) and system variables documented in pathchk(1) and specified by IEEE Std 1003.1-2008 is "Committed". For further information/specifications see the materials/-folder. #### Part 4: Enhancement of /usr/bin/tty The 4th part of this project specifies an enhancement to /usr/bin/tty based on the AT&T AST "tty" command. The AT&T AST version of the "tty" utility provides support for the following additional options found commonly in other implementations such as GNU and BSD: -- snip -- --line-number (same as existing option "-l") --silent|quiet (same as existing "-s") --man, --html, --nroff, --help, --version -- snip -- The stability of the "/usr/bin/tty" command and built-in command-line interface (including the new options) and system variables documented in tty(1) and specified by IEEE Std 1003.1-2008 is "Committed". For further information/specifications see the materials/-folder. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Fri Jul 24 16:14:16 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6ONEF6F011737 for ; Fri, 24 Jul 2009 16:14:15 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6ONEDQc016053 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 00:14:14 +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 <0KNB0080577QY700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:14:14 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00FYK77PS740@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:14:13 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6ONEDqK022328 for ; Fri, 24 Jul 2009 16:14:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNB00E006VV5500@fe-sfbay-10.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:14:13 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNB006TI77M9FC0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:14:11 -0700 (PDT) Date: Fri, 24 Jul 2009 16:14:10 -0700 From: "Garrett D'Amore" Subject: Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: PSARC-ext@sun.com, busybox-dev@opensolaris.org, ksh93-integration-discuss@opensolaris.org Message-id: <4A6A4042.8000700@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7700 My main concern here is the integration of manual page functionality into the commands themselves. I see both benefits and costs. The benefit is that the documentation is more likely to match the actual command. But part of the cost is a much higher cost to perform localization for these, and (depending on implementation) a potentially larger minimum size of the binaries. (I'm assuming for the moment that the documentation is stored in the binary, and the command is doing more than just executing some pipeline to access the manual content from /usr/share/man or whatever.) Personally, I think --man, --html and --nroff and such is a dangerous precedent to set. I'd rather not have them, and instead rely on the "man" command to provide this functionality. (Also with --html and --nroff an --man, how is the content stored -- does the command do format conversions on demand?... It seems like this functionality also might add to the total code size, although I guess this functionality is already stored in the AST libraries. Hopefully this is *not* storing 3 separate copies of the documentation in the binaries, at least! Also, I'd like the case submitter to provide some justification for these changes? Are there functional changes that will help with familiarity? (I'm assuming most people use GNU utilities on foreign operating systems, and not ksh93 versions.) Does this have any impact on the size of the objects on disk, the performance of the utilities, or the number of closed source bits we use to make up ON? Any of those would help provide justification for these changes. - Garrett Alan Coopersmith wrote: > I'm sponsoring this fast-track request on behalf of the > ksh93-integration and busybox projects. The timeout is > set for Friday, July 31, 2009. > > -Alan Coopersmith- alan.coopersmith@sun.com > Sun Microsystems, Inc. - X Window System Engineering > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > AST versions of fold, mktemp, pathchk, & tty > 1.2. Name of Document Author/Supplier: > Author: Roland Mainz > 1.3 Date of This Document: > 24 July, 2009 > 4. Technical Description > > The release binding is the same as with the previous ksh93 project: a > patch/micro release of Solaris delivering through OS/Net > 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, PSARC/2006/587, PSARC/2007/035, PSARC/2008/094, > PSARC/2008/344, PSARC/2009/063 and PSARC/2009/248) and depends on > PSARC/2009/248, specifying the following additional interfaces: > > 1) An enhanced version of the "fold" utility and an identical ksh93 > built-in command > 2) An enhanced version of the "mktemp" utility and an identical ksh93 > built-in command > 3) An enhanced version of the "pathchk" utility and an identical ksh93 > built-in command > 4) An enhanced version of the "tty" utility and an identical ksh93 > built-in command > > Bug/RFE Number(s): > > 6863449 RFE: Update /usr/bin/fold to AT&T AST "fold" > 6861633 RFE: Update /usr/bin/mktemp to AT&T AST "mktemp" > 6863450 RFE: Update /usr/bin/pathchk to AT&T AST "pathchk" > 6861634 RFE: Update /usr/bin/tty to AT&T AST "tty" > > > > Interface Stability Description > --------- --------- ----------- > /usr/bin/fold Committed fold command > /usr/bin/mktemp Committed mktemp command > /usr/bin/tty Committed tty command > /usr/bin/pathchk Committed pathchk command > > > > > ##### Introduction: > This case proposes to deliver the following features as a set of > independent putbacks as they become available. Each feature is > self contained and independent of the others, so out of order > and partial putbacks at this granularity should have no adverse > impact on the functionality and behavior of the system as a whole. > > > > #### Part 1: Enhancement of /usr/bin/fold > The first part of this project specifies an enhancement to > /usr/bin/fold based on the AT&T AST "fold" command. > The AT&T AST version of the "fold" utility provides support for the > following additional options found commonly in other > implementations such as GNU and BSD: > -- snip -- > --bytes (same as existing "-b" option) > -c, --continue=text > -d, --delimiter=delim > --spaces (same as existing "-s" option) > --width=width (same as existing "-w"/"-" option) > --man, --html, --nroff, --help, --version > -- snip -- > The stability of the "/usr/bin/fold" command and built-in > command-line interface (including the new options) and system > variables documented in fold(1) and specified by IEEE > Std 1003.1-2008 is "Committed". > For further information/specifications see the materials/-folder. > > > #### Part 2: Enhancement of /usr/bin/mktemp > The second part of this project specifies an enhancement to > /usr/bin/mktemp based on the AT&T AST "mktemp" command. > The AT&T AST version of the "mktemp" utility provides support for the > following additional options found commonly in other > implementations such as GNU and BSD: > -- snip -- > --directory (same as existing "-d") > -m, --mode > --default (same as existing "-p") > --quiet (same as existing "-q") > --tmp, --temporary-directory (same as existing "-t") > --unsafe, --dry-run (same as existing "-u") > --man, --html, --nroff, --help, --version > -- snip -- > The stability of the "/usr/bin/mktemp" command and built-in > command-line interface (including the new options) and system > variables documented in mktemp(1) is "Committed". > For further information/specifications see the materials/-folder. > > > #### Part 3: Enhancement of /usr/bin/pathchk > The third part of this project specifies an enhancement to > /usr/bin/pathchk based on the AT&T AST "pathchk" command. > The AT&T AST version of the "pathchk" utility provides support for the > following additional options found commonly in other > implementations such as GNU and BSD: > -- snip -- > --portability (same as existing "-p" option) > -P > --man, --html, --nroff, --help, --version > -- snip -- > The stability of the "/usr/bin/pathchk" command and built-in > command-line interface (including the new options) and system > variables documented in pathchk(1) and specified by IEEE > Std 1003.1-2008 is "Committed". > For further information/specifications see the materials/-folder. > > > #### Part 4: Enhancement of /usr/bin/tty > The 4th part of this project specifies an enhancement to > /usr/bin/tty based on the AT&T AST "tty" command. > The AT&T AST version of the "tty" utility provides support for the > following additional options found commonly in other > implementations such as GNU and BSD: > -- snip -- > --line-number (same as existing option "-l") > --silent|quiet (same as existing "-s") > --man, --html, --nroff, --help, --version > -- snip -- > The stability of the "/usr/bin/tty" command and built-in > command-line interface (including the new options) and system > variables documented in tty(1) and specified by IEEE > Std 1003.1-2008 is "Committed". > For further information/specifications see the materials/-folder. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Alan.Coopersmith@sun.com Fri Jul 24 16:20:13 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6ONKCYq018640 for ; Fri, 24 Jul 2009 16:20:12 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6ONJu7B019032 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 00:20:11 +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 <0KNB00A0F7HN9600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:20:11 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00F5I7HNS450@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:20:11 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6ONKAKe022701 for ; Fri, 24 Jul 2009 16:20:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNB003007D8SS00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:20:10 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNB0047M7HEOF00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:20:02 -0700 (PDT) Date: Fri, 24 Jul 2009 16:20:02 -0700 From: Alan Coopersmith Subject: Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6A4042.8000700@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, busybox-dev@opensolaris.org, ksh93-integration-discuss@opensolaris.org Message-id: <4A6A41A2.3090208@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 753 Garrett D'Amore wrote: > Personally, I think --man, --html and --nroff and such is a dangerous > precedent to set. I'd rather not have them, and instead rely on the > "man" command to provide this functionality. Isn't it a bit late to raise such a concern, since the precedent was set in the long list of previous cases that used AST/ksh93 implementations? > But part of the cost is a much higher cost to perform localization for these No matter what you multiply $0 by, it's still $0. (We don't localize man pages in Solaris. A subset of man pages used to be translated to Japanese, but I believe even that is no longer done.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Fri Jul 24 16:42:57 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6ONgv0b018953 for ; Fri, 24 Jul 2009 16:42:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6ONgv7Z029925 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Jul 2009 16:42:57 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNB00N0L8JK2100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 17:42:56 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00JK48JI9XC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 17:42:54 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6ONgsYA021806 for ; Fri, 24 Jul 2009 16:42:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNB00H008DK7C00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:42:54 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNB004LD8JHOF50@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 24 Jul 2009 16:42:54 -0700 (PDT) Date: Fri, 24 Jul 2009 16:42:52 -0700 From: "Garrett D'Amore" Subject: Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6A41A2.3090208@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: PSARC-ext@sun.com, busybox-dev@opensolaris.org, ksh93-integration-discuss@opensolaris.org Message-id: <4A6A46FC.4040008@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1527 Alan Coopersmith wrote: > Garrett D'Amore wrote: > >> Personally, I think --man, --html and --nroff and such is a dangerous >> precedent to set. I'd rather not have them, and instead rely on the >> "man" command to provide this functionality. >> > > Isn't it a bit late to raise such a concern, since the precedent was set > in the long list of previous cases that used AST/ksh93 implementations? > It might be. I certainly should have raised the issue back then. I'm still not happy about this. There's yet another concern, which is that I've found that man and command --man do not generate the same document. So we know introduce a problem were documentation delivered on the system can be inconsistent. I feel really strongly that this was a bad idea. Strongly enough that I'm contemplating derailing the case. I need to first go back and see if this particular issue was already addressed in the previous ARC history before I do so. > >> But part of the cost is a much higher cost to perform localization for these >> > > No matter what you multiply $0 by, it's still $0. (We don't localize man > pages in Solaris. A subset of man pages used to be translated to Japanese, > but I believe even that is no longer done.) > Really? That comes as a surprise. But we *do* localize commands. So does putting --man content in the command suddenly mean that in order to be I18N compliant they have to be localized? That would certainly add to the cost. - Garrett From roland.mainz@nrubsig.org Fri Jul 24 17:44:43 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6P0igew020466 for ; Fri, 24 Jul 2009 17:44:43 -0700 (PDT) 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 n6P0ibbQ023567; Sat, 25 Jul 2009 08:44:40 +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 <0KNB00603BEFQL00@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Jul 2009 17:44:39 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00BWFBEE5PC0@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Jul 2009 17:44:38 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6P0ibrl014307; Sat, 25 Jul 2009 00:44:38 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-132299; Sat, 25 Jul 2009 00:44:37 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-3618533; Sat, 25 Jul 2009 00:44:36 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-521653; Sat, 25 Jul 2009 00:42:25 +0000 (Z) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id C306C1AF2FD; Sat, 25 Jul 2009 02:42:06 +0200 (CEST) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id B57742D3782; Sat, 25 Jul 2009 02:42:06 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-068-013.pools.arcor-ip.net [84.59.68.13]) by mail-in-17.arcor-online.net (Postfix) with ESMTPS id ABA293B2613; Sat, 25 Jul 2009 02:42:01 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6P0fwhT000838; Sat, 25 Jul 2009 02:41:58 +0200 (CEST) Date: Sat, 25 Jul 2009 02:41:58 +0200 From: Roland Mainz Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: Busybox development Cc: Alan Coopersmith , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6A54D6.95E62CA1@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-17.arcor-online.net ABA293B2613 X-Antispam: No, score=-1.1/5.0, scanned in 0.184sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> Status: RO Content-Length: 8773 Garrett D'Amore wrote: > Alan Coopersmith wrote: > > I'm sponsoring this fast-track request on behalf of the > > ksh93-integration and busybox projects. The timeout is > > set for Friday, July 31, 2009. > > > > -Alan Coopersmith- alan.coopersmith@sun.com > > Sun Microsystems, Inc. - X Window System Engineering > > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > > This information is Copyright 2009 Sun Microsystems > > 1. Introduction > > 1.1. Project/Component Working Name: > > AST versions of fold, mktemp, pathchk, & tty > > 1.2. Name of Document Author/Supplier: > > Author: Roland Mainz > > 1.3 Date of This Document: > > 24 July, 2009 > > 4. Technical Description [snip] > My main concern here is the integration of manual page functionality > into the commands themselves. I see both benefits and costs. The > benefit is that the documentation is more likely to match the actual > command. But part of the cost is a much higher cost to perform > localization for these, Erm... see below... normal manpages won't be discontinued - see below... ... and there is (in theory) no restriction to localise builtin manpages - the matching string would simply appear in the l10n catalog file for libcmd (this is however not planned (yet)). > and (depending on implementation) a potentially > larger minimum size of the binaries. (I'm assuming for the moment that > the documentation is stored in the binary, and the command is doing more > than just executing some pipeline to access the manual content from > /usr/share/man or whatever.) > > Personally, I think --man, --html and --nroff and such is a dangerous > precedent to set. ... which already exists since the ksh93-integration project was started... > I'd rather not have them, and instead rely on the > "man" command to provide this functionality. Erm... we never proposed to discontinue to use manpages. The builtin support for "--man"&co. is actually only a nice side-effect of the AST getopts function - see below... > (Also with --html and > --nroff an --man, how is the content stored -- does the command do > format conversions on demand?... It seems like this functionality also > might add to the total code size, although I guess this functionality is > already stored in the AST libraries. Hopefully this is *not* storing 3 > separate copies of the documentation in the binaries, at least! Erm... some clarifications: 1. Support for "--man"/"-nroff"/"--html" is only a side-effect of the extensions of the |libast::getopts()| function. This extension (available via the ksh93 "getopts" interface for scripts and |libast::getopts()| for binaries) is used to describe the short&&long command/utilty options and allows to tag them with some messages, too. The libast code then converts this into a mannual page on demand. 2. Please don't worry... we don're store 666 copies of the manual page somewhere in the code - instead the _compact_ getopts string is dynamically converted at runtime to the requested output format. 3. The actual "extra" space being used is _tiny_ - just looking at the (completely different) implementations of /usr/bin/fold vs. the "fold.o" object from one of my development trees: -- snip -- $ ls -l ./build_sparc_64bit/arch/sol11.sun4/src/lib/libcmd/fold.o /usr/bin/fold -rw-r--r-- 1 gisburn gisburn 14136 Jun 28 04:27 ./build_sparc_64bit/src/lib/libcmd/fold.o -r-xr-xr-x 1 root bin 12752 Sep 13 2006 /usr/bin/fold -- snip -- This is on SPARC ("fold.o" is SPARCv9, "/usr/bin/fold" is SPARCv8) ... and the size difference is AFAIK not a problem since UFS uses 8k pages and both binaries therefore fit happily in two 8k pages and on x86 both need three 4k pages. 4. The bulitin manpages are intentionally only a short/terse version of the normal manpages (for example $ ksh93 --man # only gives normal shell usage, not the full syntax of the ksh93 scripting language and all the details. It's intended as quick reference and not to replace the full manual page (for smaller projects like "bldenv" or "webrev" it can replace the full manual page but that's more the exception from the standard)). 5. For the long-term (not yet, not now, not this case (please)) it may be interesting to generate the builtin string for AST "getopts" and the normal manual pages from a DocBook/XML master file (with some XML ifdef/else/endif to cut-out the non-mandatory parts). That would unify both systems but requires that I'll finish the "shxml" work (e.g. xmlreader/xmlwriter support for the shell) or write a dedicated docbook2astgetopts.xsl XSLT stylesheet. 6. We're _not_ interested to create a precedent here, just deliver what upstream does in it's code. And we document the "--man" function in this ARC case as optional _usabilty_ enhancement. > Also, I'd like the case submitter to provide some justification for > these changes? Are there functional changes that will help with > familiarity? Yes, at least we cover the following goals: - Familarity: GNU+BSD command line options (which increases interoperabilty, not only across GNU but BSD and MacOSX, too) - Performance: 1. The AST implementions are usually a lot faster than the current commands (we seen with the replacements for /usr/bin/cut, /usr/bin/paste etc. which are sometimes eight, ten or twelve times faster (partially because the |libc::stdio| implementation is _extremely_ slow)) 2. Performance boost for OpenSolaris/Indiana since the tool is a builtin shell command for /usr/bin/sh, /sbin/sh, /usr/bin/ksh and /usr/bin/ksh93 - 64bit clean codebase: Right now OS/Net is _not_ being 64bit clean (the tools we are touching in ksh93-integration update2 and this case are in particular the worst offenders, followed by the CTF tools and some minor other areas). This situation causes serious problems (e.g. accounting for 1/5 of the engineering time required to port Solaris) for ports to other hardware - for example the Solaris/SyetemZ port was forced to implement a 32bit emulation layer (!!) on pure 64bit hardware because there was no other easy way to get Solaris ported (and IMO this situation _sucks_ (<-- sorry... but I really don't like it that the code was never cleaned-up)). - Long-term maintaince: Living and _cooperative_ upstream who helps with bugfixing - License: CDDL-compatible license (for example "GNU coreutils" are GPLv2 which prevents the tools from being embedded as shared library ([1]) in non-GPLv2 code [2]). [1]=Which would be hopeless anyway since the code would need to be re-written from scratch to make it re-entrant [2]=(erm... could we please not have a license flamewar ? I'm only reciting what the coreutils folks are claiming...) > (I'm assuming most people use GNU utilities on foreign > operating systems, and not ksh93 versions.) See above - as said the tools we upgraded to the AST versions until now have their options compatible to _both_ the GNU _and_ BSD versions (we didn't cover any commands yet where options in different OSes have a conflicting meaning... we'll save that pain for the future... ;-/ ). > Does this have any impact > on the size of the objects on disk, See above. The size of the compiled code is a bit different since this new code is a completely different implementation but the size differenc is usually within +30%-/30% (not caused by the builtin manpages). And AFAIK the extra size is compensated by the busybox-style implementation which gurantees that the active code is always shared. > the performance of the utilities, The new tools weren't tested for performance yet but for the code changed in ksh93-integration update2 we know that the AST versions are significantly faster (with the exception of "tail" and "tee" _maybe_ (but I don't have any results yet ("tail" no longer uses |mmap()| which may cause performace degration but this change eliminates SIGSEGV/SIGBUS when the file shrinks and "tee" has a bit higher startup time (but has superiour buffering)))), for example AST "paste" runs - depending on the locale - 8-12 times faster than the current version. > or > the number of closed source bits we use to make up ON? Not with this ARC case but the previous one killed-off the closed-source "tail" and one of the next will cover the "sed" and "tr" variations. We're intending to get rid of the closed-source _commands_+_utilities_ soon with backwards-compatible opensource versions (e.g. "sed" is more or less done except compatibilty testing). > Any of those > would help provide justification for these changes. See above... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz@nrubsig.org Fri Jul 24 18:29:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6P1T4o2022311 for ; Fri, 24 Jul 2009 18:29:04 -0700 (PDT) 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 n6P1SkJ7016756; Sat, 25 Jul 2009 09:29:01 +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 <0KNB00D05DGC6G00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Jul 2009 18:29:00 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00F8CDGCRZB0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Jul 2009 18:29:00 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6P1MWU1012318; Sat, 25 Jul 2009 01:28:59 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay43i.sun.com with ESMTP id BT-MMP-915097; Sat, 25 Jul 2009 01:28:52 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-16033916; Sat, 25 Jul 2009 01:28:52 +0000 (Z) Received: from mail-in-11.arcor-online.net ([151.189.21.51] [151.189.21.51]) by relay4i.sun.com with ESMTP id BT-MMP-903583; Sat, 25 Jul 2009 01:28:51 +0000 (Z) Received: from mail-in-11-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mx.arcor.de (Postfix) with ESMTP id 974A7E393D; Sat, 25 Jul 2009 03:28:50 +0200 (CEST) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mail-in-11-z2.arcor-online.net (Postfix) with ESMTP id 78D773470F8; Sat, 25 Jul 2009 03:28:50 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-068-013.pools.arcor-ip.net [84.59.68.13]) by mail-in-10.arcor-online.net (Postfix) with ESMTPS id 2664828ECF4; Sat, 25 Jul 2009 03:28:47 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6P1SjDA000892; Sat, 25 Jul 2009 03:28:45 +0200 (CEST) Date: Sat, 25 Jul 2009 03:28:44 +0200 From: Roland Mainz Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: Busybox development , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com, Alan Coopersmith Message-id: <4A6A5FCC.841D1D50@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-10.arcor-online.net 2664828ECF4 X-Antispam: No, score=0.0/5.0, scanned in 0.182sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A54D6.95E62CA1@nrubsig.org> Status: RO Content-Length: 2067 Roland Mainz wrote: > Garrett D'Amore wrote: > > Alan Coopersmith wrote: [snip] > Yes, at least we cover the following goals: > - Familarity: GNU+BSD command line options (which increases > interoperabilty, not only across GNU but BSD and MacOSX, too) > - Performance: > 1. The AST implementions are usually a lot faster than the current > commands (we seen with the replacements for /usr/bin/cut, /usr/bin/paste > etc. which are sometimes eight, ten or twelve times faster (partially > because the |libc::stdio| implementation is _extremely_ slow)) > 2. Performance boost for OpenSolaris/Indiana since the tool is a > builtin shell command for /usr/bin/sh, /sbin/sh, /usr/bin/ksh and > /usr/bin/ksh93 > - 64bit clean codebase: Right now OS/Net is _not_ being 64bit clean (the > tools we are touching in ksh93-integration update2 and this case are in > particular the worst offenders, followed by the CTF tools and some minor > other areas). This situation causes serious problems (e.g. accounting > for 1/5 of the engineering time required to port Solaris) for ports to > other hardware - for example the Solaris/SyetemZ port was forced to > implement a 32bit emulation layer (!!) on pure 64bit hardware because > there was no other easy way to get Solaris ported (and IMO this > situation _sucks_ (<-- sorry... but I really don't like it that the code > was never cleaned-up)). [snip] I forgot two items: - Make all tools 100% largefile-aware. Right now some tools are still not largefile-aware, related bugs include: 1. CR #4808051 ("pathchk of file larger than 2GB will fail") [1] 2. CR #5082249 ('*fold* is not large file aware "value too large for defined data type"') - Implement IEEE Std 1003.1-2008 features (e.g. pathchk's "-P" option) [1]=I'm wondering how Solaris 10 passed the Unix&co. certifications with this bug... grrr... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz@nrubsig.org Fri Jul 24 18:51:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6P1pcW9022618 for ; Fri, 24 Jul 2009 18:51:38 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6P1pZLH001909; Sat, 25 Jul 2009 02:51:36 +0100 (BST) 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 <0KNB00B03EHZQN00@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Jul 2009 18:51:35 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00BS4EHY5LE0@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Jul 2009 18:51:35 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6P1aKkX023416; Sat, 25 Jul 2009 01:51:34 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-134576; Sat, 25 Jul 2009 01:51:25 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-481330; Sat, 25 Jul 2009 01:51:24 +0000 (Z) Received: from mail-in-02.arcor-online.net ([151.189.21.42] [151.189.21.42]) by relay1i.sun.com with ESMTP id BT-MMP-641891; Sat, 25 Jul 2009 01:47:50 +0000 (Z) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mx.arcor.de (Postfix) with ESMTP id 285713FE0E6; Sat, 25 Jul 2009 03:47:19 +0200 (CEST) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id 091FB100E3; Sat, 25 Jul 2009 03:47:19 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-068-013.pools.arcor-ip.net [84.59.68.13]) by mail-in-02.arcor-online.net (Postfix) with ESMTPS id 321103FE0E6; Sat, 25 Jul 2009 03:47:17 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6P1lFIS000904; Sat, 25 Jul 2009 03:47:15 +0200 (CEST) Date: Sat, 25 Jul 2009 03:47:15 +0200 From: Roland Mainz Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: Busybox development Cc: Alan Coopersmith , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6A6423.AB589940@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-02.arcor-online.net 321103FE0E6 X-Antispam: No, score=0.0/5.0, scanned in 0.191sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> Status: RO Content-Length: 2957 Garrett D'Amore wrote: > Alan Coopersmith wrote: > > Garrett D'Amore wrote: > >> Personally, I think --man, --html and --nroff and such is a dangerous > >> precedent to set. I'd rather not have them, and instead rely on the > >> "man" command to provide this functionality. > > > > Isn't it a bit late to raise such a concern, since the precedent was set > > in the long list of previous cases that used AST/ksh93 implementations? > > It might be. I certainly should have raised the issue back then. I'm > still not happy about this. Why ? > There's yet another concern, which is that I've found that man > and command --man do not generate the same document. So we know > introduce a problem were documentation delivered on the system can be > inconsistent. Erm... no. As said in my other email the "--man" output is basically a short/terse format and more or less exactly what the "getopts" parser sees (it may even be usefull if main documentation and actual code are out-of-sync (which is currently the case for many commands)). > I feel really strongly that this was a bad idea. IMO it was a nice idea - see my other email where this feature originated from. > Strongly enough that > I'm contemplating derailing the case. And what should we do then ? The only thing we can do is to remove it from the case materials - removing it from the code can only be done globally (e.g. libast) and that really will break existing&&ARC'ed parts. [snip] > > No matter what you multiply $0 by, it's still $0. (We don't localize man > > pages in Solaris. A subset of man pages used to be translated to Japanese, > > but I believe even that is no longer done.) > > Really? That comes as a surprise. But we *do* localize commands. Actually the situation is AFAIK currently that there is not really much funding for this left and the basic system commands are very low priority. That's why I am currently working on getting a rag-tag team set-up to get l10n catalogs for the AST commands (e.g. covering ksh93 itself and all commands which go through the busybox-like "alias" wrapper (including those commands covered by this ARC case)) integrated (first covering Japanese, Chinese, French and later German, Spanish, Russian, Urkainian locales). > So > does putting --man content in the command suddenly mean that in order to > be I18N compliant they have to be localized? That would certainly add > to the cost. I don't understand the connection here: 1. "i18n" is "internationalisation", e.g. the support for non-ASCII characters&co. and this is fully covered by the new commands (and I am _very_ picky about this detail). 2. "l10n" means "localistion" and mainly rotates around error strings/messages/etc. being provided in non-english languages. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore@sun.com Fri Jul 24 23:02:05 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6P625Rs028695 for ; Fri, 24 Jul 2009 23:02:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6P623ex010547 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Jul 2009 23:02:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNB0060ZQ3GNO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 23:02:04 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00KEAQ349240@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 23:02:04 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6P61qks011753 for ; Fri, 24 Jul 2009 23:01:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNB00D00Q1WEN00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 23:01:51 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNB00I7EQ33Y6F0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 23:01:51 -0700 (PDT) Date: Fri, 24 Jul 2009 23:01:51 -0700 From: "Garrett D'Amore" Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6A6423.AB589940@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Busybox development , Alan Coopersmith , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6A9FCF.5020100@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 9399 Roland Mainz wrote: > Garrett D'Amore wrote: > >> Alan Coopersmith wrote: >> >>> Garrett D'Amore wrote: >>> >>>> Personally, I think --man, --html and --nroff and such is a dangerous >>>> precedent to set. I'd rather not have them, and instead rely on the >>>> "man" command to provide this functionality. >>>> >>> Isn't it a bit late to raise such a concern, since the precedent was set >>> in the long list of previous cases that used AST/ksh93 implementations? >>> >> It might be. I certainly should have raised the issue back then. I'm >> still not happy about this. >> > > Why ? > I'll explain why further down. > >> There's yet another concern, which is that I've found that man >> and command --man do not generate the same document. So we know >> introduce a problem were documentation delivered on the system can be >> inconsistent. >> > > Erm... no. As said in my other email the "--man" output is basically a > short/terse format and more or less exactly what the "getopts" parser > sees (it may even be usefull if main documentation and actual code are > out-of-sync (which is currently the case for many commands)). > No, it isn't. (Well, you might have "extra" text in the getopts parser, but for an example look at the output from sum --help. Its quite a rich manual page, far beyond the normal getopts kind of messaging.) > >> I feel really strongly that this was a bad idea. >> > > IMO it was a nice idea - see my other email where this feature > originated from. > I understand the notion. And for projects that don't have the same considerations we do, the idea is elegant. But I'll elaborate further below why I think this idea is *not* a good idea for our project. > >> Strongly enough that >> I'm contemplating derailing the case. >> > > And what should we do then ? The only thing we can do is to remove it > from the case materials - removing it from the code can only be done > globally (e.g. libast) and that really will break existing&&ARC'ed > parts. > #ifdef SOLARIS ? Seriously, if you want Solaris to adopt these commands in favor of our current native implementations, then there has to be some willingness to address architectural issues found on, or even specific to, Solaris. > [snip] > >>> No matter what you multiply $0 by, it's still $0. (We don't localize man >>> pages in Solaris. A subset of man pages used to be translated to Japanese, >>> but I believe even that is no longer done.) >>> >> Really? That comes as a surprise. But we *do* localize commands. >> > > Actually the situation is AFAIK currently that there is not really much > funding for this left and the basic system commands are very low > priority. That's why I am currently working on getting a rag-tag team > set-up to get l10n catalogs for the AST commands (e.g. covering ksh93 > itself and all commands which go through the busybox-like "alias" > wrapper (including those commands covered by this ARC case)) integrated > (first covering Japanese, Chinese, French and later German, Spanish, > Russian, Urkainian locales). > That may be the case. However, the your misunderstanding my argument, at the bottom of this message I'll elaborate further. > >> So >> does putting --man content in the command suddenly mean that in order to >> be I18N compliant they have to be localized? That would certainly add >> to the cost. >> > > I don't understand the connection here: > 1. "i18n" is "internationalisation", e.g. the support for non-ASCII > characters&co. and this is fully covered by the new commands (and I am > _very_ picky about this detail). > The point is that it must be possible for the commands to be localized. While there is no *technical* difference imposed by the length of the string, the string itself must be localizable. That means you can't elide handling of this when you localize the rest of the command, I think. > 2. "l10n" means "localistion" and mainly rotates around error > strings/messages/etc. being provided in non-english languages. > Yes. Now let me break down the architectural problems I have with --man (and also with --nroff and --troff), as they pertain to Solaris: 1) The commands increase the size of the text segment. Not only does it add new parsing requirements (you have to at least have enough code to handle --man, for example), but you also have the text of the man pages themselves. While you might like to maintain the fiction that this comes for free, it *is* a fiction. Run sum --man or some of the other commands and you'll see content that was not automatically generated. 2) We also have traditional manual pages. On a normal system, the default installation will include now *two* copies of the manual page. This is wasted space. 3) Worse, the pages can be out of synch with each other. (The sum man pages are again a good example of this.) Which is correct? (*Probably* the --man command output.) 4) Furthermore, the --man output doesn't reflect standards required for Sun man pages. For example, there is no ATTRIBUTES table. 5) Some users elect to *remove* manual pages (or not install them) to save space. We've long offered this choice. However, putting the man pages in the binary effectively removes this choice from the user. 6) There has historically been different processes for man page content generation than for software engineering. By putting the man page content into the binary, you basically wind up skipping the editorial review (and in many cases creation) of those man pages by our professional documentation writers and editors. 7) The rules for localization of documentation and commands have historically often been different (based on funding levels, rules for selling to different locales, and business priorities.) By putting manual page content hard coded into the documentation, you wind up creating a locked relationship where the two have to be localized together, or not at all. This ultimately increases the cost of localizing a command should such a localization be desired. (Translators often charge by the word.) 8) The teams involved with localization of manual pages vs. commands have historically been different, and have different costs. I strongly suspect it costs more to localize a command than it does to localize documentation. (You have to test the command, and the translators also need to know more about technical details such as handling message catalogs.) So if we do decide we need to localize this stuff in the future, its probably going to cost us more to do in a binary than it would as an actual document. 9) Worse, if we keep *both* the man page and the command text, we might wind up paying *double* the cost, by translating *both* versions. 10) Whether we want to admit it or not, when many of our core utilities start doing this, the request is going to be that the rest of our utilities (e.g. dladm, ifconfig, maybe even the man command itself!) support --man as well. (I admit at first blush its a nifty feature, and many users are going to like it, without understanding or caring about the the ramifications I've listed above.) So saying that this doesn't set precedent is IMO akin to putting ones fingers in ones ears and saying LALALALA... If we're going down this road, then it needs to be an explicit decision rather than something that happened as an implementation accident. Now, all that said I do understand why the AST/ksh93 team has gone down this road. Indeed, if I was going to deliver an unbundled project, I might make the same decisions. Many of the above concerns won't be relevant to David Korn or Glenn Fowler, and this approach probably *does* solve problems that the upstream cares about (no need to write actual separate man pages for example). But they *are* relevant to Sun and the Solaris project. Many of the above issues could be handled more cleanly by simply having --man execute the man command and feed the generated result. But then, this begs the question, why not just run "man command" instead of "command --man" ? (Indeed, the first form is more familiar and requires less typing than the introduced --man content.) So with all that said, I believe that its *important* that the decision to inline man pages into libraries and manual pages be made *explicitly* by the ARC. I believe (going back and reading over the previous ARC materials) that this detail was largely unconsidered during previous ARC cases, and I would like the ARC membership the change to think on the above points I've made, and make a decision explicitly. With that in mind, I'm derailing this case for a vote, and I'll write the opinion. Unless you want to provide more answers or responses to my above points, I don't think any further work is required from the project team -- we have enough information (I think) to proceed with a vote on this. I will say just one more thing. Where it not for the --man, --nroff, and --html options, I think I would unhesitatingly give this case a +1. I think the rest of the case has a great deal of technical merit, and I actually would like to see the changes integrated -- just without manual pages integrated into the binaries. -- Garrett From gsf@research.att.com Sat Jul 25 01:49:15 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6P8nE9q004024 for ; Sat, 25 Jul 2009 01:49:15 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6P8nC51004575 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 09:49:14 +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 <0KNB00805XU0ZI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 01:49:12 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00FDPXTZRH70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 01:49:12 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6P8ipi6001910 for ; Sat, 25 Jul 2009 08:49:11 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-147286 for PSARC-ext@sun.com; Sat, 25 Jul 2009 08:49:11 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-551525 for PSARC-ext@sun.com; Sat, 25 Jul 2009 08:49:10 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-1384839 for PSARC-ext@sun.com; Sat, 25 Jul 2009 08:47:24 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id 5C21691BE; Sat, 25 Jul 2009 04:47:12 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6P8lBon031464; Sat, 25 Jul 2009 04:47:11 -0400 Date: Sat, 25 Jul 2009 04:47:11 -0400 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: ksh93-integration-discuss@opensolaris.org, roland.mainz@nrubsig.org Cc: busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <200907250847.n6P8lBon031464@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.088sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> Status: RO Content-Length: 2768 On Fri, 24 Jul 2009 23:01:51 -0700 Garrett D'Amore wrote: > Now let me break down the architectural problems I have with --man (and > also with --nroff and --troff), as they pertain to Solaris: > 1) The commands increase the size of the text segment. Not only does > it add new parsing requirements (you have to at least have enough code > to handle --man, for example), but you also have the text of the man > pages themselves. While you might like to maintain the fiction that > this comes for free, it *is* a fiction. Run sum --man or some of the > other commands and you'll see content that was not automatically generated. a point, a question, some background, and a comment point for any ast command --??? lists the man page for options available to all ast commands via libast::optget(), so the "new parsing requirements" are provided in one place, most likely a shared library function, not in each command question "you'll see content that was not automatically generated" ? well part of sum --man *is* automatically generated specifically the methods listed for --method (try sum --?method) each method provides its own documentation that is combined at runtime for --man etc. via an optget() callback function that scans a method table although ast sum does not use plugins (methods in runtime shared libs / dlls) other ast commands do (e.g., pax, sort, vczip (not part of this case)) and plugins provide documentation using the same mechanism; plugins added to the command specific plugin path will show up in the next self-documenting (--man) output the ksh93 ulimit resource related options are generated on the fly from a separate resource table there are a few other instances where ksh93 generates option and self-documentation at runtime -- (script) user defined types is one example -- I'll let dgk elaborate on that background motivations behind --man in optget() - avoid duplication that may result in documentation that does not reflect implementation (if its not in the optget() usage then its not implemented) - avoid the man command providing legitimate documentation for the wrong command (PATH points to a different foo than man foo) - installing a command a.out also installs its documentation the static ksh93 sh.1 man page is an exception to the ast rule: the man pages for almost all other ast commands (ARC'd or not) are derived from --man, and there are no plans to provide static .1 man pages for them if solaris requires a .1 for each command then for the ast commands I imagine that being done via --nroff with a bit of automated filtering comment this is the first time I can remember someone complaining about (me) *providing* documentation -- Glenn Fowler -- at&t Research, Florham Park NJ -- From iszczesniak@gmail.com Sat Jul 25 03:20:13 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PAKCDh005138 for ; Sat, 25 Jul 2009 03:20:12 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6PAK9jl014142 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 11:20:11 +0100 (BST) 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 <0KNC0040121NTO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 04:20:11 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00E4X21MEO30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 04:20:11 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PAKAMA016682 for ; Sat, 25 Jul 2009 10:20:10 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-258375 for PSARC-ext@sun.com; Sat, 25 Jul 2009 10:20:10 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-4498108 for PSARC-ext@sun.com; Sat, 25 Jul 2009 10:20:09 +0000 (Z) Received: from mail-bw0-f211.google.com ([209.85.218.211] [209.85.218.211]) by relay1i.sun.com with ESMTP id BT-MMP-1556387 for PSARC-ext@sun.com; Sat, 25 Jul 2009 10:20:08 +0000 (Z) Received: by bwz7 with SMTP id 7so1833734bwz.8 for ; Sat, 25 Jul 2009 03:20:00 -0700 (PDT) Received: by 10.204.122.200 with SMTP id m8mr703017bkr.176.1248517200202; Sat, 25 Jul 2009 03:20:00 -0700 (PDT) Date: Sat, 25 Jul 2009 12:20:00 +0200 From: "I. Szczesniak" Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6A9FCF.5020100@sun.com> To: Korn Shell 93 integration/migration project discussion Cc: Roland Mainz , Busybox development , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bFI4CGj+DGds2hOTIdQAF+1iyohQRYyQ4+qyioNgWG0=; b=cvZb0pbdtrDB8+NyW68kyVdbqBWrj2QKH3ITmTMLvDi9XL6vFVC2itKX3y39VqXqbp uKuqGMkblgrjdT0PaM1UGCDmnrAFid2GN3Vqway37MGJAb1YKT4EtuTwyHaatVSRRbry wCil/hKXHLabIqmDIMmw9QTZIABlSuwajwY3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J9/is8TvNTlcGFrXNBnJcsnlHgvnUPsdFCTxNE1S9lR2iIMG28CUUhewTVFFYp3uTg r4cIMUY3Sk7iZmxSTqXakcRHcc08Rey7JmjubvfACT78dT2OtlYGCY3jLRXGexHB7d0S F/oP44N+XoxT3SPdUp573YD9qdGKLsmRk5FLE= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.084sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> Status: RO Content-Length: 3336 On 7/25/09, Garrett D'Amore wrote: > Roland Mainz wrote: > > > Garrett D'Amore wrote: > > > > > > > Alan Coopersmith wrote: > > > > > > > > > > Garrett D'Amore wrote: > > > > > > > > > > > > > Personally, I think --man, --html and --nroff and such is a > dangerous > > > > > precedent to set. I'd rather not have them, and instead rely on the > > > > > "man" command to provide this functionality. > > > > > > > > > > > > > > Isn't it a bit late to raise such a concern, since the precedent was > set > > > > in the long list of previous cases that used AST/ksh93 > implementations? > > > > > > > > > > > It might be. I certainly should have raised the issue back then. I'm > > > still not happy about this. > > > > > > > > > > Why ? > > > > > > I'll explain why further down. > > > > > > > > > There's yet another concern, which is that I've found that man > > > and command --man do not generate the same document. So we know > > > introduce a problem were documentation delivered on the system can be > > > inconsistent. > > > > > > > > > > Erm... no. As said in my other email the "--man" output is basically a > > short/terse format and more or less exactly what the "getopts" parser > > sees (it may even be usefull if main documentation and actual code are > > out-of-sync (which is currently the case for many commands)). > > > > > > No, it isn't. (Well, you might have "extra" text in the getopts parser, > but for an example look at the output from sum --help. Its quite a rich > manual page, far beyond the normal getopts kind of messaging.) > > > > > > > > > I feel really strongly that this was a bad idea. > > > > > > > > > > IMO it was a nice idea - see my other email where this feature > > originated from. > > > > > > I understand the notion. And for projects that don't have the same > considerations we do, the idea is elegant. But I'll elaborate further below > why I think this idea is *not* a good idea for our project. You still failed to provide a sound technical reason why --man should be removed. > > > > > > > Strongly enough that > > > I'm contemplating derailing the case. > > > > > > > > > > And what should we do then ? The only thing we can do is to remove it > > from the case materials - removing it from the code can only be done > > globally (e.g. libast) and that really will break existing&&ARC'ed > > parts. > > > > > > #ifdef SOLARIS ? Are you SERIOUSLY suggesting the project team has to add 2196 #ifdef SOLARIS statements (45 commands, 4 per option, 20 to strip further text strings in the getopt template) in the code of libcmd? Who is going to maintain this code fork? > Seriously, if you want Solaris to adopt these commands in > favor of our current native implementations, then there has to be some > willingness to address architectural issues found on, or even specific to, > Solaris. I think the team working on the Solaris ksh93 project has shown the willingness to address reasonable architectural and technical issues on many occasions, even at the expense of crippling the set of features beyond the point I would consider acceptable. But I do not consider your proposal to strip --man from the code as reasonable. It adds an arbitrary Solaris-specific difference with NO technical justification. Please state technical reason. Irek From gdamore@sun.com Sat Jul 25 08:57:56 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PFvtD8014551 for ; Sat, 25 Jul 2009 08:57:56 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6PFvs1R028979 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 16:57:55 +0100 (BST) 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 <0KNC00K01HOI3G00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 09:57:54 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00EOAHOIE6B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 09:57:54 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PFvrYJ029083 for ; Sat, 25 Jul 2009 08:57:53 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNC00A00HGU4S00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 08:57:53 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNC00KPCHOHLSE0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 08:57:53 -0700 (PDT) Date: Sat, 25 Jul 2009 08:57:53 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: "I. Szczesniak" Cc: Korn Shell 93 integration/migration project discussion , Roland Mainz , Busybox development , PSARC-ext@sun.com Message-id: <4A6B2B81.4090504@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3772 I. Szczesniak wrote: > On 7/25/09, Garrett D'Amore wrote: > >> Roland Mainz wrote: >> >> >>> Garrett D'Amore wrote: >>> >>> >>> >>>> Alan Coopersmith wrote: >>>> >>>> >>>> >>>>> Garrett D'Amore wrote: >>>>> >>>>> >>>>> >>>>>> Personally, I think --man, --html and --nroff and such is a >>>>>> >> dangerous >> >>>>>> precedent to set. I'd rather not have them, and instead rely on the >>>>>> "man" command to provide this functionality. >>>>>> >>>>>> >>>>>> >>>>> Isn't it a bit late to raise such a concern, since the precedent was >>>>> >> set >> >>>>> in the long list of previous cases that used AST/ksh93 >>>>> >> implementations? >> >>>>> >>>> It might be. I certainly should have raised the issue back then. I'm >>>> still not happy about this. >>>> >>>> >>>> >>> Why ? >>> >>> >>> >> I'll explain why further down. >> >> >> >>> >>>> There's yet another concern, which is that I've found that man >>>> and command --man do not generate the same document. So we know >>>> introduce a problem were documentation delivered on the system can be >>>> inconsistent. >>>> >>>> >>>> >>> Erm... no. As said in my other email the "--man" output is basically a >>> short/terse format and more or less exactly what the "getopts" parser >>> sees (it may even be usefull if main documentation and actual code are >>> out-of-sync (which is currently the case for many commands)). >>> >>> >>> >> No, it isn't. (Well, you might have "extra" text in the getopts parser, >> but for an example look at the output from sum --help. Its quite a rich >> manual page, far beyond the normal getopts kind of messaging.) >> >> >> >>> >>>> I feel really strongly that this was a bad idea. >>>> >>>> >>>> >>> IMO it was a nice idea - see my other email where this feature >>> originated from. >>> >>> >>> >> I understand the notion. And for projects that don't have the same >> considerations we do, the idea is elegant. But I'll elaborate further below >> why I think this idea is *not* a good idea for our project. >> > > You still failed to provide a sound technical reason why --man should > be removed. > > >>> >>>> Strongly enough that >>>> I'm contemplating derailing the case. >>>> >>>> >>>> >>> And what should we do then ? The only thing we can do is to remove it >>> from the case materials - removing it from the code can only be done >>> globally (e.g. libast) and that really will break existing&&ARC'ed >>> parts. >>> >>> >>> >> #ifdef SOLARIS ? >> > > Are you SERIOUSLY suggesting the project team has to add 2196 #ifdef > SOLARIS statements (45 commands, 4 per option, 20 to strip further > text strings in the getopt template) in the code of libcmd? Who is > going to maintain this code fork? > > >> Seriously, if you want Solaris to adopt these commands in >> favor of our current native implementations, then there has to be some >> willingness to address architectural issues found on, or even specific to, >> Solaris. >> > > I think the team working on the Solaris ksh93 project has shown the > willingness to address reasonable architectural and technical issues > on many occasions, even at the expense of crippling the set of > features beyond the point I would consider acceptable. > > But I do not consider your proposal to strip --man from the code as > reasonable. It adds an arbitrary Solaris-specific difference with NO > technical justification. > Please state technical reason. > Did you actually read the architectural considerations at the bottom of the message? - Garrett > Irek > From Alan.Coopersmith@sun.com Sat Jul 25 09:57:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PGvOpp015190 for ; Sat, 25 Jul 2009 09:57:24 -0700 (PDT) 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 n6PGvLak013891 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 00:57:23 +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 <0KNC00F01KFLE300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 09:57:21 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC002RIKFL6DE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 09:57:21 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PGvL9E004122 for ; Sat, 25 Jul 2009 09:57:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNC00K00K4VA900@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 09:57:21 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNC00DXFKFKZ5B0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 09:57:21 -0700 (PDT) Date: Sat, 25 Jul 2009 09:57:20 -0700 From: Alan Coopersmith Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6A9FCF.5020100@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: Roland Mainz , Busybox development , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6B3970.2000400@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 5688 Garrett D'Amore wrote: > 1) The commands increase the size of the text segment. Not only does > it add new parsing requirements (you have to at least have enough code > to handle --man, for example), but you also have the text of the man > pages themselves. While you might like to maintain the fiction that > this comes for free, it *is* a fiction. Run sum --man or some of the > other commands and you'll see content that was not automatically generated. The minimum memory requirement for the release this is integrating into is 512Mb. A few k of memory, in a shared library that can be shared amongst all processes using it, is far down in the noise. > 2) We also have traditional manual pages. On a normal system, the > default installation will include now *two* copies of the manual page. > This is wasted space. We also install commands users never use, drivers for hardware they don't have (and could possibly never have), sample audio files they'll never listen to, etc. Text that helps them use a command is far more useful than any of those. > 3) Worse, the pages can be out of synch with each other. (The sum man > pages are again a good example of this.) Which is correct? (*Probably* > the --man command output.) This documentation is less likely to be out of sync with the implementation than the traditional man page. That's an improvement to the architecture, making sure the user always has at least a correct, if less detailed, source of documentation of the options. It will also always document the version the user is using - I've seen far too many questions on OpenSolaris e-mail and IRC from users confused because their PATH & MANPATH don't match and they're seeing /usr/gnu man pages but running /usr/bin commands, or vice versa. > 4) Furthermore, the --man output doesn't reflect standards required for > Sun man pages. For example, there is no > ATTRIBUTES table. That's a good reason why there should also be a traditional man page, and --man shouldn't replace it, just supplement it. > 5) Some users elect to *remove* manual pages (or not install them) to > save space. We've long offered this choice. However, putting the man > pages in the binary effectively removes this choice from the user. That choice was added when we shipped workstations with 105Mb hard disks. That choice makes no sense on today's computers and decreases system usability. Many of the install options added for 105Mb hard disks will be gone in the installer for the Solaris release this integrates to, since they make no sense in the day of 1Tb hard disks costing $100, and even embedded systems, like the cell phone in my pocket, having many times the disk space of that 105Mb SPARCstation 1. > 6) There has historically been different processes for man page content > generation than for software engineering. By putting the man page > content into the binary, you basically wind up skipping the editorial > review (and in many cases creation) of those man pages by our > professional documentation writers and editors. That's a good reason why there should also be a traditional man page, and --man shouldn't replace it, just supplement it. > 7) The rules for localization of documentation and commands have > historically often been different (based on funding levels, rules for > selling to different locales, and business priorities.) By putting > manual page content hard coded into the documentation, you wind up > creating a locked relationship where the two have to be localized > together, or not at all. This ultimately increases the cost of > localizing a command should such a localization be desired. > (Translators often charge by the word.) Translators don't have to translate every string in the application. > 9) Worse, if we keep *both* the man page and the command text, we might > wind up paying *double* the cost, by translating *both* versions. That argument, like the above, are Sun business decisions. If Sun wants to save money, it can make decisions about what it pays to translate, but that should not affect the architecture of the shared OpenSolaris code base. Please separate business considerations of one distro maker from the shared architecture of all distros. > 10) Whether we want to admit it or not, when many of our core utilities > start doing this, the request is going to be that the rest of our > utilities (e.g. dladm, ifconfig, maybe even the man command itself!) > support --man as well. (I admit at first blush its a nifty feature, and > many users are going to like it, without understanding or caring about > the the ramifications I've listed above.) So saying that this doesn't > set precedent is IMO akin to putting ones fingers in ones ears and > saying LALALALA... *THIS* case does not set precedent because this precedent was set in the previous cases shipping commands with --man/--html/--nroff options. This project team should not be penalized because you failed to raise objections to this architecture when those precedents were set. > Now, all that said I do understand why the AST/ksh93 team has gone down > this road. Indeed, if I was going to deliver an unbundled project, I > might make the same decisions. Many of the above concerns won't be > relevant to David Korn or Glenn Fowler, and this approach probably > *does* solve problems that the upstream cares about (no need to write > actual separate man pages for example). But they *are* relevant to Sun > and the Solaris project. This is the OpenSolaris ARC, not Sun business review. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From pickychris@googlemail.com Sat Jul 25 11:14:26 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PIEPP8016280 for ; Sat, 25 Jul 2009 11:14:26 -0700 (PDT) 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 n6PIEC6s021036; Sun, 26 Jul 2009 02:14:23 +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 <0KNC00801NZY4X00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 11:14:22 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00GKRNZY1U80@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 11:14:22 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PIELnc011299; Sat, 25 Jul 2009 18:14:22 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay43i.sun.com with ESMTP id BT-MMP-949325; Sat, 25 Jul 2009 18:14:21 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-19264410; Sat, 25 Jul 2009 18:14:18 +0000 (Z) Received: from fg-out-1718.google.com ([72.14.220.154] [72.14.220.154]) by relay4i.sun.com with ESMTP id BT-MMP-16162795; Sat, 25 Jul 2009 18:14:18 +0000 (Z) Received: by fg-out-1718.google.com with SMTP id d23so596203fga.6 for ; Sat, 25 Jul 2009 11:14:17 -0700 (PDT) Received: by 10.86.89.6 with SMTP id m6mr936827fgb.1.1248545657405; Sat, 25 Jul 2009 11:14:17 -0700 (PDT) Date: Sat, 25 Jul 2009 20:14:17 +0200 From: Chris Pickett Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6A4042.8000700@sun.com> Sender: pickychris@googlemail.com To: Korn Shell 93 integration/migration project discussion Cc: Alan Coopersmith , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=S7Y7cTjYLv6hsv2o/k6JGOK9a2YRyOnTA7LH+2jb+6o=; b=X+VwagQ4A+Y1PRb1HMcrk28uNZHwXiEswZMN9Lmqv/eu7i2fqPS51aPmefX2JmgT4i Ls7TLVi2ift0OsoirYOlKYCdn+BdX6LtR9rjMll2XYwsAuHwyqzYYUV6pjkTGc6rw32E /JQYBjxjslAum1NLlfHCnQiYyPD+qMK8Ehri8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QIOZH3NhrzBQZJayvwthybiosvJVS5uUPXbty0HB20ZniL59DB30VVt9H+CBtYNC6N nYfM1pTfWxh+LzcQlAfLLrN+ZjlnWikwortJ73sdJain9H+2cfk6FI7xMwXu1hP6odSy YLo45nZPH3vRa2PBasCBHP6VRUYo5lwTgAypg= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: cddfa69bd210b2f7 X-Antispam: No, score=-0.2/5.0, scanned in 3.100sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> Status: RO Content-Length: 1011 On 7/25/09, Garrett D'Amore wrote: > My main concern here is the integration of manual page functionality into > the commands themselves. I see both benefits and costs. The benefit is > that the documentation is more likely to match the actual command. But part > of the cost is a much higher cost to perform localization for these, and > (depending on implementation) a potentially larger minimum size of the > binaries. (I'm assuming for the moment that the documentation is stored in > the binary, and the command is doing more than just executing some pipeline > to access the manual content from /usr/share/man or whatever.) > > Personally, I think --man, --html and --nroff and such is a dangerous > precedent to set. What about --help and --version? Do you object to those options, too? Would you drop your concerns if Roland would rename --man to --extended-help? Chris -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris@users.sourceforge.net From gdamore@sun.com Sat Jul 25 11:27:33 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PIRWZK016317 for ; Sat, 25 Jul 2009 11:27:32 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6PIRQsM001746 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 19:27:31 +0100 (BST) 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 <0KNC00E01OLV1X00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:27:31 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC004MPOLUL6B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:27:30 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PIRUnJ001382 for ; Sat, 25 Jul 2009 11:27:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNC00H00OFU9200@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:27:30 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNC00DPTOLT0XB0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:27:30 -0700 (PDT) Date: Sat, 25 Jul 2009 11:27:29 -0700 From: "Garrett D'Amore" Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B3970.2000400@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: Roland Mainz , Busybox development , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6B4E91.6020002@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 8870 Alan Coopersmith wrote: > Garrett D'Amore wrote: > >> 1) The commands increase the size of the text segment. Not only does >> it add new parsing requirements (you have to at least have enough code >> to handle --man, for example), but you also have the text of the man >> pages themselves. While you might like to maintain the fiction that >> this comes for free, it *is* a fiction. Run sum --man or some of the >> other commands and you'll see content that was not automatically generated. >> > > The minimum memory requirement for the release this is integrating into > is 512Mb. A few k of memory, in a shared library that can be shared amongst > all processes using it, is far down in the noise. > This attitude, spread across dozens, or hundreds of projects, is part of the reason why software still struggles even in the face of Moore's law. Nobody cares about a few kB, but those kB add up in aggregate. > >> 2) We also have traditional manual pages. On a normal system, the >> default installation will include now *two* copies of the manual page. >> This is wasted space. >> > > We also install commands users never use, drivers for hardware they don't > have (and could possibly never have), sample audio files they'll never > listen to, etc. Text that helps them use a command is far more useful > than any of those. > Yes, but *two* copies of the text? And in many cases those drivers *can* be easily removed, as can the audio files. They are uninstallable. (In fact, I recently pushed a change to delete a 300k audio file that nobody listens to anymore. The remaining audio files are much smaller, and *may* be used by various applications or user configs.) > >> 3) Worse, the pages can be out of synch with each other. (The sum man >> pages are again a good example of this.) Which is correct? (*Probably* >> the --man command output.) >> > > This documentation is less likely to be out of sync with the implementation > than the traditional man page. That's an improvement to the architecture, > making sure the user always has at least a correct, if less detailed, source > of documentation of the options. It will also always document the version > the user is using - I've seen far too many questions on OpenSolaris e-mail > and IRC from users confused because their PATH & MANPATH don't match and > they're seeing /usr/gnu man pages but running /usr/bin commands, or vice versa. > I agree that this is likely to be an improvement (although it turns out that the documentation in the command still has to be maintained.) Does that mean we abandon traditional man pages? > >> 4) Furthermore, the --man output doesn't reflect standards required for >> Sun man pages. For example, there is no >> ATTRIBUTES table. >> > > That's a good reason why there should also be a traditional man page, and > --man shouldn't replace it, just supplement it. > Your response here conflicts with your response to point #3 above. Either we have one canonical copy of the documentation that should always be correct and maintained, or we risk having the two copies get out of sync or become inaccurate. Which should it be? > >> 5) Some users elect to *remove* manual pages (or not install them) to >> save space. We've long offered this choice. However, putting the man >> pages in the binary effectively removes this choice from the user. >> > > That choice was added when we shipped workstations with 105Mb hard disks. > That choice makes no sense on today's computers and decreases system > usability. Many of the install options added for 105Mb hard disks will > be gone in the installer for the Solaris release this integrates to, since > they make no sense in the day of 1Tb hard disks costing $100, and even > embedded systems, like the cell phone in my pocket, having many times the > disk space of that 105Mb SPARCstation 1. > I seem to recall we are also struggling to find room on the LiveCD. Space constraints are *not* a thing of the past. This attitude -- memory is cheap so it doesn't matter -- is why systems that should be fully capable of performing the same basic tasks we did 5 years ago, are now no longer able to boot an operating system even though the end user is really just interested in doing the same basic task. Yes, I believe in tight code. Yes I believe memory should still be treated as a precious resource. No, I don't think it is unreasonable to ask to be able to use an operating system with 128 MB of RAM. As far as I'm concerned, this "fight" is the "good fight", and I'll stand my ground on it. I may well be overruled, but I refused to just take the easy and lazy path of considering system resources an infinitely wasteable resource. > >> 6) There has historically been different processes for man page content >> generation than for software engineering. By putting the man page >> content into the binary, you basically wind up skipping the editorial >> review (and in many cases creation) of those man pages by our >> professional documentation writers and editors. >> > > That's a good reason why there should also be a traditional man page, and > --man shouldn't replace it, just supplement it. > > >> 7) The rules for localization of documentation and commands have >> historically often been different (based on funding levels, rules for >> selling to different locales, and business priorities.) By putting >> manual page content hard coded into the documentation, you wind up >> creating a locked relationship where the two have to be localized >> together, or not at all. This ultimately increases the cost of >> localizing a command should such a localization be desired. >> (Translators often charge by the word.) >> > > Translators don't have to translate every string in the application. > Since when? I thought that pretty much every human interaction had to be l10n'd in order to be qualified as localized. This is the first time I've heard of "partially" localizing an application. Are there any other precedents for this? > >> 9) Worse, if we keep *both* the man page and the command text, we might >> wind up paying *double* the cost, by translating *both* versions. >> > > That argument, like the above, are Sun business decisions. If Sun wants > to save money, it can make decisions about what it pays to translate, but > that should not affect the architecture of the shared OpenSolaris code base. > Please separate business considerations of one distro maker from the shared > architecture of all distros. > Separating things like basic costs from architecture is IMO foolish. We don't live in an abstract world were funding is unlimited and memory is free. In the real world, getting work done costs money. And, I'm not even talking about what this might cost Sun -- the same costs apply to *anyone* who might perform this work. > >> 10) Whether we want to admit it or not, when many of our core utilities >> start doing this, the request is going to be that the rest of our >> utilities (e.g. dladm, ifconfig, maybe even the man command itself!) >> support --man as well. (I admit at first blush its a nifty feature, and >> many users are going to like it, without understanding or caring about >> the the ramifications I've listed above.) So saying that this doesn't >> set precedent is IMO akin to putting ones fingers in ones ears and >> saying LALALALA... >> > > *THIS* case does not set precedent because this precedent was set in the > previous cases shipping commands with --man/--html/--nroff options. This > project team should not be penalized because you failed to raise objections > to this architecture when those precedents were set. > The precedent set was not made explicitly -- in my opinion it slid by without due consideration. I'm not saying we have to go back and rip out the support from existing commands -- but I *am* saying that if this is going to be the new way of doing things, then we ought to at least properly consider it. So yes, I do get to ask that we reconsider the direction. ARC has done this to numerous projects in the past as well. > >> Now, all that said I do understand why the AST/ksh93 team has gone down >> this road. Indeed, if I was going to deliver an unbundled project, I >> might make the same decisions. Many of the above concerns won't be >> relevant to David Korn or Glenn Fowler, and this approach probably >> *does* solve problems that the upstream cares about (no need to write >> actual separate man pages for example). But they *are* relevant to Sun >> and the Solaris project. >> > > This is the OpenSolaris ARC, not Sun business review. > But it is relevant to *SOLARIS*. (Or if you prefer *OpenSolaris*.) -- Garrett From pickychris@googlemail.com Sat Jul 25 11:30:59 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PIUwhk016331 for ; Sat, 25 Jul 2009 11:30:59 -0700 (PDT) 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 n6PIUubv028747 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 02:30:57 +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 <0KNC00E07ORKBO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:30:56 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00461ORJKVB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:30:55 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PIIL8u024933 for ; Sat, 25 Jul 2009 18:30:55 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-272330 for PSARC-ext@sun.com; Sat, 25 Jul 2009 18:30:55 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-5317314 for PSARC-ext@sun.com; Sat, 25 Jul 2009 18:30:50 +0000 (Z) Received: from fg-out-1718.google.com ([72.14.220.153] [72.14.220.153]) by relay1i.sun.com with ESMTP id BT-MMP-8859067 for PSARC-ext@sun.com; Sat, 25 Jul 2009 18:23:33 +0000 (Z) Received: by fg-out-1718.google.com with SMTP id l27so268989fgb.6 for ; Sat, 25 Jul 2009 11:22:33 -0700 (PDT) Received: by 10.86.93.20 with SMTP id q20mr942696fgb.16.1248546151873; Sat, 25 Jul 2009 11:22:31 -0700 (PDT) Date: Sat, 25 Jul 2009 20:22:31 +0200 From: Chris Pickett Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: Sender: pickychris@googlemail.com To: Korn Shell 93 integration/migration project discussion Cc: PSARC-ext@sun.com, Busybox development Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=b5GTU8PujnyCPJSaEWNOsD2IRPNdZ/x4BkhVhof6jfs=; b=f34lIhDFxExuzTWVKb+lJ8G8Y0gXfGOsiRFCJ7LvyEqN5SOnNHQEdmb7FaBCxtuJxe EIFy9xzlM6UpOYg9grRgkqNWBlakdcXJ2UT3uOkSkpDKx12JtUxiP354iwHV5jXaahbc f7xxxIOJOubGQrx/9dJcB1wA3BiVWj8aVyXME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sQSevizpxYOswTEGfeH2ugoqlisOD3U2GiO3USGiUbE9xeVjgTszXwF7F3wPtdCnhK pnwJyXMC0DB/z3nX9DNFoI8rQ865ipezCjkB3iOeu7RCq7H3hHNXTieWiLYtVhuwxbNg OHZMfvCRi2a1uf64T36pcKNNG2GYSMfB/NpLk= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 254813644dfa548e X-Antispam: No, score=0.0/5.0, scanned in 3.015sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> Status: RO Content-Length: 521 > > #ifdef SOLARIS ? > > > Are you SERIOUSLY suggesting the project team has to add 2196 #ifdef > SOLARIS statements (45 commands, 4 per option, 20 to strip further > text strings in the getopt template) in the code of libcmd? Irek, you cannot comment the getopts option description out without breaking options --help and --version and the /usr/bin/sum, /usr/bin/cksum and /usr/bin/ulimit utilities. Chris -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris@users.sourceforge.net From gdamore@sun.com Sat Jul 25 11:32:31 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PIWUFf016364 for ; Sat, 25 Jul 2009 11:32:31 -0700 (PDT) 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 n6PIWTvn029669 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 02:32:29 +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 <0KNC00E01OU4F200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:32:28 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC004N4OU4L1B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:32:28 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PIWSYs001463 for ; Sat, 25 Jul 2009 11:32:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNC00H00OJ1EO00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:32:28 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNC007MWOU3N440@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 11:32:28 -0700 (PDT) Date: Sat, 25 Jul 2009 11:32:27 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: Chris Pickett Cc: Korn Shell 93 integration/migration project discussion , Alan Coopersmith , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <4A6B4FBB.1070808@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1804 Chris Pickett wrote: > On 7/25/09, Garrett D'Amore wrote: > >> My main concern here is the integration of manual page functionality into >> the commands themselves. I see both benefits and costs. The benefit is >> that the documentation is more likely to match the actual command. But part >> of the cost is a much higher cost to perform localization for these, and >> (depending on implementation) a potentially larger minimum size of the >> binaries. (I'm assuming for the moment that the documentation is stored in >> the binary, and the command is doing more than just executing some pipeline >> to access the manual content from /usr/share/man or whatever.) >> >> Personally, I think --man, --html and --nroff and such is a dangerous >> precedent to set. >> > > What about --help and --version? Do you object to those options, too? > Would you drop your concerns if Roland would rename --man to > --extended-help? > When the --man output really is a manual page, I still object. It doesn't matter what you call it -- the problem is that we have two copies of the same information, the on-line manual page and the bits in the binary. Actually, if --man were to generate an actual man page by reading the man text from the on-disk file that is formatted by man(1) itself, then I would probably answer all (or very nearly so) of my concerns about this. If you read my architectural concerns about this, then you'd understand why I have problems with it. (Right now it looks like I'm very much in the minority -- maybe a minority of one on this -- but if so then a vote on the issue will be easy for the project team to achieve, and costs nobody anything except me -- and the cost to me is that I'll have to write the resulting opinion.) - Garrett From pickychris@googlemail.com Sat Jul 25 11:46:17 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PIkGr4016406 for ; Sat, 25 Jul 2009 11:46:17 -0700 (PDT) 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 n6PIkBSq006002; Sun, 26 Jul 2009 02:46:14 +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 <0KNC00G05PH1EA00@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 12:46:13 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00C35PH1BH40@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 12:46:13 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PIfasr001489; Sat, 25 Jul 2009 18:46:13 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-272809; Sat, 25 Jul 2009 18:46:13 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-5418710; Sat, 25 Jul 2009 18:46:09 +0000 (Z) Received: from mail-fx0-f222.google.com ([209.85.220.222] [209.85.220.222]) by relay1i.sun.com with ESMTP id BT-MMP-5874365; Sat, 25 Jul 2009 18:41:11 +0000 (Z) Received: by fxm22 with SMTP id 22so1962608fxm.8 for ; Sat, 25 Jul 2009 11:40:14 -0700 (PDT) Received: by 10.86.54.7 with SMTP id c7mr970435fga.24.1248547214706; Sat, 25 Jul 2009 11:40:14 -0700 (PDT) Date: Sat, 25 Jul 2009 20:40:14 +0200 From: Chris Pickett Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B4E91.6020002@sun.com> Sender: pickychris@googlemail.com To: Korn Shell 93 integration/migration project discussion Cc: Alan Coopersmith , PSARC-ext@sun.com, Busybox development Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=hR8vL4KZPJ5lUCOp2GKpYBWLInv7dCmatp7eAhNd/lg=; b=RXjkWF0Rw/8q/ZqH3NdnRgdNzeyn2WmAIv8lN54Pa128sxoh6R4WgNAztrKdEKziqu fk8oB0a3ves3Kb1DCb1MLL2hplOzt8zb1PL30drLYSPtZsmaYpPrcgjLSOt3PfBB9wXQ eBZh1TjdnhyHxLF27x2439XSCstYkqPs/dRm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MOC4GVXhrplvKvVZIy174I300c5+p7WEYPElEQVPq2LMUTO5N8vADwTVUV6JqerE4Y hH9CqGmUfPBbsCIW9j7pLEElpmN79T/EVssglrupAzKu2UDoGstkfVYSd0Mt7WEuP84m Kg+VmBi0BT2Rx+1tNj7NC1+VfM1Vra8/l6P+o= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 21cd87d0e6e310c9 X-Antispam: No, score=-1.1/5.0, scanned in 3.312sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> Status: RO Content-Length: 5804 On 7/25/09, Garrett D'Amore wrote: > Alan Coopersmith wrote: > > > Garrett D'Amore wrote: > > > > > > > 1) The commands increase the size of the text segment. Not only does > > > it add new parsing requirements (you have to at least have enough code > > > to handle --man, for example), but you also have the text of the man > > > pages themselves. While you might like to maintain the fiction that > > > this comes for free, it *is* a fiction. Run sum --man or some of the > > > other commands and you'll see content that was not automatically > generated. > > > > > > > > > > The minimum memory requirement for the release this is integrating into > > is 512Mb. A few k of memory, in a shared library that can be shared > amongst > > all processes using it, is far down in the noise. > > > > > > This attitude, spread across dozens, or hundreds of projects, is part of > the reason why software still struggles even in the face of Moore's law. > Nobody cares about a few kB, but those kB add up in aggregate. > > > > > > > > > 2) We also have traditional manual pages. On a normal system, the > > > default installation will include now *two* copies of the manual page. > This is wasted space. This is not wasted space. The string is used for parsing the arguments. You would see that if you'd ever took a look at the *code*. > > > > > > > > > > We also install commands users never use, drivers for hardware they don't > > have (and could possibly never have), sample audio files they'll never > > listen to, etc. Text that helps them use a command is far more useful > > than any of those. > > > > > > Yes, but *two* copies of the text? And in many cases those drivers *can* > be easily removed, as can the audio files. They are uninstallable. (In > fact, I recently pushed a change to delete a 300k audio file that nobody > listens to anymore. The remaining audio files are much smaller, and *may* > be used by various applications or user configs.) > > > > > > > > > 3) Worse, the pages can be out of synch with each other. (The sum man > > > pages are again a good example of this.) Which is correct? (*Probably* > > > the --man command output.) > > > > > > > > > > This documentation is less likely to be out of sync with the > implementation > > than the traditional man page. That's an improvement to the > architecture, > > making sure the user always has at least a correct, if less detailed, > source > > of documentation of the options. It will also always document the > version > > the user is using - I've seen far too many questions on OpenSolaris e-mail > > and IRC from users confused because their PATH & MANPATH don't match and > > they're seeing /usr/gnu man pages but running /usr/bin commands, or vice > versa. > > > > > > I agree that this is likely to be an improvement (although it turns out > that the documentation in the command still has to be maintained.) Garrett, would you take a look at the implementation, please? It would answer your question. > Does > that mean we abandon traditional man pages? > > > > > > > > > 4) Furthermore, the --man output doesn't reflect standards required for > > > Sun man pages. For example, there is no > > > ATTRIBUTES table. > > > > > > > > > > That's a good reason why there should also be a traditional man page, and > > --man shouldn't replace it, just supplement it. > > > > > > Your response here conflicts with your response to point #3 above. Either > we have one canonical copy of the documentation that should always be > correct and maintained, or we risk having the two copies get out of sync or > become inaccurate. Which should it be? > > > > > > > > > 5) Some users elect to *remove* manual pages (or not install them) to > > > save space. We've long offered this choice. However, putting the man > > > pages in the binary effectively removes this choice from the user. > > > > > > > > > > That choice was added when we shipped workstations with 105Mb hard disks. > > That choice makes no sense on today's computers and decreases system > > usability. Many of the install options added for 105Mb hard disks will > > be gone in the installer for the Solaris release this integrates to, since > > they make no sense in the day of 1Tb hard disks costing $100, and even > > embedded systems, like the cell phone in my pocket, having many times the > > disk space of that 105Mb SPARCstation 1. > > > > > > I seem to recall we are also struggling to find room on the LiveCD. Space > constraints are *not* a thing of the past. > > This attitude -- memory is cheap so it doesn't matter -- is why systems > that should be fully capable of performing the same basic tasks we did 5 > years ago, are now no longer able to boot an operating system even though > the end user is really just interested in doing the same basic task. > > Yes, I believe in tight code. Yes I believe memory should still be treated > as a precious resource. No, I don't think it is unreasonable to ask to be > able to use an operating system with 128 MB of RAM. > > As far as I'm concerned, this "fight" is the "good fight", and I'll stand > my ground on it. I may well be overruled, but I refused to just take the > easy and lazy path of considering system resources an infinitely wasteable > resource. I think a couple of people who work on the project will consider your comments as *offense*. Much time was spend in *reducing* memory usage and the commands which are used as replacements are tuned for *embedded* environments, i.e. low memory usage and low footprint. This was always the goal and will be the goal for the Opensolaris busybox project. Chris (who feels offended) -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris@users.sourceforge.net From pickychris@googlemail.com Sat Jul 25 11:49:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PIn4W3016539 for ; Sat, 25 Jul 2009 11:49:04 -0700 (PDT) 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 n6PImasI007229; Sun, 26 Jul 2009 02:49:01 +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 <0KNC00F01PLOJR00@nwk-avmta-2.sfbay.sun.com>; Sat, 25 Jul 2009 11:49:00 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC0040ZPLNKWC0@nwk-avmta-2.sfbay.sun.com>; Sat, 25 Jul 2009 11:48:59 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PImxok024965; Sat, 25 Jul 2009 18:48:59 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-164569; Sat, 25 Jul 2009 18:48:59 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-343319; Sat, 25 Jul 2009 18:48:54 +0000 (Z) Received: from fg-out-1718.google.com ([72.14.220.155] [72.14.220.155]) by relay1i.sun.com with ESMTP id BT-MMP-5879122; Sat, 25 Jul 2009 18:48:28 +0000 (Z) Received: by fg-out-1718.google.com with SMTP id l27so271032fgb.6 for ; Sat, 25 Jul 2009 11:48:16 -0700 (PDT) Received: by 10.86.89.6 with SMTP id m6mr958843fgb.1.1248547696351; Sat, 25 Jul 2009 11:48:16 -0700 (PDT) Date: Sat, 25 Jul 2009 20:48:16 +0200 From: Chris Pickett Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B4FBB.1070808@sun.com> Sender: pickychris@googlemail.com To: "Garrett D'Amore" Cc: Korn Shell 93 integration/migration project discussion , Alan Coopersmith , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ScfwiBXmcxV2zFHp4F+cG0+ehK5PdRq9l5EZbsY3BCg=; b=D+cT5O1dr4IYUukpgqVWetpGXNTcsBrcYfrBiKu1h16LYW+a3FMLGPqQdhvhZdeUWQ gcxKvhCehTmu0UQ6miHAJxeU3ZWKDSZjngh+rjTobqw0sG0PDvEDgAt7Dw8eZuyd+eR/ yT7zoCsKS7KrIMxDn2nSUypCl9/bP5W40C1A0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oKCfzqIoLFM+3XBRb6R/vTx/NW/9eS64r/4QNWBIlEMPwz/gaLCCqiBPJcp4zyp1+Q GfEHH0fcvlT2GJ3R6iSZD9dm4ZHifqz6OF0ekKCbOMoDn9lxtEFcRDF1Hf4u08Mzhovv qxlCSl/K457/0/U5r9TyMo2RFhnKx+B8vohr4= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: da5dc4f1f9db4ad3 X-Antispam: No, score=-0.7/5.0, scanned in 3.123sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> Status: RO Content-Length: 2386 On 7/25/09, Garrett D'Amore wrote: > Chris Pickett wrote: > > > On 7/25/09, Garrett D'Amore wrote: > > > > > > > My main concern here is the integration of manual page functionality > into > > > the commands themselves. I see both benefits and costs. The benefit is > > > that the documentation is more likely to match the actual command. But > part > > > of the cost is a much higher cost to perform localization for these, and > > > (depending on implementation) a potentially larger minimum size of the > > > binaries. (I'm assuming for the moment that the documentation is stored > in > > > the binary, and the command is doing more than just executing some > pipeline > > > to access the manual content from /usr/share/man or whatever.) > > > > > > Personally, I think --man, --html and --nroff and such is a dangerous > > > precedent to set. > > > > > > > > > > What about --help and --version? Do you object to those options, too? > > Would you drop your concerns if Roland would rename --man to > > --extended-help? > > > > > > When the --man output really is a manual page, I still object. It doesn't > matter what you call it -- the problem is that we have two copies of the > same information, the on-line manual page and the bits in the binary. > > Actually, if --man were to generate an actual man page by reading the man > text from the on-disk file that is formatted by man(1) itself, then I would > probably answer all (or very nearly so) of my concerns about this. If you would've ever researched the implementation you would come to the conclusion that this is not possible. The same string used for argument parsing is the same string used to generate the help, version, man, nroff and html output. There is no space wasted *anywhere*. > If you read my architectural concerns about this, then you'd understand why > I have problems with it. (Right now it looks like I'm very much in the > minority Yes, you are. >-- maybe a minority of one on this -- but if so then a vote on the > issue will be easy for the project team to achieve, and costs nobody > anything except me -- and the cost to me is that I'll have to write the > resulting opinion.) Where and when is such a vote done? Where can I vote? Chris -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris@users.sourceforge.net From unixconsole@yahoo.com Sat Jul 25 12:00:52 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PJ0p76023683 for ; Sat, 25 Jul 2009 12:00:51 -0700 (PDT) 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 n6PJ0lYJ012617 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 03:00: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 <0KNC00H07Q5BLU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:00:47 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00G5TQ5B1UD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:00:47 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PIvAkx018530 for ; Sat, 25 Jul 2009 19:00:47 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-950842 for PSARC-ext@sun.com; Sat, 25 Jul 2009 19:00:46 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-16970682 for PSARC-ext@sun.com; Sat, 25 Jul 2009 19:00:46 +0000 (Z) Received: from web30804.mail.mud.yahoo.com ([68.142.200.147] [68.142.200.147]) by relay4i.sun.com id BT-MMP-16228573 for PSARC-ext@sun.com; Sat, 25 Jul 2009 19:00:46 +0000 (Z) Received: (qmail 50882 invoked by uid 60001); Sat, 25 Jul 2009 19:00:24 +0000 Received: from [67.232.108.234] by web30804.mail.mud.yahoo.com via HTTP; Sat, 25 Jul 2009 12:00:23 -0700 (PDT) Date: Sat, 25 Jul 2009 12:00:23 -0700 (PDT) From: Octave Orgeron Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B4FBB.1070808@sun.com> To: "Garrett D'Amore" , Chris Pickett Cc: Korn Shell 93 integration/migration project discussion , PSARC-ext@sun.com, Alan Coopersmith , busybox-dev@opensolaris.org Message-id: <543740.62070.qm@web30804.mail.mud.yahoo.com> MIME-version: 1.0 X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1248548424; bh=idXXeScsnwfXzqPt0RRBSY70SMxaPK9RXrMNYefSYd0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KB0LtkMXPCo4aeGYHQUgMdeMs/m4Wk+ZsvFcRJSkYtDC3BbDmZbborUZ4qqPQL3JrJKRU9DoymOzNJnAL1RcehckNHS/XOKlgKwLcJcbd1aKUbV1xu4ennBY1Z054nUhfk9rgKj9OPiiH4qosGL9Lj1ofwgVdufu6tbUzwsJ33s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fCdEOg1w+NjYzFfLhQVQ/+knGsblPmXQnHGayIAeNb760UdVNEVgoLOM2xH1WZOaWtqqOBRtN+hRxVddnyMfEV3m34+6WIO3NsmiuIX44TPRs/mxC3hrrRsKQ5gO6P2VceQfjxD8puIXWWy696BPcQqT8KbAOR287y3H5Z+HBew=; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-YMail-OSG: 2vc58WkVM1nDRKWqD9.H1.OEwOMtJ9.3zA.W0xeOEuu.c1ymYQmU8ceGEH_h4F3L0bx_e55ehfpTUfYrFCiM5PU5_GP2E5d.Xpnsrf8NQ.r4Lj0C2XUDDwIsQup5XDhM5CSlu57hgQO51TAtVroLnkeeNiG0VKNqnCOgEEpRnRD3sauwhUHJfNO5qBYLXphTFJHB1Bs9uMNWoJEcZ7wec5swtRcu11dA.CZ_QC26CBU3GifH79HoIoDTRljmBqSj16ihf2aSQ6obrN.5PiF8_uYv58eETMCBKlDvlCaC3.eObAs2_NgBG69eHpyjXQiCo0RJqEXWxEwfdq0PM1zNklTY9.to4kd1 X-Antispam: No, score=-0.7/5.0, scanned in 0.098sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> Status: RO Content-Length: 3622 I totally agree with Garrett on this: 1. There should only be one man page that is maintained. 2. If the --man option is included, it should reference the man page data and not internal binary text. I think everyone would be happier with updating the man page for a command once, instead of having to recompile the binaries for each command. My concern here is consistency and standardization. We're already making the waters pretty murky with the plethora of common command versions/flavors (Sun, XPG4/6, BSD/UCB, GNU, etc.) in OpenSolaris. I do agree with the AST approach and hopefully in getting all our CLI tools to be 64-bit clean (still surprising Tru64 was the only one that succeeded in that). I also don't really care for the GNUisms, if someone needs them they should all reside in /usr/gnu. Solaris and OpenSolaris are not UNIX-like OS's, they are UNIX. As such, the defaults should always be the UNIX commands. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixconsole@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ----- Original Message ---- From: Garrett D'Amore To: Chris Pickett Cc: Korn Shell 93 integration/migration project discussion ; PSARC-ext@sun.com; Alan Coopersmith ; busybox-dev@opensolaris.org Sent: Saturday, July 25, 2009 1:32:27 PM Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Chris Pickett wrote: > On 7/25/09, Garrett D'Amore wrote: > >> My main concern here is the integration of manual page functionality into >> the commands themselves. I see both benefits and costs. The benefit is >> that the documentation is more likely to match the actual command. But part >> of the cost is a much higher cost to perform localization for these, and >> (depending on implementation) a potentially larger minimum size of the >> binaries. (I'm assuming for the moment that the documentation is stored in >> the binary, and the command is doing more than just executing some pipeline >> to access the manual content from /usr/share/man or whatever.) >> >> Personally, I think --man, --html and --nroff and such is a dangerous >> precedent to set. >> > > What about --help and --version? Do you object to those options, too? > Would you drop your concerns if Roland would rename --man to > --extended-help? > When the --man output really is a manual page, I still object. It doesn't matter what you call it -- the problem is that we have two copies of the same information, the on-line manual page and the bits in the binary. Actually, if --man were to generate an actual man page by reading the man text from the on-disk file that is formatted by man(1) itself, then I would probably answer all (or very nearly so) of my concerns about this. If you read my architectural concerns about this, then you'd understand why I have problems with it. (Right now it looks like I'm very much in the minority -- maybe a minority of one on this -- but if so then a vote on the issue will be easy for the project team to achieve, and costs nobody anything except me -- and the cost to me is that I'll have to write the resulting opinion.) - Garrett _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org From unixconsole@yahoo.com Sat Jul 25 12:04:34 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PJ4Yjg024216 for ; Sat, 25 Jul 2009 12:04:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6PJ4YbO010573 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 12:04:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNC00G03QBMMH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:04:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00414QBLL5C0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:04:33 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PJ4X06027633 for ; Sat, 25 Jul 2009 19:04:33 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay41i.sun.com with ESMTP id BT-MMP-927572 for PSARC-ext@sun.com; Sat, 25 Jul 2009 19:04:33 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-19431926 for PSARC-ext@sun.com; Sat, 25 Jul 2009 19:04:32 +0000 (Z) Received: from web30803.mail.mud.yahoo.com ([68.142.200.146] [68.142.200.146]) by relay4i.sun.com id BT-MMP-21147138 for PSARC-ext@sun.com; Sat, 25 Jul 2009 19:04:32 +0000 (Z) Received: (qmail 17175 invoked by uid 60001); Sat, 25 Jul 2009 19:03:42 +0000 Received: from [67.232.108.234] by web30803.mail.mud.yahoo.com via HTTP; Sat, 25 Jul 2009 12:03:42 -0700 (PDT) Date: Sat, 25 Jul 2009 12:03:42 -0700 (PDT) From: Octave Orgeron Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: To: "I. Szczesniak" , Korn Shell 93 integration/migration project discussion Cc: PSARC-ext@sun.com, Busybox development Message-id: <284568.16368.qm@web30803.mail.mud.yahoo.com> MIME-version: 1.0 X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1248548622; bh=gfcOpJNdo0rR11e8fwdyBZcnHgUMWmCDzEwZxZ/8pTY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5uN1Bvw44ftxM2A5eBp0Zvh4FEoinSfCGFuWuCKuHrC1/db6ytpKB1SswGApVASniGkiEUF7G3BB2Dw06lDI5b0XYRe8RE3IyFOIUs8etCywMnTDC646cjzAc80mfLi2A6DtkbNFTrQmDnYQaJLjMmEzouIYCx8JlgFea2SBgjY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ze4MV47swtlZelE9faZGmkIH8W2B2MWG6pmerrPypX4WtBCqTFfjq8rylWbQ+otryENSUE9RPR/k60qTrQpAqCtzG9Rh+25wXFfutE7lLUP8d5rKJRrdZi8Sor3AzMqPqLlt1OSuNJidJx2Twy+5Y6KHPM2dlR9kO+3a9s9ICuo=; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-YMail-OSG: WWIvBvEVM1nDoDMxGbKyqrdSPmYV2zOzRXLJFzkdiuRepJAMeD2nuBj8trSuW1h9kUownRUd1k.3aYG66EmoTziTS1PFw_hSvOcBglpjZnSDMywlIneDbuis7FJEnQ94RvD8c1OMs5XjOJ2hbxulbdHHLM.OH9_lY1yDQwXamZhsxxoGLbTimojoHGLBbOFOxGbh0aaZ2ipwOKMWuNkDebrhMY_iMdBu44nxp2kFoBEWvinDPZvNhio_U_du0f3qoLXuge6ZtpOCdPgvieeM9ZfV6k7Nvq8x9Xk4NnqZJ3XAOhsiu7eaY72mzbGC72mYP2N.88fbVaBpM9DfYJPzq8xEHa.Se6eqmzaFsSU9tUlJ1Q-- X-Antispam: No, score=-0.7/5.0, scanned in 0.107sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> Status: RO Content-Length: 4430 Why not add an option at compile/configure time to reference the native man pages for the target OS? That way it's not a Solaris specific feature, but an option anyone can use on any target platform?? I think that would be the best compromise. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixconsole@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ----- Original Message ---- From: I. Szczesniak To: Korn Shell 93 integration/migration project discussion Cc: PSARC-ext@sun.com; Busybox development Sent: Saturday, July 25, 2009 5:20:00 AM Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] On 7/25/09, Garrett D'Amore wrote: > Roland Mainz wrote: > > > Garrett D'Amore wrote: > > > > > > > Alan Coopersmith wrote: > > > > > > > > > > Garrett D'Amore wrote: > > > > > > > > > > > > > Personally, I think --man, --html and --nroff and such is a > dangerous > > > > > precedent to set. I'd rather not have them, and instead rely on the > > > > > "man" command to provide this functionality. > > > > > > > > > > > > > > Isn't it a bit late to raise such a concern, since the precedent was > set > > > > in the long list of previous cases that used AST/ksh93 > implementations? > > > > > > > > > > > It might be. I certainly should have raised the issue back then. I'm > > > still not happy about this. > > > > > > > > > > Why ? > > > > > > I'll explain why further down. > > > > > > > > > There's yet another concern, which is that I've found that man > > > and command --man do not generate the same document. So we know > > > introduce a problem were documentation delivered on the system can be > > > inconsistent. > > > > > > > > > > Erm... no. As said in my other email the "--man" output is basically a > > short/terse format and more or less exactly what the "getopts" parser > > sees (it may even be usefull if main documentation and actual code are > > out-of-sync (which is currently the case for many commands)). > > > > > > No, it isn't. (Well, you might have "extra" text in the getopts parser, > but for an example look at the output from sum --help. Its quite a rich > manual page, far beyond the normal getopts kind of messaging.) > > > > > > > > > I feel really strongly that this was a bad idea. > > > > > > > > > > IMO it was a nice idea - see my other email where this feature > > originated from. > > > > > > I understand the notion. And for projects that don't have the same > considerations we do, the idea is elegant. But I'll elaborate further below > why I think this idea is *not* a good idea for our project. You still failed to provide a sound technical reason why --man should be removed. > > > > > > > Strongly enough that > > > I'm contemplating derailing the case. > > > > > > > > > > And what should we do then ? The only thing we can do is to remove it > > from the case materials - removing it from the code can only be done > > globally (e.g. libast) and that really will break existing&&ARC'ed > > parts. > > > > > > #ifdef SOLARIS ? Are you SERIOUSLY suggesting the project team has to add 2196 #ifdef SOLARIS statements (45 commands, 4 per option, 20 to strip further text strings in the getopt template) in the code of libcmd? Who is going to maintain this code fork? > Seriously, if you want Solaris to adopt these commands in > favor of our current native implementations, then there has to be some > willingness to address architectural issues found on, or even specific to, > Solaris. I think the team working on the Solaris ksh93 project has shown the willingness to address reasonable architectural and technical issues on many occasions, even at the expense of crippling the set of features beyond the point I would consider acceptable. But I do not consider your proposal to strip --man from the code as reasonable. It adds an arbitrary Solaris-specific difference with NO technical justification. Please state technical reason. Irek _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org From gdamore@sun.com Sat Jul 25 12:25:17 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PJPG3c020211 for ; Sat, 25 Jul 2009 12:25:17 -0700 (PDT) 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 n6PJP9ec022978 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 03:25:16 +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 <0KNC00K01RA1TH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 13:25:13 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00CLGRA0BF70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 13:25:13 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PJPCdt007299 for ; Sat, 25 Jul 2009 12:25:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNC00400R6GEV00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:25:12 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNC0023JR9ZK510@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:25:12 -0700 (PDT) Date: Sat, 25 Jul 2009 12:25:11 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: Chris Pickett Cc: Korn Shell 93 integration/migration project discussion , Alan Coopersmith , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <4A6B5C17.2000909@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4850 Chris Pickett wrote: > On 7/25/09, Garrett D'Amore wrote: > >> Chris Pickett wrote: >> >> >>> On 7/25/09, Garrett D'Amore wrote: >>> >>> >>> >>>> My main concern here is the integration of manual page functionality >>>> >> into >> >>>> the commands themselves. I see both benefits and costs. The benefit is >>>> that the documentation is more likely to match the actual command. But >>>> >> part >> >>>> of the cost is a much higher cost to perform localization for these, and >>>> (depending on implementation) a potentially larger minimum size of the >>>> binaries. (I'm assuming for the moment that the documentation is stored >>>> >> in >> >>>> the binary, and the command is doing more than just executing some >>>> >> pipeline >> >>>> to access the manual content from /usr/share/man or whatever.) >>>> >>>> Personally, I think --man, --html and --nroff and such is a dangerous >>>> precedent to set. >>>> >>>> >>>> >>> What about --help and --version? Do you object to those options, too? >>> Would you drop your concerns if Roland would rename --man to >>> --extended-help? >>> >>> >>> >> When the --man output really is a manual page, I still object. It doesn't >> matter what you call it -- the problem is that we have two copies of the >> same information, the on-line manual page and the bits in the binary. >> >> Actually, if --man were to generate an actual man page by reading the man >> text from the on-disk file that is formatted by man(1) itself, then I would >> probably answer all (or very nearly so) of my concerns about this. >> > > If you would've ever researched the implementation you would come to > the conclusion that this is not possible. The same string used for > argument parsing is the same string used to generate the help, > version, man, nroff and html output. There is no space wasted > *anywhere*. > That's unfortunate... there is a lot of text in the output from some of this man output... its pretty obvious to me that the "SEE ALSO", "IMPLEMENTATION", and "DESCRIPTION" sections of the --man output are not actually *required* for option parsing. It may be that the text is embedded in a way that makes it difficult or impossible to remove. At some level that's an implementation detail, but it is one that the committee will have to consider when the vote is taken. But I also think you might well be wrong. For example, consider the following in builtins.c (for sleep): *const* *char* sh_optsleep [] = 1478 "[-1c?\n@(#)$Id: sleep (AT&T Research) 1999-04-07 $\n]" 1479 USAGE_LICENSE 1480 "[+NAME?sleep - suspend execution for an interval]" 1481 "[+DESCRIPTION?\bsleep\b suspends execution for at least the time specified " 1482 "by \aseconds\a or until a \bSIGALRM\b signal is received. " 1483 "\aseconds\a can be specified as a floating point number but the " 1484 "actual granularity depends on the underlying system, normally " 1485 "around 1 millisecond.]" 1486 "\n" 1487 "\nseconds\n" 1488 "\n" 1489 "[+EXIT STATUS?]{" 1490 "[+0?The execution was successfully suspended for at least \atime\a " 1491 "seconds, or a \bSIGALRM\b signal was received.]" 1492 "[+>0?An error occurred.]" 1493 "}" 1494 "[+SEE ALSO?\btime\b(1), \bwait\b(1)]" 1495 ; Why couldn't I have simply #ifdef'd out lines 1479-1488, and 1489-1494? None of that text looks (at least to me) to be intrinsically necessary as part of the options parser. > >> If you read my architectural concerns about this, then you'd understand why >> I have problems with it. (Right now it looks like I'm very much in the >> minority >> > > Yes, you are. > Well, we'll see. I'll be satisfied if the the committee takes a vote, no matter how the vote turns out. At least then I'll know that the concerns I've raised were properly considered. It may be that the concerns are no longer relevant, in which case I'll happily stand aside. So my requesting a vote on the issue (and pointing out the concerns) should not be a problem for folks convinced that none of my concerns matter anymore and that the other PSARC members will see the foolishness of my thinking. > >> -- maybe a minority of one on this -- but if so then a vote on the >> issue will be easy for the project team to achieve, and costs nobody >> anything except me -- and the cost to me is that I'll have to write the >> resulting opinion.) >> > > Where and when is such a vote done? Where can I vote? > On Wednesday at the PSARC meeting. Only regular PSARC members can vote. - Garrett From gdamore@sun.com Sat Jul 25 12:29:31 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PJTVV9020225 for ; Sat, 25 Jul 2009 12:29:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6PJTVsv015107 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 12:29:31 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNC00001RH7FM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:29:31 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC00LQ0RH7T310@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:29:31 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PJTV0F007352 for ; Sat, 25 Jul 2009 12:29:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNC00400R6GEV00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:29:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNC002EARH6K510@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:29:30 -0700 (PDT) Date: Sat, 25 Jul 2009 12:29:30 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B5C17.2000909@sun.com> Sender: Garrett.Damore@sun.com To: Chris Pickett Cc: Korn Shell 93 integration/migration project discussion , Alan Coopersmith , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <4A6B5D1A.3060100@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 5326 Garrett D'Amore wrote: > Chris Pickett wrote: >> On 7/25/09, Garrett D'Amore wrote: >> >>> Chris Pickett wrote: >>> >>> >>>> On 7/25/09, Garrett D'Amore wrote: >>>> >>>> >>>> >>>>> My main concern here is the integration of manual page functionality >>>>> >>> into >>> >>>>> the commands themselves. I see both benefits and costs. The >>>>> benefit is >>>>> that the documentation is more likely to match the actual >>>>> command. But >>>>> >>> part >>> >>>>> of the cost is a much higher cost to perform localization for >>>>> these, and >>>>> (depending on implementation) a potentially larger minimum size of >>>>> the >>>>> binaries. (I'm assuming for the moment that the documentation is >>>>> stored >>>>> >>> in >>> >>>>> the binary, and the command is doing more than just executing some >>>>> >>> pipeline >>> >>>>> to access the manual content from /usr/share/man or whatever.) >>>>> >>>>> Personally, I think --man, --html and --nroff and such is a >>>>> dangerous >>>>> precedent to set. >>>>> >>>>> >>>>> >>>> What about --help and --version? Do you object to those options, too? >>>> Would you drop your concerns if Roland would rename --man to >>>> --extended-help? >>>> >>>> >>>> >>> When the --man output really is a manual page, I still object. It >>> doesn't >>> matter what you call it -- the problem is that we have two copies of >>> the >>> same information, the on-line manual page and the bits in the binary. >>> >>> Actually, if --man were to generate an actual man page by reading >>> the man >>> text from the on-disk file that is formatted by man(1) itself, then >>> I would >>> probably answer all (or very nearly so) of my concerns about this. >>> >> >> If you would've ever researched the implementation you would come to >> the conclusion that this is not possible. The same string used for >> argument parsing is the same string used to generate the help, >> version, man, nroff and html output. There is no space wasted >> *anywhere*. >> > > That's unfortunate... there is a lot of text in the output from some > of this man output... its pretty obvious to me that the "SEE ALSO", > "IMPLEMENTATION", and "DESCRIPTION" sections of the --man output are > not actually *required* for option parsing. It may be that the text > is embedded in a way that makes it difficult or impossible to remove. > At some level that's an implementation detail, but it is one that the > committee will have to consider when the vote is taken. > > But I also think you might well be wrong. For example, consider the > following in builtins.c (for sleep): > > *const* *char* sh_optsleep > [] = > 1478 "[-1c?\n@(#)$Id: sleep (AT&T Research) 1999-04-07 $\n]" > 1479 USAGE_LICENSE > > 1480 "[+NAME?sleep - suspend execution for an interval]" > 1481 "[+DESCRIPTION?\bsleep\b suspends execution for at least the > time specified " > 1482 "by \aseconds\a or until a \bSIGALRM\b signal is received. " > 1483 "\aseconds\a can be specified as a floating point number > but the " > 1484 "actual granularity depends on the underlying system, > normally " > 1485 "around 1 millisecond.]" > 1486 "\n" > 1487 "\nseconds\n" > 1488 "\n" > 1489 "[+EXIT STATUS?]{" > 1490 "[+0?The execution was successfully suspended for at least > \atime\a " > 1491 "seconds, or a \bSIGALRM\b signal was received.]" > 1492 "[+>0?An error occurred.]" > 1493 "}" > 1494 "[+SEE ALSO?\btime\b(1), \bwait\b(1)]" > 1495 ; > > > Why couldn't I have simply #ifdef'd out lines 1479-1488, and 1489-1494? Sorry, I mistakenly used the wrong numbers... I meant to say 1479-1485. I *suspect* that the parser needs lines 1486 thru 1488. (Although I've not read the parser code to be certain.) - Garrett > > None of that text looks (at least to me) to be intrinsically necessary > as part of the options parser. > >> >>> If you read my architectural concerns about this, then you'd >>> understand why >>> I have problems with it. (Right now it looks like I'm very much in the >>> minority >>> >> >> Yes, you are. >> > > Well, we'll see. I'll be satisfied if the the committee takes a vote, > no matter how the vote turns out. At least then I'll know that the > concerns I've raised were properly considered. It may be that the > concerns are no longer relevant, in which case I'll happily stand > aside. So my requesting a vote on the issue (and pointing out the > concerns) should not be a problem for folks convinced that none of my > concerns matter anymore and that the other PSARC members will see the > foolishness of my thinking. > >> >>> -- maybe a minority of one on this -- but if so then a vote on the >>> issue will be easy for the project team to achieve, and costs nobody >>> anything except me -- and the cost to me is that I'll have to write the >>> resulting opinion.) >>> >> >> Where and when is such a vote done? Where can I vote? >> > > > On Wednesday at the PSARC meeting. Only regular PSARC members can vote. > > - Garrett > From gdamore@sun.com Sat Jul 25 12:34:34 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PJYX5Z020262 for ; Sat, 25 Jul 2009 12:34:33 -0700 (PDT) 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 n6PJYLgU027263 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 03:34:32 +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 <0KNC00I03RPJS300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:34:31 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC004J0RPJL9D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:34:31 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PJYVhq002340 for ; Sat, 25 Jul 2009 12:34:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNC00400RGFQ100@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:34:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNC0074PRPIN490@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 12:34:30 -0700 (PDT) Date: Sat, 25 Jul 2009 12:34:30 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B5D1A.3060100@sun.com> Sender: Garrett.Damore@sun.com To: Chris Pickett Cc: Korn Shell 93 integration/migration project discussion , Alan Coopersmith , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <4A6B5E46.9080508@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <4A6B5D1A.3060100@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7709 Here's another counter-example to the claim that no space is "wasted" and that it isn't possible to #ifdef out this text: 1670 *const* *char* sh_optulimit [] = 1671 "[-1c?@(#)$Id: ulimit (AT&T Research) 2003-06-21 $\n]" 1672 USAGE_LICENSE 1673 "[+NAME?ulimit - set or display resource limits]" 1674 "[+DESCRIPTION?\bulimit\b sets or displays resource limits. These " 1675 "limits apply to the current process and to each child process " 1676 "created after the resource limit has been set. If \alimit\a " 1677 "is specified, the resource limit is set, otherwise, its current value " 1678 "is displayed on standard output.]" 1679 "[+?Increasing the limit for a resource usually requires special privileges. " 1680 "Some systems allow you to lower resource limits and later increase " 1681 "them. These are called soft limits. Once a hard limit is " 1682 "set the resource can not be increased.]" 1683 "[+?Different systems allow you to specify different resources and some " 1684 "restrict how much you can raise the limit of the resource.]" 1685 "[+?The value of \alimit\a depends on the unit of the resource listed " 1686 "for each resource. In addition, \alimit\a can be \bunlimited\b " 1687 "to indicate no limit for that resource.]" 1688 "[+?If you do not specify \b-H\b or \b-S\b, then \b-S\b is used for " 1689 "listing and both \b-S\b and \b-H\b are used for setting resources.]" 1690 "[+?If you do not specify any resource, the default is \b-f\b.]" 1691 "[H?A hard limit is set or displayed.]" 1692 "[S?A soft limit is set or displayed.]" 1693 "[a?Displays all current resource limits]" 1694 "\flimits\f" 1695 "\n" 1696 "\n[limit]\n" 1697 "\n" 1698 "[+EXIT STATUS?]{" 1699 "[+0?Successful completion.]" 1700 "[+>0?A request for a higher limit was rejected or an error occurred.]" 1701 "}" In the line above, I submit that only lines 1691 thru 1697 are necessary. The rest could probably easily be #ifdef'd out. - Garrett Garrett D'Amore wrote: > Garrett D'Amore wrote: >> Chris Pickett wrote: >>> On 7/25/09, Garrett D'Amore wrote: >>> >>>> Chris Pickett wrote: >>>> >>>> >>>>> On 7/25/09, Garrett D'Amore wrote: >>>>> >>>>> >>>>> >>>>>> My main concern here is the integration of manual page functionality >>>>>> >>>> into >>>> >>>>>> the commands themselves. I see both benefits and costs. The >>>>>> benefit is >>>>>> that the documentation is more likely to match the actual >>>>>> command. But >>>>>> >>>> part >>>> >>>>>> of the cost is a much higher cost to perform localization for >>>>>> these, and >>>>>> (depending on implementation) a potentially larger minimum size >>>>>> of the >>>>>> binaries. (I'm assuming for the moment that the documentation is >>>>>> stored >>>>>> >>>> in >>>> >>>>>> the binary, and the command is doing more than just executing some >>>>>> >>>> pipeline >>>> >>>>>> to access the manual content from /usr/share/man or whatever.) >>>>>> >>>>>> Personally, I think --man, --html and --nroff and such is a >>>>>> dangerous >>>>>> precedent to set. >>>>>> >>>>>> >>>>>> >>>>> What about --help and --version? Do you object to those options, too? >>>>> Would you drop your concerns if Roland would rename --man to >>>>> --extended-help? >>>>> >>>>> >>>>> >>>> When the --man output really is a manual page, I still object. It >>>> doesn't >>>> matter what you call it -- the problem is that we have two copies >>>> of the >>>> same information, the on-line manual page and the bits in the binary. >>>> >>>> Actually, if --man were to generate an actual man page by reading >>>> the man >>>> text from the on-disk file that is formatted by man(1) itself, then >>>> I would >>>> probably answer all (or very nearly so) of my concerns about this. >>>> >>> >>> If you would've ever researched the implementation you would come to >>> the conclusion that this is not possible. The same string used for >>> argument parsing is the same string used to generate the help, >>> version, man, nroff and html output. There is no space wasted >>> *anywhere*. >>> >> >> That's unfortunate... there is a lot of text in the output from some >> of this man output... its pretty obvious to me that the "SEE ALSO", >> "IMPLEMENTATION", and "DESCRIPTION" sections of the --man output are >> not actually *required* for option parsing. It may be that the text >> is embedded in a way that makes it difficult or impossible to >> remove. At some level that's an implementation detail, but it is one >> that the committee will have to consider when the vote is taken. >> >> But I also think you might well be wrong. For example, consider the >> following in builtins.c (for sleep): >> >> *const* *char* sh_optsleep >> [] = >> 1478 "[-1c?\n@(#)$Id: sleep (AT&T Research) 1999-04-07 $\n]" >> 1479 USAGE_LICENSE >> >> 1480 "[+NAME?sleep - suspend execution for an interval]" >> 1481 "[+DESCRIPTION?\bsleep\b suspends execution for at least the >> time specified " >> 1482 "by \aseconds\a or until a \bSIGALRM\b signal is received. " >> 1483 "\aseconds\a can be specified as a floating point number >> but the " >> 1484 "actual granularity depends on the underlying system, >> normally " >> 1485 "around 1 millisecond.]" >> 1486 "\n" >> 1487 "\nseconds\n" >> 1488 "\n" >> 1489 "[+EXIT STATUS?]{" >> 1490 "[+0?The execution was successfully suspended for at least >> \atime\a " >> 1491 "seconds, or a \bSIGALRM\b signal was received.]" >> 1492 "[+>0?An error occurred.]" >> 1493 "}" >> 1494 "[+SEE ALSO?\btime\b(1), \bwait\b(1)]" >> 1495 ; >> >> >> Why couldn't I have simply #ifdef'd out lines 1479-1488, and 1489-1494? > > Sorry, I mistakenly used the wrong numbers... I meant to say > 1479-1485. I *suspect* that the parser needs lines 1486 thru 1488. > (Although I've not read the parser code to be certain.) > > - Garrett >> >> None of that text looks (at least to me) to be intrinsically >> necessary as part of the options parser. >> >>> >>>> If you read my architectural concerns about this, then you'd >>>> understand why >>>> I have problems with it. (Right now it looks like I'm very much in >>>> the >>>> minority >>>> >>> >>> Yes, you are. >>> >> >> Well, we'll see. I'll be satisfied if the the committee takes a >> vote, no matter how the vote turns out. At least then I'll know that >> the concerns I've raised were properly considered. It may be that >> the concerns are no longer relevant, in which case I'll happily stand >> aside. So my requesting a vote on the issue (and pointing out the >> concerns) should not be a problem for folks convinced that none of my >> concerns matter anymore and that the other PSARC members will see the >> foolishness of my thinking. >> >>> >>>> -- maybe a minority of one on this -- but if so then a vote on the >>>> issue will be easy for the project team to achieve, and costs nobody >>>> anything except me -- and the cost to me is that I'll have to write >>>> the >>>> resulting opinion.) >>>> >>> >>> Where and when is such a vote done? Where can I vote? >>> >> >> >> On Wednesday at the PSARC meeting. Only regular PSARC members can vote. >> >> - Garrett >> > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Sat Jul 25 13:03:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PK3bIi020809 for ; Sat, 25 Jul 2009 13:03:38 -0700 (PDT) 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 n6PK3axW011316 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 04:03:37 +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 <0KNC00K01T20TM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 13:03:36 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNC0047NT1ZKUE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 13:03:35 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6PJvBeG025391 for ; Sat, 25 Jul 2009 20:03:35 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-49615 for PSARC-ext@sun.com; Sat, 25 Jul 2009 20:03:34 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-5563377 for PSARC-ext@sun.com; Sat, 25 Jul 2009 20:03:28 +0000 (Z) Received: from relay04-haj2.antispameurope.com ([83.246.65.54] [83.246.65.54]) by relay1i.sun.com with ESMTP id BT-MMP-6026948 for PSARC-ext@sun.com; Sat, 25 Jul 2009 20:02:53 +0000 (Z) Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 7E6315EC102; Sat, 25 Jul 2009 22:02:47 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id C6C795EC0EE; Sat, 25 Jul 2009 22:02:46 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n6PK2knJ000569; Sat, 25 Jul 2009 22:02:46 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 22:02:46 +0200 Date: Sat, 25 Jul 2009 22:02:33 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: pkchris@users.sourceforge.net, ksh93-integration-discuss@opensolaris.org Cc: PSARC-ext@sun.com, busybox-dev@opensolaris.org, Alan.Coopersmith@sun.com Message-id: <4a6b64d9.t+U+sPjmqtv/jT2k%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 5.019sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 25 Jul 2009 20:02:46.0029 (UTC) FILETIME=[E0A423D0:01CA0D62] Status: RO Content-Length: 1025 Chris Pickett wrote: > > Personally, I think --man, --html and --nroff and such is a dangerous > > precedent to set. > > What about --help and --version? Do you object to those options, too? > Would you drop your concerns if Roland would rename --man to > --extended-help? -help is nothing new. It was introduced in 1981 by a UNIX clone called "UNOS". All my software implements -help since 1982 ;-) I habe no problem with -man in case that the related text is inside a shared library that my be omitted for smaller platforms like WLAN Base stations or DSL routers. If yourse the program still needs to work otherwise in case that the library with the documentation text is not present. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From johnsonnenschein@gmail.com Sat Jul 25 15:34:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6PMYMjt022127 for ; Sat, 25 Jul 2009 15:34:23 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6PMYJIg004011; Sat, 25 Jul 2009 23:34:20 +0100 (BST) 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 <0KND00I05018U300@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 16:34:20 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00EUW018F780@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 16:34:20 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PMUaCq005539; Sat, 25 Jul 2009 22:34:19 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-170819; Sat, 25 Jul 2009 22:34:19 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-8354246; Sat, 25 Jul 2009 22:34:18 +0000 (Z) Received: from rv-out-0708.google.com ([209.85.198.243] [209.85.198.243]) by relay1i.sun.com with ESMTP id BT-MMP-9321561; Sat, 25 Jul 2009 22:34:18 +0000 (Z) Received: by rv-out-0708.google.com with SMTP id f25so617769rvb.8 for ; Sat, 25 Jul 2009 15:34:12 -0700 (PDT) Received: by 10.140.200.13 with SMTP id x13mr3139091rvf.71.1248561251995; Sat, 25 Jul 2009 15:34:11 -0700 (PDT) Received: from ?192.168.1.105? (76-10-188-43.dsl.teksavvy.com [76.10.188.43]) by mx.google.com with ESMTPS id g31sm23101759rvb.6.2009.07.25.15.34.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 15:34:10 -0700 (PDT) Date: Sat, 25 Jul 2009 15:33:56 -0700 From: John Sonnenschein Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6A9FCF.5020100@sun.com> To: "Garrett D'Amore" Cc: Roland Mainz , ksh93-integration-discuss@opensolaris.org, Alan Coopersmith , Busybox development , PSARC-ext@sun.com Message-id: <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.935.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=L9IKxVqmhF7njGjaH/A6nuJfF9W6S7oGQUTR7vq2cGU=; b=E33WRqEdh8U2kPrj+bvo/rkzdPml0qLqAkGNSGETE6kEz0zHbpFd19Wn2zEqFjRdwP 4IK+iPYhceUnc7CYEfjkyby5eDK07/cIuHpnC6WI58b2dogDE3OTn2QnanJ2/DxHZhgW dYyN138Lmq57bQXNYDV194oDYiznmIiwsP43M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=B/UOL0ghNXJWg54Y6LbuBEgwoblgnL25wXnDIjpiTStzCKhfvjCnPbID4d2A6NvfR7 s0i6A9sOM2v8Ao8Db3uYZ8DkTy2h6ViBuz608h1PM/mdUbOUeJbWL1Tk+uGl761un/NX zFaO1TeSJn1UaCuA1UY0gEDiyDcyL6BB6oLAI= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.177sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> Status: RO Content-Length: 10319 I've got a question about this... Whose responsibility is it to update the man pages and --man command then? The people whose jobs it is to update man pages, or the people whose jobs it is to update the command line utility? Basically if a new flag is added in the future for some reason, how will one synchronize the man pages? -JohnS On 24-Jul-09, at 11:01 PM, Garrett D'Amore wrote: > Roland Mainz wrote: >> Garrett D'Amore wrote: >> >>> Alan Coopersmith wrote: >>> >>>> Garrett D'Amore wrote: >>>> >>>>> Personally, I think --man, --html and --nroff and such is a >>>>> dangerous >>>>> precedent to set. I'd rather not have them, and instead rely on >>>>> the >>>>> "man" command to provide this functionality. >>>>> >>>> Isn't it a bit late to raise such a concern, since the precedent >>>> was set >>>> in the long list of previous cases that used AST/ksh93 >>>> implementations? >>>> >>> It might be. I certainly should have raised the issue back then. >>> I'm >>> still not happy about this. >>> >> >> Why ? >> > > I'll explain why further down. > >> >>> There's yet another concern, which is that I've found that man >>> >>> and command --man do not generate the same document. So we know >>> introduce a problem were documentation delivered on the system can >>> be >>> inconsistent. >>> >> >> Erm... no. As said in my other email the "--man" output is >> basically a >> short/terse format and more or less exactly what the "getopts" parser >> sees (it may even be usefull if main documentation and actual code >> are >> out-of-sync (which is currently the case for many commands)). >> > > No, it isn't. (Well, you might have "extra" text in the getopts > parser, but for an example look at the output from sum --help. Its > quite a rich manual page, far beyond the normal getopts kind of > messaging.) > >> >>> I feel really strongly that this was a bad idea. >>> >> >> IMO it was a nice idea - see my other email where this feature >> originated from. >> > > I understand the notion. And for projects that don't have the same > considerations we do, the idea is elegant. But I'll elaborate > further below why I think this idea is *not* a good idea for our > project. >> >>> Strongly enough that >>> I'm contemplating derailing the case. >>> >> >> And what should we do then ? The only thing we can do is to remove it >> from the case materials - removing it from the code can only be done >> globally (e.g. libast) and that really will break existing&&ARC'ed >> parts. >> > > #ifdef SOLARIS ? Seriously, if you want Solaris to adopt these > commands in favor of our current native implementations, then there > has to be some willingness to address architectural issues found on, > or even specific to, Solaris. > > >> [snip] >> >>>> No matter what you multiply $0 by, it's still $0. (We don't >>>> localize man >>>> pages in Solaris. A subset of man pages used to be translated >>>> to Japanese, >>>> but I believe even that is no longer done.) >>>> >>> Really? That comes as a surprise. But we *do* localize commands. >>> >> >> Actually the situation is AFAIK currently that there is not really >> much >> funding for this left and the basic system commands are very low >> priority. That's why I am currently working on getting a rag-tag team >> set-up to get l10n catalogs for the AST commands (e.g. covering ksh93 >> itself and all commands which go through the busybox-like "alias" >> wrapper (including those commands covered by this ARC case)) >> integrated >> (first covering Japanese, Chinese, French and later German, Spanish, >> Russian, Urkainian locales). >> > > That may be the case. However, the your misunderstanding my > argument, at the bottom of this message I'll elaborate further. > >> >>> So >>> does putting --man content in the command suddenly mean that in >>> order to >>> be I18N compliant they have to be localized? That would certainly >>> add >>> to the cost. >>> >> >> I don't understand the connection here: >> 1. "i18n" is "internationalisation", e.g. the support for non-ASCII >> characters&co. and this is fully covered by the new commands (and I >> am >> _very_ picky about this detail). >> > > The point is that it must be possible for the commands to be > localized. While there is no *technical* difference imposed by the > length of the string, the string itself must be localizable. That > means you can't elide handling of this when you localize the rest of > the command, I think. > >> 2. "l10n" means "localistion" and mainly rotates around error >> strings/messages/etc. being provided in non-english languages. > > Yes. > > Now let me break down the architectural problems I have with --man > (and also with --nroff and --troff), as they pertain to Solaris: > > > 1) The commands increase the size of the text segment. Not only > does it add new parsing requirements (you have to at least have > enough code to handle --man, for example), but you also have the > text of the man pages themselves. While you might like to maintain > the fiction that this comes for free, it *is* a fiction. Run sum -- > man or some of the other commands and you'll see content that was > not automatically generated. > > 2) We also have traditional manual pages. On a normal system, the > default installation will include now *two* copies of the manual > page. This is wasted space. > > 3) Worse, the pages can be out of synch with each other. (The sum > man pages are again a good example of this.) Which is correct? > (*Probably* the --man command output.) > > 4) Furthermore, the --man output doesn't reflect standards required > for Sun man pages. For example, there is no > ATTRIBUTES table. > > 5) Some users elect to *remove* manual pages (or not install them) > to save space. We've long offered this choice. However, putting > the man pages in the binary effectively removes this choice from the > user. > > 6) There has historically been different processes for man page > content generation than for software engineering. By putting the > man page content into the binary, you basically wind up skipping the > editorial review (and in many cases creation) of those man pages by > our professional documentation writers and editors. > > 7) The rules for localization of documentation and commands have > historically often been different (based on funding levels, rules > for selling to different locales, and business priorities.) By > putting manual page content hard coded into the documentation, you > wind up creating a locked relationship where the two have to be > localized together, or not at all. This ultimately increases the > cost of localizing a command should such a localization be desired. > (Translators often charge by the word.) > > 8) The teams involved with localization of manual pages vs. commands > have historically been different, and have different costs. I > strongly suspect it costs more to localize a command than it does to > localize documentation. (You have to test the command, and the > translators also need to know more about technical details such as > handling message catalogs.) So if we do decide we need to localize > this stuff in the future, its probably going to cost us more to do > in a binary than it would as an actual document. > > 9) Worse, if we keep *both* the man page and the command text, we > might wind up paying *double* the cost, by translating *both* > versions. > > 10) Whether we want to admit it or not, when many of our core > utilities start doing this, the request is going to be that the rest > of our utilities (e.g. dladm, ifconfig, maybe even the man command > itself!) support --man as well. (I admit at first blush its a nifty > feature, and many users are going to like it, without understanding > or caring about the the ramifications I've listed above.) So saying > that this doesn't set precedent is IMO akin to putting ones fingers > in ones ears and saying LALALALA... If we're going down this road, > then it needs to be an explicit decision rather than something that > happened as an implementation accident. > > Now, all that said I do understand why the AST/ksh93 team has gone > down this road. Indeed, if I was going to deliver an unbundled > project, I might make the same decisions. Many of the above > concerns won't be relevant to David Korn or Glenn Fowler, and this > approach probably *does* solve problems that the upstream cares > about (no need to write actual separate man pages for example). > But they *are* relevant to Sun and the Solaris project. > > Many of the above issues could be handled more cleanly by simply > having --man execute the man command and feed the generated result. > But then, this begs the question, why not just run "man command" > instead of "command --man" ? (Indeed, the first form is more > familiar and requires less typing than the introduced --man content.) > > So with all that said, I believe that its *important* that the > decision to inline man pages into libraries and manual pages be made > *explicitly* by the ARC. I believe (going back and reading over the > previous ARC materials) that this detail was largely unconsidered > during previous ARC cases, and I would like the ARC membership the > change to think on the above points I've made, and make a decision > explicitly. > > With that in mind, I'm derailing this case for a vote, and I'll > write the opinion. Unless you want to provide more answers or > responses to my above points, I don't think any further work is > required from the project team -- we have enough information (I > think) to proceed with a vote on this. > > I will say just one more thing. Where it not for the --man, -- > nroff, and --html options, I think I would unhesitatingly give this > case a +1. I think the rest of the case has a great deal of > technical merit, and I actually would like to see the changes > integrated -- just without manual pages integrated into the binaries. > > -- Garrett > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From carlsonj@workingcode.com Sat Jul 25 17:00:03 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q002db027970 for ; Sat, 25 Jul 2009 17:00:03 -0700 (PDT) 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 n6PNxwHC004451; Sun, 26 Jul 2009 07:59:59 +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 <0KND001053ZYZG00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 16:59:58 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00NX73ZX4610@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 16:59:58 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PNxuNM016913; Sat, 25 Jul 2009 23:59:57 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay42i.sun.com with ESMTP id BT-MMP-959652; Sat, 25 Jul 2009 23:59:56 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-19875760; Sat, 25 Jul 2009 23:59:56 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-2672175; Sat, 25 Jul 2009 23:59:56 +0000 (Z) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n6PNxB2V014660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jul 2009 19:59:14 -0400 (EDT) Date: Sat, 25 Jul 2009 19:59:11 -0400 From: James Carlson Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> To: John Sonnenschein Cc: "Garrett D'Amore" , ksh93-integration-discuss@opensolaris.org, Busybox development , Alan Coopersmith , PSARC-ext@sun.com Message-id: <4A6B9C4F.4090302@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=6 Fuz1=6 Fuz2=6 X-Antispam: No, score=0.0/5.0, scanned in 0.145sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 880 John Sonnenschein wrote: > I've got a question about this... > > Whose responsibility is it to update the man pages and --man command > then? The people whose jobs it is to update man pages, or the people > whose jobs it is to update the command line utility? > > Basically if a new flag is added in the future for some reason, how will > one synchronize the man pages? Usually, that's done by filing a bug against the man pages. The advantage of keeping the documentation separate is that it's in the hands of professional documentation writers, who are able to keep a consistent style across all of the system man pages. I'm with Garrett about the inadvisability of baking man page documentation into executables, but for ksh93-related things, I think that ship has unfortunately sailed. -- James Carlson 42.703N 71.076W From roland.mainz@nrubsig.org Sat Jul 25 17:06:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q06MbJ028098 for ; Sat, 25 Jul 2009 17:06:23 -0700 (PDT) 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 n6Q06Fg6007329; Sun, 26 Jul 2009 08:06:20 +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 <0KND0030B4AH4D00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 17:06:17 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00NFM4AG4630@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 17:06:17 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6PNxoIs008310; Sun, 26 Jul 2009 00:06:16 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-281823; Sun, 26 Jul 2009 00:06:16 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-8492494; Sun, 26 Jul 2009 00:06:14 +0000 (Z) Received: from mail-in-11.arcor-online.net ([151.189.21.51] [151.189.21.51]) by relay1i.sun.com with ESMTP id BT-MMP-6457817; Sun, 26 Jul 2009 00:06:13 +0000 (Z) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mx.arcor.de (Postfix) with ESMTP id 5A488E3982; Sun, 26 Jul 2009 02:06:12 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 3D1D66BFFB; Sun, 26 Jul 2009 02:06:12 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-208-176.pools.arcor-ip.net [94.219.208.176]) by mail-in-05.arcor-online.net (Postfix) with ESMTPS id C20233327F9; Sun, 26 Jul 2009 02:06:10 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6Q067rX000731; Sun, 26 Jul 2009 02:06:07 +0200 (CEST) Date: Sun, 26 Jul 2009 02:06:06 +0200 From: Roland Mainz Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: John Sonnenschein Cc: "Garrett D'Amore" , ksh93-integration-discuss@opensolaris.org, Alan Coopersmith , Busybox development , PSARC-ext@sun.com Message-id: <4A6B9DEE.6AA52908@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-05.arcor-online.net C20233327F9 X-Antispam: No, score=0.0/5.0, scanned in 0.098sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> Status: RO Content-Length: 1879 John Sonnenschein wrote: > On 24-Jul-09, at 11:01 PM, Garrett D'Amore wrote: > > Roland Mainz wrote: > >> Garrett D'Amore wrote: > >>> Alan Coopersmith wrote: [snip] > > I will say just one more thing. Where it not for the --man, -- > > nroff, and --html options, I think I would unhesitatingly give this > > case a +1. I think the rest of the case has a great deal of > > technical merit, and I actually would like to see the changes > > integrated -- just without manual pages integrated into the binaries. > > I've got a question about this... > > Whose responsibility is it to update the man pages and --man command > then? The people whose jobs it is to update man pages, or the people > whose jobs it is to update the command line utility? > > Basically if a new flag is added in the future for some reason, how > will one synchronize the man pages? There are two independent methods ([1] is mandatory, [2] acts as "safeguard"): 1. If we putback into the OS/Net gate and had an ARC case with manual page changes associated with it the putback rules require that we notify the documentation folks at Sun to get the matching manpages updated (e.g. we need to document a milestone/build id when the mapage changes will be completed (which is usually required not to further away than two builds from the code putback build id)) 2. If we add new options we edit the internal string passed to |libast::getopts()| from which the output for --man/--help/--html/--nroff/--version/etc. is generated from. Once the new code runs we have script in place which compares the output against the last output stored in a Subversion tree and warns us if there is a difference in the options part. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From matt@greenviolet.net Sat Jul 25 17:22:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q0M4WM028161 for ; Sat, 25 Jul 2009 17:22:05 -0700 (PDT) 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 n6Q0M21A015128 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 08:22:03 +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 <0KND00F0750PR200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 17:22:01 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00C4550PI110@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 17:22:01 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6Q0F7tm014008 for ; Sun, 26 Jul 2009 00:22:00 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-56996 for PSARC-ext@sun.com; Sun, 26 Jul 2009 00:22:00 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-8513697 for PSARC-ext@sun.com; Sun, 26 Jul 2009 00:21:55 +0000 (Z) Received: from bay0-omc3-s28.bay0.hotmail.com ([65.54.246.228] [65.54.246.228]) by relay1i.sun.com with ESMTP id BT-MMP-3111520 for PSARC-ext@sun.com; Sun, 26 Jul 2009 00:21:55 +0000 (Z) Received: from BAY142-DS4 ([65.55.153.31]) by bay0-omc3-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 17:21:54 -0700 Date: Sat, 25 Jul 2009 17:21:54 -0700 From: Matt Lewandowsky Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold,mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <284568.16368.qm@web30803.mail.mud.yahoo.com> X-Originating-IP: [66.92.7.5] To: Korn Shell 93 integration/migration project discussion Cc: PSARC-ext@sun.com, Busybox development Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Originating-Email: [matt@greenviolet.net] X-Antispam: No, score=-0.2/5.0, scanned in 4.400sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <284568.16368.qm@web30803.mail.mud.yahoo.com> X-OriginalArrivalTime: 26 Jul 2009 00:21:54.0238 (UTC) FILETIME=[14188DE0:01CA0D87] Status: RO Content-Length: 5005 From: "Octave Orgeron" on Saturday, July 25, 2009 12:03 PM: > Why not add an option at compile/configure time to reference the native > man pages for the target OS? That way it's not a Solaris specific feature, > but an option anyone can use on any target platform?? I think that would > be the best compromise. This is my personal preference. There are non-(Open)Solaris environments where this would be useful, as well. (Such environments are not directly applicable to this discussion and will not be gotten into in-depth by me.) It also removes the stigma of "Sun wants to be different for no good reason" (a complaint leveraged against various of Sun's tools for quite a while now) and replaces it with a lesser stigma of "They chose the configuration options to disable these features" (even though it's the same end-result), if the options are removed. Also, Garrett has raised some very valid points that I agree with. Especially about users opting for removing documentation... Regardless of how valid the desire to do it is, the fact remains that there are business customers who have hard requirements of no documentation kept on their production servers. Having the documentation within the binaries themselves will make trying to get newer versions of Solaris into said customer environments a challenge, at best. Logic is useless against these customers, and it's not an issue of disk space. In addition, I have been observing increasing interest in OpenSolaris as an embedded platform. Due to economies and currently available embedded development platforms, these systems may feasibly have less storage space to work with than even the LiveCD. While it is certainly true that you can get, for example, a 4 GB MicroSD card for less than USD$10.00 these days, they're not exactly a viable option for many/most embedded "consumers". And removing documentation on a device you won't ever actually use the documentation on is low hanging fruit. If my math is correct, a full installation of SXCE 117 includes over 155 MB of man pages alone. Granted, it's a small percentage of total space taken by the installation, but it's also not a small amount of text to plop onto a 512 MB device (most of the pages are in /usr/share/man). But duplicating this in the binaries seems silly and a waste of space. If the precedent is set that all commands in ON should be self-documenting, this may preclude the possibility of an OpenSolaris distribution aimed at truly embedded devices for even longer than it appears the wait will be at this time. If it's specified that "just" things from AST are to do this, I have less of an issue with the space. However, I then have an issue with consistency. How would a user know when to use --man? They'd likely be inclined not to bother, since 8 of 10 times it won't work and they'd be typing "man somecommand" anyhow. And, in addition to the system man pages drifting out of sync with the --man output, Garrett had a great point in that Solaris requires additional sections in their man pages that are not required by other operating systems (e.g. attributes). How have other Unixes with similar requirements dealt with this? Do they patch their custom sections into the source at buildtime or something? Or has ksh93 not been that heavily integrated into any others yet? Also, this reeks a bit of feature creep. While --man, --nroff, and --html can potentially be very useful, where will it stop? Will there be an RFE in a year from someone who needs --ps? Then another in a year and a half for --pdf? And another for --xml? Will they be added? Why or why not? Does anyone have a magic crystal ball to find out? I foresee these options as a slippery slope. Saying right now that "no one will ever need that" indicates that you've not spent enough time with users and management. ;) Also, my opinion toward "We can't disable --man because it will break the test suite" is: Fix the test suite to accommodate the behavior. I realize that this increases the scope of the test suite, but the option doesn't really make sense (at least on Solaris) and the tests should accommodate the Solaris-friendlier behavior. These are just my thoughts on the matter. Make of them what you will. But if I were voting, I'd be voting against this as it stands. However much the *idea* of --man appeals to me: I don't like the look of precedent; I don't like the "trivial" text segments growing; I don't like user confusion (they get enough of it as it is); I don't like not being able to upgrade customers (see the inflexibility, above, about documentation on public-facing systems); I don't like different content depending on how the man page is accessed (they're certain to diverge over time, plus aforementioned Solaris-specific sections); and, I don't like how Garrett's concerns have been brushed aside. Warmest, --Matt -- Matt Lewandowsky Greenviolet http://greenviolet.net/ From roland.mainz@nrubsig.org Sat Jul 25 17:41:02 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q0f2qm028200 for ; Sat, 25 Jul 2009 17:41:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q0f1PI003275; Sat, 25 Jul 2009 17:41:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND009055WDJQ00@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 18:41:01 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND005EN5WDTF70@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 18:41:01 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6Q0WxJu006578; Sun, 26 Jul 2009 00:41:00 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-960825; Sun, 26 Jul 2009 00:41:00 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-19915160; Sun, 26 Jul 2009 00:40:59 +0000 (Z) Received: from mail-in-07.arcor-online.net ([151.189.21.47] [151.189.21.47]) by relay4i.sun.com with ESMTP id BT-MMP-21556559; Sun, 26 Jul 2009 00:40:59 +0000 (Z) Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mx.arcor.de (Postfix) with ESMTP id 2AB1C3CA2B2; Sun, 26 Jul 2009 02:40:58 +0200 (CEST) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id 0236923DD7D; Sun, 26 Jul 2009 02:40:58 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-208-176.pools.arcor-ip.net [94.219.208.176]) by mail-in-07.arcor-online.net (Postfix) with ESMTPS id 88B083CA1E4; Sun, 26 Jul 2009 02:40:52 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6Q0ene2000739; Sun, 26 Jul 2009 02:40:49 +0200 (CEST) Date: Sun, 26 Jul 2009 02:40:49 +0200 From: Roland Mainz Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Busybox development , Alan Coopersmith , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6BA611.5C05D8F9@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-07.arcor-online.net 88B083CA1E4 X-Antispam: No, score=-0.2/5.0, scanned in 0.318sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> Status: RO Content-Length: 7880 Garrett D'Amore wrote: > Roland Mainz wrote: > > Garrett D'Amore wrote: > >> Alan Coopersmith wrote: > >>> Garrett D'Amore wrote: [snip] > >> There's yet another concern, which is that I've found that man > >> and command --man do not generate the same document. So we know > >> introduce a problem were documentation delivered on the system can be > >> inconsistent. > > > > Erm... no. As said in my other email the "--man" output is basically a > > short/terse format and more or less exactly what the "getopts" parser > > sees (it may even be usefull if main documentation and actual code are > > out-of-sync (which is currently the case for many commands)). > > No, it isn't. (Well, you might have "extra" text in the getopts parser, > but for an example look at the output from sum --help. Its quite a rich > manual page, far beyond the normal getopts kind of messaging.) Right... but it cannot be easily stripped either because there are callbacks tied into the getopts code. Most of this specific getopts stuff (which is an exception (AFAIK the only one beyond "ulimit")) is actually _dynamically_ generated based on the capabilities of the underlying crypto libraries. IMO you hit the worst example of all... ;-( [snip] > > And what should we do then ? The only thing we can do is to remove it > > from the case materials - removing it from the code can only be done > > globally (e.g. libast) and that really will break existing&&ARC'ed > > parts. > > > > #ifdef SOLARIS ? Seriously, if you want Solaris to adopt these commands > in favor of our current native implementations, then there has to be > some willingness to address architectural issues found on, or even > specific to, Solaris. Right... but I also remind you that we try to _avoid_ the history of Solaris's ksh88 which was gradually fork'ed over time with the "best intentions" which later rendered the code incompatible to other ksh88 versions on other Unices and pretty much unmaintainable, too. The ksh93-integration project was then created with the _strong_ intention to _prevent_ this kind of problems to happen _ever_ again, which resulted in several major and unbreakable rules for this project which includes: - WE DO NOT FORK THE CODE - WE DO NOT BREAK THE KSH93 TEST SUITE - THE KSH93 TEST SUITE IS COMPLETELY OFF-LIMITS FOR CHANGES (I am using uppercase here to make it very clear that this project was founded to prevent the history from repeating. Sun unfortunately has a long tradition of shooting itself into it's many feet and when this project was founded we really hoped to prevent these mistakes at least for this project). That's why I am very unhappy about the suggestion to "litter" the code with lots of (IMHO) unneccesary |#ifdef SOLARIS|. It would mean we fork the code, create a huge additional maintaince and testing burden (and testing is already a _pain_, we're now working on the ksh93-integration update2 for more than six month and more than four of them are spend in testing) and make the code (slightly) incompatible. It's only "slightly" for _now_ but I know poeple love precedents and once this is established there is no way to stop the flood anymore. [snip] > > I don't understand the connection here: > > 1. "i18n" is "internationalisation", e.g. the support for non-ASCII > > characters&co. and this is fully covered by the new commands (and I am > > _very_ picky about this detail). > > The point is that it must be possible for the commands to be localized. > While there is no *technical* difference imposed by the length of the > string, the string itself must be localizable. That means you can't > elide handling of this when you localize the rest of the command, I think. Erm... why ? l10n catalogs are always allowed to be sparse. > > 2. "l10n" means "localistion" and mainly rotates around error > > strings/messages/etc. being provided in non-english languages. > > Yes. > > Now let me break down the architectural problems I have with --man (and > also with --nroff and --troff), as they pertain to Solaris: > > 1) The commands increase the size of the text segment. Not only does > it add new parsing requirements (you have to at least have enough code > to handle --man, for example), but you also have the text of the man > pages themselves. While you might like to maintain the fiction that > this comes for free, it *is* a fiction. Run sum --man or some of the > other commands and you'll see content that was not automatically generated. > > 2) We also have traditional manual pages. On a normal system, the > default installation will include now *two* copies of the manual page. > This is wasted space. Actually this is not much "wasted space" since the same string is used for getopts parsing and the "--help" output which you (AFAIK) wish to keep around. > 3) Worse, the pages can be out of synch with each other. (The sum man > pages are again a good example of this.) Which is correct? (*Probably* > the --man command output.) Right... the recent layoffs hit April Chin who was doing the coordination work and her disappearance from Sun wreaked lots of havoc. Even security-related bugs and their patches went "missing" ... the manual page stuff comes at the bottom of that list of mayhem. > 4) Furthermore, the --man output doesn't reflect standards required for > Sun man pages. For example, there is no > ATTRIBUTES table. Again, the output is not intended to be a full manual page. I said that several times (and I am starting to feel ignored). > 5) Some users elect to *remove* manual pages (or not install them) to > save space. We've long offered this choice. However, putting the man > pages in the binary effectively removes this choice from the user. Again, the getopts string is used to create the "--man"+"--help" output. There isn't much wasted space. And the little bit of "extra space" you're describing is more or less "hidden" by the detail that > 6) There has historically been different processes for man page content > generation than for software engineering. By putting the man page > content into the binary, you basically wind up skipping the editorial > review (and in many cases creation) of those man pages by our > professional documentation writers and editors. Again, please read what I wrote. We use the getopts string for this. > 7) The rules for localization of documentation and commands have > historically often been different (based on funding levels, rules for > selling to different locales, and business priorities.) By putting > manual page content hard coded into the documentation, you wind up > creating a locked relationship where the two have to be localized > together, or not at all. This ultimately increases the cost of > localizing a command should such a localization be desired. > (Translators often charge by the word.) Please see above. It is _not_ mandatory to do the localisation for every string. The code explicitly allows sparse catalogs. > 8) The teams involved with localization of manual pages vs. commands > have historically been different, and have different costs. I strongly > suspect it costs more to localize a command than it does to localize > documentation. (You have to test the command, and the translators also > need to know more about technical details such as handling message > catalogs.) So if we do decide we need to localize this stuff in the > future, its probably going to cost us more to do in a binary than it > would as an actual document. See above... > 9) Worse, if we keep *both* the man page and the command text, we might > wind up paying *double* the cost, by translating *both* versions. See above. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz@nrubsig.org Sat Jul 25 17:44:02 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q0i2U5028235 for ; Sat, 25 Jul 2009 17:44:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q0i15D003774 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 17:44:02 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND0090361CVJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 18:44:00 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND005WL61BTF70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 18:44:00 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q0Sk2p005028 for ; Sun, 26 Jul 2009 00:43:59 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-57562 for PSARC-ext@sun.com; Sun, 26 Jul 2009 00:43:59 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-6017857 for PSARC-ext@sun.com; Sun, 26 Jul 2009 00:43:58 +0000 (Z) Received: from mail-in-06.arcor-online.net ([151.189.21.46] [151.189.21.46]) by relay1i.sun.com with ESMTP id BT-MMP-6510472 for PSARC-ext@sun.com; Sun, 26 Jul 2009 00:43:57 +0000 (Z) Received: from mail-in-07-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mx.arcor.de (Postfix) with ESMTP id 9216939A41A; Sun, 26 Jul 2009 02:43:56 +0200 (CEST) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-07-z2.arcor-online.net (Postfix) with ESMTP id 8987F2C712E; Sun, 26 Jul 2009 02:43:56 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-208-176.pools.arcor-ip.net [94.219.208.176]) by mail-in-07.arcor-online.net (Postfix) with ESMTPS id E574A3CA29C; Sun, 26 Jul 2009 02:43:54 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6Q0hqRF000744; Sun, 26 Jul 2009 02:43:52 +0200 (CEST) Date: Sun, 26 Jul 2009 02:43:52 +0200 From: Roland Mainz Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: "I. Szczesniak" Cc: Korn Shell 93 integration/migration project discussion , Busybox development , PSARC-ext@sun.com Message-id: <4A6BA6C8.F52F1863@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-07.arcor-online.net E574A3CA29C X-Antispam: No, score=0.0/5.0, scanned in 0.064sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> Status: RO Content-Length: 1342 "I. Szczesniak" wrote: > On 7/25/09, Garrett D'Amore wrote: > > Roland Mainz wrote: > > > Garrett D'Amore wrote: > > > > Alan Coopersmith wrote: > > > > > Garrett D'Amore wrote: [snip] > > > > Strongly enough that > > > > I'm contemplating derailing the case. > > > > > > And what should we do then ? The only thing we can do is to remove it > > > from the case materials - removing it from the code can only be done > > > globally (e.g. libast) and that really will break existing&&ARC'ed > > > parts. > > > > #ifdef SOLARIS ? > > Are you SERIOUSLY suggesting the project team has to add 2196 #ifdef > SOLARIS statements (45 commands, 4 per option, 20 to strip further > text strings in the getopt template) in the code of libcmd? Erm... technically it may then be easier to |#ifdef SOLARIS ... #else ... #endif| the whole codeblock containg the getopts string... but as said this is something which this project tried to avoid at all cost in the past to prevent that we end-up in the same situation as Solaris ksh88 (which was at the end considered unmaintainable and unsalvageable by the people at Sun who did the maintaince on it). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore@sun.com Sat Jul 25 18:04:50 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q14oIu028729 for ; Sat, 25 Jul 2009 18:04:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q14ndD031019 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 19:04:50 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND00C0D7023F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 19:04:50 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND005XW6ZZTFB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 19:04:48 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q14lLS013687 for ; Sat, 25 Jul 2009 18:04:47 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KND00F006WMBS00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 18:04:47 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KND00BM26ZZ5HE0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 18:04:47 -0700 (PDT) Date: Sat, 25 Jul 2009 18:04:46 -0700 From: "Garrett D'Amore" Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6BA611.5C05D8F9@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Busybox development , Alan Coopersmith , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6BABAE.1060305@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6BA611.5C05D8F9@nrubsig.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 9991 While you talk about implementation issues and details below, I'm unconvinced that my architectural considerations are addressed. It may be that I chose poor examples, but rest assured I chose them at random. Some examination of the code makes me think there are are others that have a lot of content in them. Other replies: * From a end-user's view point, it looks like a man page, it is access with an option called "--man", so how saying that this is not a "replacement" for man pages feels a bit dishonest to me. Indeed, there could be important information in the regular man page, but a user wouldn't think to read that because they'll just --man. How is the end user to know that this isn't the "real" man page. (Or for that matter, which one is the "real" man page?) * On l10n sparse catalogs. I'm sure that it is possible to build sparse catalogs. I'm unsure that this is an accepted practice however, and in markets where l10n is required, having some of the messaging be excluded might require extraordinary measures to have such a waiver. (Then again they might now... I don't know enough about the processes that go into deciding when l10n is needed or not.) Note that these are *business* issues which may face anyone that wants to deliver any commercial product based on OpenSolaris. Of course, if you're only interested in giving your stuff away for free, then such concerns are not likely to be important to you. Thanks. Mostly at this point I'll just wait and see how this pans out during the meeting on Wednesday. Actually, that does bring up one order of business: will you be available for the meeting on Wednesday at 10am PDT? If not, do you want us to take the vote, or would you prefer to reschedule for a week when you can be available? - Garrett Roland Mainz wrote: > Garrett D'Amore wrote: > >> Roland Mainz wrote: >> >>> Garrett D'Amore wrote: >>> >>>> Alan Coopersmith wrote: >>>> >>>>> Garrett D'Amore wrote: >>>>> > [snip] > >>>> There's yet another concern, which is that I've found that man >>>> and command --man do not generate the same document. So we know >>>> introduce a problem were documentation delivered on the system can be >>>> inconsistent. >>>> >>> Erm... no. As said in my other email the "--man" output is basically a >>> short/terse format and more or less exactly what the "getopts" parser >>> sees (it may even be usefull if main documentation and actual code are >>> out-of-sync (which is currently the case for many commands)). >>> >> No, it isn't. (Well, you might have "extra" text in the getopts parser, >> but for an example look at the output from sum --help. Its quite a rich >> manual page, far beyond the normal getopts kind of messaging.) >> > > Right... but it cannot be easily stripped either because there are > callbacks tied into the getopts code. Most of this specific getopts > stuff (which is an exception (AFAIK the only one beyond "ulimit")) is > actually _dynamically_ generated based on the capabilities of the > underlying crypto libraries. IMO you hit the worst example of all... ;-( > > [snip] > >>> And what should we do then ? The only thing we can do is to remove it >>> from the case materials - removing it from the code can only be done >>> globally (e.g. libast) and that really will break existing&&ARC'ed >>> parts. >>> >>> >> #ifdef SOLARIS ? Seriously, if you want Solaris to adopt these commands >> in favor of our current native implementations, then there has to be >> some willingness to address architectural issues found on, or even >> specific to, Solaris. >> > > Right... but I also remind you that we try to _avoid_ the history of > Solaris's ksh88 which was gradually fork'ed over time with the "best > intentions" which later rendered the code incompatible to other ksh88 > versions on other Unices and pretty much unmaintainable, too. The > ksh93-integration project was then created with the _strong_ intention > to _prevent_ this kind of problems to happen _ever_ again, which > resulted in several major and unbreakable rules for this project which > includes: > - WE DO NOT FORK THE CODE > - WE DO NOT BREAK THE KSH93 TEST SUITE > - THE KSH93 TEST SUITE IS COMPLETELY OFF-LIMITS FOR CHANGES > (I am using uppercase here to make it very clear that this project was > founded to prevent the history from repeating. Sun unfortunately has a > long tradition of shooting itself into it's many feet and when this > project was founded we really hoped to prevent these mistakes at least > for this project). > > That's why I am very unhappy about the suggestion to "litter" the code > with lots of (IMHO) unneccesary |#ifdef SOLARIS|. It would mean we fork > the code, create a huge additional maintaince and testing burden (and > testing is already a _pain_, we're now working on the ksh93-integration > update2 for more than six month and more than four of them are spend in > testing) and make the code (slightly) incompatible. It's only "slightly" > for _now_ but I know poeple love precedents and once this is established > there is no way to stop the flood anymore. > > [snip] > >>> I don't understand the connection here: >>> 1. "i18n" is "internationalisation", e.g. the support for non-ASCII >>> characters&co. and this is fully covered by the new commands (and I am >>> _very_ picky about this detail). >>> >> The point is that it must be possible for the commands to be localized. >> While there is no *technical* difference imposed by the length of the >> string, the string itself must be localizable. That means you can't >> elide handling of this when you localize the rest of the command, I think. >> > > Erm... why ? l10n catalogs are always allowed to be sparse. > > >>> 2. "l10n" means "localistion" and mainly rotates around error >>> strings/messages/etc. being provided in non-english languages. >>> >> Yes. >> >> Now let me break down the architectural problems I have with --man (and >> also with --nroff and --troff), as they pertain to Solaris: >> >> 1) The commands increase the size of the text segment. Not only does >> it add new parsing requirements (you have to at least have enough code >> to handle --man, for example), but you also have the text of the man >> pages themselves. While you might like to maintain the fiction that >> this comes for free, it *is* a fiction. Run sum --man or some of the >> other commands and you'll see content that was not automatically generated. >> >> 2) We also have traditional manual pages. On a normal system, the >> default installation will include now *two* copies of the manual page. >> This is wasted space. >> > > Actually this is not much "wasted space" since the same string is used > for getopts parsing and the "--help" output which you (AFAIK) wish to > keep around. > > >> 3) Worse, the pages can be out of synch with each other. (The sum man >> pages are again a good example of this.) Which is correct? (*Probably* >> the --man command output.) >> > > Right... the recent layoffs hit April Chin who was doing the > coordination work and her disappearance from Sun wreaked lots of havoc. > Even security-related bugs and their patches went "missing" ... the > manual page stuff comes at the bottom of that list of mayhem. > > >> 4) Furthermore, the --man output doesn't reflect standards required for >> Sun man pages. For example, there is no >> ATTRIBUTES table. >> > > Again, the output is not intended to be a full manual page. I said that > several times (and I am starting to feel ignored). > > >> 5) Some users elect to *remove* manual pages (or not install them) to >> save space. We've long offered this choice. However, putting the man >> pages in the binary effectively removes this choice from the user. >> > > Again, the getopts string is used to create the "--man"+"--help" output. > There isn't much wasted space. And the little bit of "extra space" > you're describing is more or less "hidden" by the detail that > > >> 6) There has historically been different processes for man page content >> generation than for software engineering. By putting the man page >> content into the binary, you basically wind up skipping the editorial >> review (and in many cases creation) of those man pages by our >> professional documentation writers and editors. >> > > Again, please read what I wrote. We use the getopts string for this. > > >> 7) The rules for localization of documentation and commands have >> historically often been different (based on funding levels, rules for >> selling to different locales, and business priorities.) By putting >> manual page content hard coded into the documentation, you wind up >> creating a locked relationship where the two have to be localized >> together, or not at all. This ultimately increases the cost of >> localizing a command should such a localization be desired. >> (Translators often charge by the word.) >> > > Please see above. It is _not_ mandatory to do the localisation for every > string. The code explicitly allows sparse catalogs. > > >> 8) The teams involved with localization of manual pages vs. commands >> have historically been different, and have different costs. I strongly >> suspect it costs more to localize a command than it does to localize >> documentation. (You have to test the command, and the translators also >> need to know more about technical details such as handling message >> catalogs.) So if we do decide we need to localize this stuff in the >> future, its probably going to cost us more to do in a binary than it >> would as an actual document. >> > > See above... > > >> 9) Worse, if we keep *both* the man page and the command text, we might >> wind up paying *double* the cost, by translating *both* versions. >> > > See above. > > ---- > > Bye, > Roland > > From roland.mainz@nrubsig.org Sat Jul 25 18:16:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q1GloS028775 for ; Sat, 25 Jul 2009 18:16:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q1GkEC034978; Sat, 25 Jul 2009 19:16:46 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND00G037JYLV00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 18:16:46 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00E9G7JXF120@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Jul 2009 18:16:45 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q187wb027396; Sun, 26 Jul 2009 01:16:45 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-961981; Sun, 26 Jul 2009 01:16:45 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-19717962; Sun, 26 Jul 2009 01:16:44 +0000 (Z) Received: from mail-in-01.arcor-online.net ([151.189.21.41] [151.189.21.41]) by relay4i.sun.com with ESMTP id BT-MMP-2757489; Sun, 26 Jul 2009 01:16:44 +0000 (Z) Received: from mail-in-12-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mx.arcor.de (Postfix) with ESMTP id D6BA63326AE; Sun, 26 Jul 2009 03:16:42 +0200 (CEST) Received: from mail-in-13.arcor-online.net (mail-in-13.arcor-online.net [151.189.21.53]) by mail-in-12-z2.arcor-online.net (Postfix) with ESMTP id B89F1279457; Sun, 26 Jul 2009 03:16:42 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-208-176.pools.arcor-ip.net [94.219.208.176]) by mail-in-13.arcor-online.net (Postfix) with ESMTPS id D2B102BACF4; Sun, 26 Jul 2009 03:16:36 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6Q1GXD6000763; Sun, 26 Jul 2009 03:16:34 +0200 (CEST) Date: Sun, 26 Jul 2009 03:16:33 +0200 From: Roland Mainz Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Alan Coopersmith , Busybox development , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6BAE71.D8E03E03@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-13.arcor-online.net D2B102BACF4 X-Antispam: No, score=-0.7/5.0, scanned in 0.175sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> Status: RO Content-Length: 8136 Garrett D'Amore wrote: > Alan Coopersmith wrote: > > Garrett D'Amore wrote: > >> 1) The commands increase the size of the text segment. Not only does > >> it add new parsing requirements (you have to at least have enough code > >> to handle --man, for example), but you also have the text of the man > >> pages themselves. While you might like to maintain the fiction that > >> this comes for free, it *is* a fiction. Run sum --man or some of the > >> other commands and you'll see content that was not automatically generated. > > > > The minimum memory requirement for the release this is integrating into > > is 512Mb. A few k of memory, in a shared library that can be shared amongst > > all processes using it, is far down in the noise. > > This attitude, spread across dozens, or hundreds of projects, is part of > the reason why software still struggles even in the face of Moore's > law. Nobody cares about a few kB, but those kB add up in aggregate. Actually I _do_ care. That's why we came up with the AST-based busybox design - to save memory and disk space _and_ make the commands faster at the same time. The whole stuff should fully scale from 8MB ARM-based machines upto SF25k class machines > >> 2) We also have traditional manual pages. On a normal system, the > >> default installation will include now *two* copies of the manual page. > >> This is wasted space. > > > > We also install commands users never use, drivers for hardware they don't > > have (and could possibly never have), sample audio files they'll never > > listen to, etc. Text that helps them use a command is far more useful > > than any of those. > > Yes, but *two* copies of the text? And in many cases those drivers > *can* be easily removed, as can the audio files. They are > uninstallable. (In fact, I recently pushed a change to delete a 300k > audio file that nobody listens to anymore. The remaining audio files > are much smaller, and *may* be used by various applications or user > configs.) Did you actually notice my comment that it in the mid-term (not long-term but not for the next putback) we may simple generate both the normal manual pages and the getopts strings put into libcmd/libshell/libbusybox from a DocBook/XML master file ? That was actually my "truce offer" (e.g. let this case pass as-is and then let me work in _peace_ on the DocBook/XML--->getopts XSLT stylesheet stuff (as already said this puts a huge strain on my resources but I would be willing to push this as a priority project)) ... and I'm very very unhappy that this was completely ignored and moved forward and de-railed the case (which will now likely lead to a wishdrawl of the case) ... > >> 3) Worse, the pages can be out of synch with each other. (The sum man > >> pages are again a good example of this.) Which is correct? (*Probably* > >> the --man command output.) > > > > This documentation is less likely to be out of sync with the implementation > > than the traditional man page. That's an improvement to the architecture, > > making sure the user always has at least a correct, if less detailed, source > > of documentation of the options. It will also always document the version > > the user is using - I've seen far too many questions on OpenSolaris e-mail > > and IRC from users confused because their PATH & MANPATH don't match and > > they're seeing /usr/gnu man pages but running /usr/bin commands, or vice versa. > > I agree that this is likely to be an improvement (although it turns out > that the documentation in the command still has to be maintained.) Does > that mean we abandon traditional man pages? No, that was _never_ intended. The idea was simply to re-use some of the information which is already present in the "getopts" string and format it a bit like a ASCII rendering of a man page (I'm still stunned that we have so many emails about this). > >> 4) Furthermore, the --man output doesn't reflect standards required for > >> Sun man pages. For example, there is no > >> ATTRIBUTES table. > > > > That's a good reason why there should also be a traditional man page, and > > --man shouldn't replace it, just supplement it. > > Your response here conflicts with your response to point #3 above. > Either we have one canonical copy of the documentation that should > always be correct and maintained, or we risk having the two copies get > out of sync or become inaccurate. Which should it be? The out-of-sync can never be avoided since this stuff is done in two seperate departments within Sun. The the man-like ASCII rendering and the output for "--help" is obviously _always_ in sync because it uses exactly the same information as the |getopts()| function uses for the actual parsing but we have two "safeguards" in place to make sure that the real manual page is updated (the current large lag was caused by the lay-off of April Chin and the resulting havoc). > >> 5) Some users elect to *remove* manual pages (or not install them) to > >> save space. We've long offered this choice. However, putting the man > >> pages in the binary effectively removes this choice from the user. > > > > That choice was added when we shipped workstations with 105Mb hard disks. > > That choice makes no sense on today's computers and decreases system > > usability. Many of the install options added for 105Mb hard disks will > > be gone in the installer for the Solaris release this integrates to, since > > they make no sense in the day of 1Tb hard disks costing $100, and even > > embedded systems, like the cell phone in my pocket, having many times the > > disk space of that 105Mb SPARCstation 1. > > > > I seem to recall we are also struggling to find room on the LiveCD. You realise that the new code actually _saves_ space on the LiveCD ? > Space constraints are *not* a thing of the past. Right... on the other side an ISO9660 CDROM has (Jörg may correct me) a block size of 2048 bytes and that's much longer than the largest builtin strings we pass to |getopts()| > This attitude -- memory is cheap so it doesn't matter -- is why systems > that should be fully capable of performing the same basic tasks we did 5 > years ago, are now no longer able to boot an operating system even > though the end user is really just interested in doing the same basic task. I agree with you. However this is only a disk footprint concern - the strings are in read-only memory, shared between processes (unlike the current versions of the utilities who do _not_ share their strings) and are paged-in on demand like normal code. This is a _huge_ improvement over the _current_ situation. > Yes, I believe in tight code. Yes I believe memory should still be > treated as a precious resource. No, I don't think it is unreasonable to > ask to be able to use an operating system with 128 MB of RAM. I agree. And the current code works on an 8MB ARM-based embedded system. > As far as I'm concerned, this "fight" is the "good fight", and I'll > stand my ground on it. I may well be overruled, but I refused to just > take the easy and lazy path of considering system resources an > infinitely wasteable resource. Technically I agree with you that the resources should be saved as much as possible. But.... we're doing exactly that with our work and now get punished for it. [snip] > > Translators don't have to translate every string in the application. > > Since when? I thought that pretty much every human interaction had to > be l10n'd in order to be qualified as localized. This is the first time > I've heard of "partially" localizing an application. Are there any > other precedents for this? Yes, AFAIK many of the applications shipped with Solaris use "sparse catalogs" or simply none (because there is no funding or the funding only covered the application's main windows but not a far-away option window hiddent behind lots of menu items). Please ask in i18n-discuss@opensolaris.org ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From johnsonnenschein@gmail.com Sat Jul 25 19:23:54 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q2Nsmf029383 for ; Sat, 25 Jul 2009 19:23:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q2NsNB028588; Sat, 25 Jul 2009 19:23:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND00L01ANU3W00@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 20:23:54 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00EAWANT0V40@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 20:23:53 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q2Nrkq016640; Sun, 26 Jul 2009 02:23:53 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-60232; Sun, 26 Jul 2009 02:23:09 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-6095189; Sun, 26 Jul 2009 02:23:08 +0000 (Z) Received: from mail-px0-f201.google.com ([209.85.216.201] [209.85.216.201]) by relay1i.sun.com with ESMTP id BT-MMP-6687845; Sun, 26 Jul 2009 02:20:08 +0000 (Z) Received: by pxi39 with SMTP id 39so28361pxi.30 for ; Sat, 25 Jul 2009 19:19:39 -0700 (PDT) Received: by 10.114.178.14 with SMTP id a14mr7279418waf.15.1248574779765; Sat, 25 Jul 2009 19:19:39 -0700 (PDT) Received: from ?192.168.1.110? (76-10-188-43.dsl.teksavvy.com [76.10.188.43]) by mx.google.com with ESMTPS id f21sm13466732rvb.8.2009.07.25.19.19.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 19:19:39 -0700 (PDT) Date: Sat, 25 Jul 2009 19:19:37 -0700 From: John Sonnenschein Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B9C4F.4090302@workingcode.com> To: James Carlson Cc: "Garrett D'Amore" , ksh93-integration-discuss@opensolaris.org, Busybox development , Alan Coopersmith , PSARC-ext@sun.com Message-id: <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.935.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=WnIrcs5q5ut6xLO3v6ksOm1+zLnXBq/b42PtM9Kqmyo=; b=rIOaDQjZThSmfFVsNweEBrIFa5z5bWktkHJVaX9BX87NFKWGo+TxSaImjxPpa4CaaF k7Bil68pjuklH9pM+YVklKui7KRuDGvBRz/i090CDJfNJO6tZjVTt84Tg8jQfRYjk8/q O9547x+bi4/Nqkq1NhC3Zrx4rpAzzczCkgW9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=GqA6Gs/8EpUcm100pjbpgRN6Lh+Ro0w+CwO8EDx6s9q1jmeQVtWzGqVZPEFzCHjzJe L2xF/ikLw+1JRDdHSAMWA9SedTH2bB3SqkZp1hLFOg4reOnqtMEp98z6zq1Le1lIVGFf J4p3dmx+udPquNac0QwABHMsi1TccmeQHWbWs= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.060sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> Status: RO Content-Length: 1121 On 25-Jul-09, at 4:59 PM, James Carlson wrote: > John Sonnenschein wrote: >> I've got a question about this... >> Whose responsibility is it to update the man pages and --man >> command then? The people whose jobs it is to update man pages, or >> the people whose jobs it is to update the command line utility? >> Basically if a new flag is added in the future for some reason, how >> will one synchronize the man pages? > > Usually, that's done by filing a bug against the man pages. > > The advantage of keeping the documentation separate is that it's in > the hands of professional documentation writers, who are able to > keep a consistent style across all of the system man pages. > > I'm with Garrett about the inadvisability of baking man page > documentation into executables, but for ksh93-related things, I > think that ship has unfortunately sailed. Sure but for the sake of argument if we have some tools that have -- man and also man pages, does that mean that the docs people will be putting back to ON, or will there be a desynchronization between the man pages and the --man pages ? From gsf@research.att.com Sat Jul 25 20:37:44 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q3binM003104 for ; Sat, 25 Jul 2009 20:37:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q3biI6016269; Sat, 25 Jul 2009 20:37:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND00601E2W5X00@nwk-avmta-2.sfbay.sun.com>; Sat, 25 Jul 2009 20:37:44 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00CZZE2VI540@nwk-avmta-2.sfbay.sun.com>; Sat, 25 Jul 2009 20:37:43 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6Q3ECO9004964; Sun, 26 Jul 2009 03:37:43 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-179117; Sun, 26 Jul 2009 03:37:43 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-40467; Sun, 26 Jul 2009 03:37:41 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-6817747; Sun, 26 Jul 2009 03:35:36 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id 503158CE6; Sat, 25 Jul 2009 23:35:23 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6Q3ZNo9017329; Sat, 25 Jul 2009 23:35:23 -0400 Date: Sat, 25 Jul 2009 23:35:23 -0400 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: Alan.Coopersmith@sun.com, ksh93-integration-discuss@opensolaris.org Cc: busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <200907260335.n6Q3ZNo9017329@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.084sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> Status: RO Content-Length: 256 could some kind soul figure out how to clean up the reply address for this thread so that I (we) only get one copy of each message I'm currently getting at least 4 of each message and I'm sure I have missed at least one tidbit of valuable info thanks From gsf@research.att.com Sat Jul 25 21:14:18 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q4EHvt003697 for ; Sat, 25 Jul 2009 21:14:18 -0700 (PDT) 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 n6Q4EAuU028049; Sun, 26 Jul 2009 12:14:15 +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 <0KND00B55FRPV900@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:14:13 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00EHPFMT0VB0@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:11:17 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6Q4BGbf028959; Sun, 26 Jul 2009 04:11:16 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-288442; Sun, 26 Jul 2009 04:11:16 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-6364101; Sun, 26 Jul 2009 04:11:16 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-3522115; Sun, 26 Jul 2009 04:09:24 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-blue.research.att.com (Postfix) with ESMTP id BF9EBF0CE5; Sun, 26 Jul 2009 00:09:11 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6Q49BRW017860; Sun, 26 Jul 2009 00:09:11 -0400 Date: Sun, 26 Jul 2009 00:09:11 -0400 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: Alan.Coopersmith@sun.com, ksh93-integration-discuss@opensolaris.org Cc: busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <200907260409.n6Q49BRW017860@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.206sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> Status: RO Content-Length: 916 re concerns about libast::optget() string out of sync with .1 man page I mentioned this in a previous post but it must have gotten lost amidst the volume of posts: the separate ksh93 sh.1 man page is an exception rather than the rule for ast section 1 utilities in almost all other cases the optget() usage string *is* the man page src, and we have no intention of ever maintaining separate .1 man pages, save the traditional exceptions for the long ones like sh(1) if there are concerns about maintaining separate optget() usage strings and .1 text files for ast commands on solaris, then I recommend generating the man page from the --nroff output; this generation step would be a place to add solaris specific tags; something like astcommand --nroff solaris-maintained-man-additions as input to a script that generates the solaris man page text file -- Glenn Fowler -- at&t Research, Florham Park NJ -- From gsf@research.att.com Sat Jul 25 21:19:10 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q4J90W003713 for ; Sat, 25 Jul 2009 21:19:09 -0700 (PDT) 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 n6Q4IqUt029637; Sun, 26 Jul 2009 12:19:06 +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 <0KND00D07FZT4A00@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:19:05 -0600 (MDT) 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 <0KND00EAXFZS0SC0@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:19:04 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q4FqHO015679; Sun, 26 Jul 2009 04:19:04 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-63450; Sun, 26 Jul 2009 04:19:04 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-6376484; Sun, 26 Jul 2009 04:19:03 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-6891924; Sun, 26 Jul 2009 04:18:32 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id ED07A92E2; Sun, 26 Jul 2009 00:18:26 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6Q4IQXT018024; Sun, 26 Jul 2009 00:18:26 -0400 Date: Sun, 26 Jul 2009 00:18:26 -0400 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: Alan.Coopersmith@sun.com, ksh93-integration-discuss@opensolaris.org Cc: busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <200907260418.n6Q4IQXT018024@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.053sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> Status: RO Content-Length: 601 re eliding portions of libast::optget() usage strings via #ifdef SOLARIS or whatever the optget() usage string contains: (1) information required for short and long options, and proper rendering of diagnostics for option errors (2) version, author and copyright information (3) optional callback hooks for runtime generated information (4) other text to produce an acceptable man page all but (4) are required for proper operation of ast utilities omit any of (1)(2)(3) and at minimum the upstream can no longer vouch for utility behavior -- Glenn Fowler -- at&t Research, Florham Park NJ -- From gsf@research.att.com Sat Jul 25 21:20:54 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q4KsuS003727 for ; Sat, 25 Jul 2009 21:20:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q4KrAU015741; Sat, 25 Jul 2009 21:20:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND00D03G2TD100@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:20:53 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00EF9G2T0SC0@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:20:53 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q4CtkE027003; Sun, 26 Jul 2009 04:20:52 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay42i.sun.com with ESMTP id BT-MMP-967370; Sun, 26 Jul 2009 04:20:52 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-20012810; Sun, 26 Jul 2009 04:20:52 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay4i.sun.com with ESMTP id BT-MMP-2973679; Sun, 26 Jul 2009 04:20:52 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-blue.research.att.com (Postfix) with ESMTP id EF6BEF0CDA; Sat, 25 Jul 2009 23:49:31 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6Q3nVXd017537; Sat, 25 Jul 2009 23:49:31 -0400 Date: Sat, 25 Jul 2009 23:49:31 -0400 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: Alan.Coopersmith@sun.com, ksh93-integration-discuss@opensolaris.org Cc: busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <200907260349.n6Q3nVXd017537@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.163sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> Status: RO Content-Length: 998 I understand the "sparse message catalog" problem to be that an ast optget usage string would be treated as one string in the message catalog however, this is not how libast::optget() interfaces with the underlying message catalogs almost all of the l10n strings in ast src are arguments to libast::error() or libast::optget() the error() strings are basically printf-style strings that are used as keys into the message catalog an ast layer is provided to map the strings to integral indices for native message catalog apis that require indices optget() breaks down the usage string into smaller message catalog strings the --keys option lists the message catalog strings in C-style "..." strings, one per line e.g., sum --keys 2>&1 | wc shows 88 message catalog strings for a total of ~6K bytes for the C locale note that the long option names are also subject to l10n for portability the C locale names are visible in all locales -- Glenn Fowler -- at&t Research, Florham Park NJ -- From gdamore@sun.com Sat Jul 25 21:45:24 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q4jO1x003806 for ; Sat, 25 Jul 2009 21:45:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q4jMaI021338 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 21:45:24 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND0090XH7NTU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:45:23 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00CFKH7MI160@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:45:22 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q4jMG3017495 for ; Sat, 25 Jul 2009 21:45:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KND00600GVF3500@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:45:22 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KND008NJH7LMK80@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:45:22 -0700 (PDT) Date: Sat, 25 Jul 2009 21:45:21 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <200907260349.n6Q3nVXd017537@penguin.research.att.com> Sender: Garrett.Damore@sun.com To: Glenn Fowler Cc: Alan.Coopersmith@sun.com, ksh93-integration-discuss@opensolaris.org, busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6BDF61.6050508@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> <200907260349.n6Q3nVXd017537@penguin.research.att.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1790 Glenn Fowler wrote: > I understand the "sparse message catalog" problem to be > that an ast optget usage string would be treated as > one string in the message catalog > No, what I meant by this is whether or not all output messages are translated as part of the process of localization. I think normally commands have *all* of their messages translated. My fear is that by putting the man pages in line in the binary, it increases the cost of localizing these commands. The response made by others was that it would be possible to elide the translations for the man pages, giving a "sparse" message catalog. (In retrospect this language is not fully accurate -- what is meant is a sparse localization.) Now, I'm not sure about precedent for this, and whether in a given situation waiving the localization for part of a command would be acceptable. - Garrett > however, this is not how libast::optget() interfaces with > the underlying message catalogs > > almost all of the l10n strings in ast src are > arguments to libast::error() or libast::optget() > > the error() strings are basically printf-style > strings that are used as keys into the message catalog > > an ast layer is provided to map the strings to integral > indices for native message catalog apis that require indices > > optget() breaks down the usage string into smaller > message catalog strings > > the --keys option lists the message catalog strings > in C-style "..." strings, one per line > > e.g., > sum --keys 2>&1 | wc > shows 88 message catalog strings for a total of ~6K bytes > for the C locale > > note that the long option names are also subject to l10n > for portability the C locale names are visible in all locales > > -- Glenn Fowler -- at&t Research, Florham Park NJ -- > > From gdamore@sun.com Sat Jul 25 21:47:56 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q4ltZt003820 for ; Sat, 25 Jul 2009 21:47:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q4lrVu047611 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Jul 2009 22:47:55 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND0090BHBSZM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:47:52 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00CI8HBLHT60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:47:45 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q4ljEv017525 for ; Sat, 25 Jul 2009 21:47:45 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KND00700HBH4T00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:47:45 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KND008THHBKMK80@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 21:47:45 -0700 (PDT) Date: Sat, 25 Jul 2009 21:47:44 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <200907260409.n6Q49BRW017860@penguin.research.att.com> Sender: Garrett.Damore@sun.com To: Glenn Fowler Cc: Alan.Coopersmith@sun.com, ksh93-integration-discuss@opensolaris.org, busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6BDFF0.8000500@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> <200907260409.n6Q49BRW017860@penguin.research.att.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1548 Glenn Fowler wrote: > re concerns about libast::optget() string out of sync with .1 man page > > I mentioned this in a previous post but it must have gotten lost > amidst the volume of posts: the separate ksh93 sh.1 man page is an > exception rather than the rule for ast section 1 utilities > Right, this was my understanding of what the "upstream" does. However it does *not* match the way we manage documentation in Solaris. > in almost all other cases the optget() usage string *is* the man page src, > and we have no intention of ever maintaining separate .1 man pages, > save the traditional exceptions for the long ones like sh(1) > > if there are concerns about maintaining separate optget() usage strings > and .1 text files for ast commands on solaris, then I recommend > generating the man page from the --nroff output; this generation step > would be a place to add solaris specific tags; something like > > astcommand --nroff > solaris-maintained-man-additions > > as input to a script that generates the solaris man page text file > This is a possibility, although there are still unanswered concerns about this. At least one of these is that it totally short-cuts the professional writers, and our "standards" for man pages. (For example, on Solaris, man pages include information about interface stability. This is probably meaningless to the ksh93 upstream project, but it *is* an important architectural consideration for Solaris.) - Garrett > -- Glenn Fowler -- at&t Research, Florham Park NJ -- > > From roland.mainz@nrubsig.org Sat Jul 25 21:54:32 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q4sWPl004110 for ; Sat, 25 Jul 2009 21:54:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6Q4sWB0007414; Sat, 25 Jul 2009 21:54:32 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KND00G03HMWRX00@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:54:32 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00EYHHMV0PE0@brm-avmta-1.central.sun.com>; Sat, 25 Jul 2009 22:54:32 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6Q4oDFF027528; Sun, 26 Jul 2009 04:54:31 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-181316; Sun, 26 Jul 2009 04:52:31 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-6425159; Sun, 26 Jul 2009 04:52:30 +0000 (Z) Received: from mail-in-07.arcor-online.net ([151.189.21.47] [151.189.21.47]) by relay1i.sun.com with ESMTP id BT-MMP-9953878; Sun, 26 Jul 2009 04:52:30 +0000 (Z) Received: from mail-in-02-z2.arcor-online.net (mail-in-02-z2.arcor-online.net [151.189.8.14]) by mx.arcor.de (Postfix) with ESMTP id CB8CE3CA296; Sun, 26 Jul 2009 06:52:28 +0200 (CEST) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-02-z2.arcor-online.net (Postfix) with ESMTP id B81AC11414E; Sun, 26 Jul 2009 06:52:28 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-208-176.pools.arcor-ip.net [94.219.208.176]) by mail-in-07.arcor-online.net (Postfix) with ESMTPS id 463003CA296; Sun, 26 Jul 2009 06:52:27 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6Q4qNBh000802; Sun, 26 Jul 2009 06:52:23 +0200 (CEST) Date: Sun, 26 Jul 2009 06:52:23 +0200 From: Roland Mainz Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: John Sonnenschein Cc: James Carlson , ksh93-integration-discuss@opensolaris.org, Alan Coopersmith , Busybox development , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <4A6BE107.47F65A19@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-07.arcor-online.net 463003CA296 X-Antispam: No, score=0.0/5.0, scanned in 0.238sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> Status: RO Content-Length: 2464 John Sonnenschein wrote: > On 25-Jul-09, at 4:59 PM, James Carlson wrote: > > John Sonnenschein wrote: > >> I've got a question about this... > >> Whose responsibility is it to update the man pages and --man > >> command then? The people whose jobs it is to update man pages, or > >> the people whose jobs it is to update the command line utility? > >> Basically if a new flag is added in the future for some reason, how > >> will one synchronize the man pages? > > > > Usually, that's done by filing a bug against the man pages. > > > > The advantage of keeping the documentation separate is that it's in > > the hands of professional documentation writers, who are able to > > keep a consistent style across all of the system man pages. > > > > I'm with Garrett about the inadvisability of baking man page > > documentation into executables, but for ksh93-related things, I > > think that ship has unfortunately sailed. > > Sure but for the sake of argument if we have some tools that have -- > man and also man pages, does that mean that the docs people will be > putting back to ON, Erm... why should the documentation people do putback into OS/Net ? The strings used by getopts are used for argument parsing and are - as "nice side-effect" - reused to generate the output for --help, --version, --man etc. > or will there be a desynchronization between the > man pages and the --man pages ? They _may_ be out-of-sync shortly after code putback if we add new options to the |getopts()| string until the documentation folks caught up with the code changes. But as I am trying to say over and over again (and I am starting to feel _ignored_) that the output for --help, --man etc. is generated from the getopts string template used for argument parsing. This string is there to "drive" the argument parsing and is absolutely the wrong place for Solaris-specific edits. We have a real, seperate and maintained manual page for that purpose ([1]). [1]=(And as said _several_ times that we could use a DocBook/XML manual page as master source file shared between documentation and code folks in the future from which both the Solaris manpage and the getopts string can be generated from (this would eliminate all the "manpages out-of-sync" concerns described in this thread)) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore@Sun.COM Sat Jul 25 22:03:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6Q53MJb004340 for ; Sat, 25 Jul 2009 22:03:22 -0700 (PDT) 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 n6Q53IVA017491 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 13:03:21 +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 <0KND00B03I1LGN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 22:03:21 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND008PGI1IU020@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 22:03:20 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6Q53IFG017772 for ; Sat, 25 Jul 2009 22:03:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KND00200HRT1F00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 22:03:18 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KND00H89I1H58F0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 25 Jul 2009 22:03:18 -0700 (PDT) Date: Sat, 25 Jul 2009 22:03:17 -0700 From: "Garrett D'Amore" Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6BE107.47F65A19@nrubsig.org> Sender: Garrett.Damore@Sun.COM To: Roland Mainz Cc: John Sonnenschein , James Carlson , ksh93-integration-discuss@opensolaris.org, Alan Coopersmith , Busybox development , PSARC-ext@Sun.COM Message-id: <4A6BE395.9060108@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> <4A6BE107.47F65A19@nrubsig.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3610 Roland Mainz wrote: > John Sonnenschein wrote: > >> On 25-Jul-09, at 4:59 PM, James Carlson wrote: >> >>> John Sonnenschein wrote: >>> >>>> I've got a question about this... >>>> Whose responsibility is it to update the man pages and --man >>>> command then? The people whose jobs it is to update man pages, or >>>> the people whose jobs it is to update the command line utility? >>>> Basically if a new flag is added in the future for some reason, how >>>> will one synchronize the man pages? >>>> >>> Usually, that's done by filing a bug against the man pages. >>> >>> The advantage of keeping the documentation separate is that it's in >>> the hands of professional documentation writers, who are able to >>> keep a consistent style across all of the system man pages. >>> >>> I'm with Garrett about the inadvisability of baking man page >>> documentation into executables, but for ksh93-related things, I >>> think that ship has unfortunately sailed. >>> >> Sure but for the sake of argument if we have some tools that have -- >> man and also man pages, does that mean that the docs people will be >> putting back to ON, >> > > Erm... why should the documentation people do putback into OS/Net ? The > strings used by getopts are used for argument parsing and are - as "nice > side-effect" - reused to generate the output for --help, --version, > --man etc. > I have no objections to --version, --help. My concerns relate to --man, --nroff, and --html. > >> or will there be a desynchronization between the >> man pages and the --man pages ? >> > > They _may_ be out-of-sync shortly after code putback if we add new > options to the |getopts()| string until the documentation folks caught > up with the code changes. But as I am trying to say over and over again > (and I am starting to feel _ignored_) that the output for --help, --man > etc. is generated from the getopts string template used for argument > parsing. This string is there to "drive" the argument parsing and is > absolutely the wrong place for Solaris-specific edits. We have a real, > seperate and maintained manual page for that purpose ([1]). > Apparently the upstream disagrees with you. They (well Glenn) in fact *recommend* that the man page generated automatically from the --nroff output. > [1]=(And as said _several_ times that we could use a DocBook/XML manual > page as master source file shared between documentation and code folks > in the future from which both the Solaris manpage and the getopts string > can be generated from (this would eliminate all the "manpages > out-of-sync" concerns described in this thread)) > That helps address some, but not all, of the concerns. You still wind up with the situation of two physical copies of the documentation on the media. This approach also seems not to match what the upstream suppliers seem to be saying... I rather strongly suspect that in the end we will be faced with one of two choices: 1) fork the code base and do what we feel is right for Solaris, or 2) accept the upstream's view of how documentation should be produced and delivered to end-users, even though it doesn't match historical precedent for Solaris, or what (at least some of us) we believe is the right way to do this for Solaris Neither of those decisions are wonderful ones, but the fact is that this is a situation where we can't achieve all of our desires. So it will be up to us (and the ARC) to decide which ones are more important. Which is why a vote is necessary. - Garrett > ---- > > Bye, > Roland > > From piochjennifer@googlemail.com Sun Jul 26 06:44:44 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QDiiZ8016017 for ; Sun, 26 Jul 2009 06:44:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QDiiuv028468 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 06:44:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00C0166JEP00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 07:44:43 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00IFM66JTZ90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 07:44:43 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6QDihBh000497 for ; Sun, 26 Jul 2009 13:44:43 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay44i.sun.com with ESMTP id BT-MMP-466051 for PSARC-ext@sun.com; Sun, 26 Jul 2009 13:44:42 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-20764255 for PSARC-ext@sun.com; Sun, 26 Jul 2009 13:44:39 +0000 (Z) Received: from wf-out-1314.google.com ([209.85.200.171] [209.85.200.171]) by relay4i.sun.com with ESMTP id BT-MMP-22117421 for PSARC-ext@sun.com; Sun, 26 Jul 2009 13:44:39 +0000 (Z) Received: by wf-out-1314.google.com with SMTP id 28so693614wff.17 for ; Sun, 26 Jul 2009 06:44:38 -0700 (PDT) Received: by 10.142.155.13 with SMTP id c13mr736296wfe.326.1248615878867; Sun, 26 Jul 2009 06:44:38 -0700 (PDT) Date: Sun, 26 Jul 2009 15:44:38 +0200 From: Jennifer Pioch Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B5C17.2000909@sun.com> To: Korn Shell 93 integration/migration project discussion Cc: Chris Pickett , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S/9CHjESH9Nl7BCmZOV8ggDBIv5fqnp0t/OBNzbFQeQ=; b=KZs8bM9MJHQtGG6DZFKCGpEPBts9XPN3jjSuRy78m+FD+5j9YLtiwHw5hcPCvwCTe/ ZC/nuoWUTy6eWUzRi8u7vnOZ1EGeLCw8XyzLa2XZkkJj8BBYi/00uj3kKhjavYnhCnUt ugGvqDfgVkNAX9I5pumsugpZekJtpvsNfrUHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Fk3XC/ECk9RH8bxMj55Kecehkqp9yBrVAE3HS/A/utRxdVs3QtE56W+q9CtqPgJaGX vwSpSnGlAG4Hsd3EZyqM3rG/7wm6XdjFhFMLJf6+pD9TGpRbBUf+j/c5rM8bbccFMn1Q /ZT3Ss4TJvnmWfO9M295SYfI+UYcCL4cR03Ls= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 3.143sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> Status: RO Content-Length: 149 > On Wednesday at the PSARC meeting. Only regular PSARC members can vote. Who elected the PSARC members? Jenny -- Jennifer Pioch, Uni Frankfurt From piochjennifer@googlemail.com Sun Jul 26 06:46:29 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QDkSdj016029 for ; Sun, 26 Jul 2009 06:46:28 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6QDkRs5016057 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 14:46:27 +0100 (BST) 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 <0KNE00C0169FO900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 07:46:27 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00ION69ETZ90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 07:46:26 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6QDkQ7r000784 for ; Sun, 26 Jul 2009 13:46:26 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-198099 for PSARC-ext@sun.com; Sun, 26 Jul 2009 13:46:26 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-9836989 for PSARC-ext@sun.com; Sun, 26 Jul 2009 13:46:20 +0000 (Z) Received: from wf-out-1314.google.com ([209.85.200.170] [209.85.200.170]) by relay1i.sun.com with ESMTP id BT-MMP-4503849 for PSARC-ext@sun.com; Sun, 26 Jul 2009 13:42:55 +0000 (Z) Received: by wf-out-1314.google.com with SMTP id 28so693465wff.17 for ; Sun, 26 Jul 2009 06:42:21 -0700 (PDT) Received: by 10.142.154.14 with SMTP id b14mr753455wfe.160.1248615741573; Sun, 26 Jul 2009 06:42:21 -0700 (PDT) Date: Sun, 26 Jul 2009 15:42:21 +0200 From: Jennifer Pioch Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6BE395.9060108@sun.com> To: Korn Shell 93 integration/migration project discussion Cc: Roland Mainz , James Carlson , Busybox development , PSARC-ext@sun.com, John Sonnenschein Message-id: <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eG9R87GWFSOz5P6bqKCzR911gPhuf6OChNKc4ryxEJM=; b=Pf3E78mzS5dWTducp6vW0ewNYWtBL3IjV1oIG5uJU0B7LwfIlqk+L8NotBq9Dv+A2C ZhXmKD/5m9G0adZ9m6jVjqPrUE0vdyoxGiJOZ6BNhX/iqA4o5xRgj3Yv8JhR2vNBXj0D 2T67zrwqd0m2B1t/k6MtvIUzmqEwAytILbn6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=erUIuMReV7JojDTX7pInxtHM3i7NnQYrJRYg35t8NAYaP+H8BjvO+Eg+oW+evrQOeq PqhEk/isnkDwCpHmHAvF6MxEz8q6ge8w342ge0t2BmoDa7sLV8qAHzWW5sxiFQ8cyBzA hDXkI7PC77wadh0cwpwKDFjJQ2n0VefeknVjE= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 4.144sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> <4A6BE107.47F65A19@nrubsig.org> <4A6BE395.9060108@sun.com> Status: RO Content-Length: 3771 On 7/26/09, Garrett D'Amore wrote: > Roland Mainz wrote: > > > John Sonnenschein wrote: > > > > > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote: > > > > > > > > > > John Sonnenschein wrote: > > > > > > > > > > > > > I've got a question about this... > > > > > Whose responsibility is it to update the man pages and --man > > > > > command then? The people whose jobs it is to update man pages, or > > > > > the people whose jobs it is to update the command line utility? > > > > > Basically if a new flag is added in the future for some reason, how > > > > > will one synchronize the man pages? > > > > > > > > > > > > > > Usually, that's done by filing a bug against the man pages. > > > > > > > > The advantage of keeping the documentation separate is that it's in > > > > the hands of professional documentation writers, who are able to > > > > keep a consistent style across all of the system man pages. > > > > > > > > I'm with Garrett about the inadvisability of baking man page > > > > documentation into executables, but for ksh93-related things, I > > > > think that ship has unfortunately sailed. > > > > > > > > > > > Sure but for the sake of argument if we have some tools that have -- > > > man and also man pages, does that mean that the docs people will be > > > putting back to ON, > > > > > > > > > > Erm... why should the documentation people do putback into OS/Net ? The > > strings used by getopts are used for argument parsing and are - as "nice > > side-effect" - reused to generate the output for --help, --version, > > --man etc. > > > > > > I have no objections to --version, --help. My concerns relate to --man, > --nroff, and --html. > > > > > > > > > or will there be a desynchronization between the > > > man pages and the --man pages ? > > > > > > > > > > They _may_ be out-of-sync shortly after code putback if we add new > > options to the |getopts()| string until the documentation folks caught > > up with the code changes. But as I am trying to say over and over again > > (and I am starting to feel _ignored_) that the output for --help, --man > > etc. is generated from the getopts string template used for argument > > parsing. This string is there to "drive" the argument parsing and is > > absolutely the wrong place for Solaris-specific edits. We have a real, > > seperate and maintained manual page for that purpose ([1]). > > > > > > Apparently the upstream disagrees with you. They (well Glenn) in fact > *recommend* that the man page generated automatically from the --nroff > output. > > > > [1]=(And as said _several_ times that we could use a DocBook/XML manual > > page as master source file shared between documentation and code folks > > in the future from which both the Solaris manpage and the getopts string > > can be generated from (this would eliminate all the "manpages > > out-of-sync" concerns described in this thread)) > > > > > > That helps address some, but not all, of the concerns. You still wind up > with the situation of two physical copies of the documentation on the media. > > This approach also seems not to match what the upstream suppliers seem to > be saying... > > I rather strongly suspect that in the end we will be faced with one of two > choices: > > 1) fork the code base and do what we feel is right for Solaris, or Didn't you read what Roland wrote about the project rules? > in several major and unbreakable rules for this project which > includes: > - WE DO NOT FORK THE CODE > - WE DO NOT BREAK THE KSH93 TEST SUITE > - THE KSH93 TEST SUITE IS COMPLETELY OFF-LIMITS FOR CHANGES If you are forking the code with such unnecessary changes I will NO LONGER CONTRIBUTE to this or any other Opensolaris.org project. Jenny -- Jennifer Pioch, Uni Frankfurt From carlsonj@workingcode.com Sun Jul 26 07:42:43 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QEghvv016575 for ; Sun, 26 Jul 2009 07:42:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QEgglW062930 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 08:42:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00B018V6LZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 07:42:42 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00ARV8V5RW70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 07:42:42 -0700 (PDT) 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 n6QEgf59027412 for ; Sun, 26 Jul 2009 14:42:41 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay43i.sun.com with ESMTP id BT-MMP-987792 for PSARC-ext@sun.com; Sun, 26 Jul 2009 14:42:41 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-20713933 for PSARC-ext@sun.com; Sun, 26 Jul 2009 14:42:41 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-9874501 for PSARC-ext@sun.com; Sun, 26 Jul 2009 14:42:40 +0000 (Z) Received: from [192.168.254.178] (dhcp-178 [192.168.254.178]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n6QEg4KA021050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Jul 2009 10:42:05 -0400 (EDT) Date: Sun, 26 Jul 2009 10:42:20 -0400 From: James Carlson Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> To: Jennifer Pioch Cc: Korn Shell 93 integration/migration project discussion , "PSARC-ext@sun.com" , "busybox-dev@opensolaris.org" Message-id: MIME-version: 1.0 X-Mailer: iPod Mail (5H11a) Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-sonic.net-Metrics: carlson 1117; Body=4 Fuz1=4 Fuz2=4 X-Antispam: No, score=0.0/5.0, scanned in 0.238sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> Status: RO Content-Length: 593 On Jul 26, 2009, at 9:44 AM, Jennifer Pioch wrote: >> On Wednesday at the PSARC meeting. Only regular PSARC members can >> vote. > > Who elected the PSARC members? Nobody. Sun's CTO founded the ARC 19 years ago. Since then, new members have been added by having the existing members nominate new ones, primarily from the ranks of the interns. If you're interested, all it takes is volunteering, time, and a bit of demonstrated clue. It's a technical position, not an administrative one, so "elections" would, I expect, have very poor results. From gdamore@sun.com Sun Jul 26 08:51:57 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QFpuQE020232 for ; Sun, 26 Jul 2009 08:51:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QFpuhA002416 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 08:51:56 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00901C2KU900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 08:51:56 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE008PQC2K0410@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 08:51:56 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QFpufj029172 for ; Sun, 26 Jul 2009 08:51:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNE00600C14TJ00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 08:51:56 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNE00LKYC2JNLD0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 08:51:56 -0700 (PDT) Date: Sun, 26 Jul 2009 08:51:55 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> Sender: Garrett.Damore@sun.com To: Jennifer Pioch Cc: Korn Shell 93 integration/migration project discussion , Chris Pickett , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <4A6C7B9B.3040906@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 395 Jennifer Pioch wrote: >> On Wednesday at the PSARC meeting. Only regular PSARC members can vote. >> > > Who elected the PSARC members? > > Jenny > I'm not sure about the first round, but PSARC members are selected by other PSARC members after first serving an internship. They are selected on the basis of having broad architectural vision and technical leadership. - Garrett From gdamore@sun.com Sun Jul 26 09:01:03 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QG13r3020708 for ; Sun, 26 Jul 2009 09:01:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QG13px029053 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 09:01:03 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00I05CHQMF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:01:02 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00AZNCHES190@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:01:02 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QG0o8G029335 for ; Sun, 26 Jul 2009 09:00:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNE00800CC51100@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:00:50 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNE00LG8CHDNLE0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:00:50 -0700 (PDT) Date: Sun, 26 Jul 2009 09:00:49 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> Sender: Garrett.Damore@sun.com To: Jennifer Pioch Cc: Korn Shell 93 integration/migration project discussion , Roland Mainz , James Carlson , Busybox development , PSARC-ext@sun.com, John Sonnenschein Message-id: <4A6C7DB1.1050805@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> <4A6BE107.47F65A19@nrubsig.org> <4A6BE395.9060108@sun.com> <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1897 Jennifer Pioch wrote: > On 7/26/09, Garrett D'Amore wrote: > > > Didn't you read what Roland wrote about the project rules? > >> in several major and unbreakable rules for this project which >> includes: >> - WE DO NOT FORK THE CODE >> - WE DO NOT BREAK THE KSH93 TEST SUITE >> - THE KSH93 TEST SUITE IS COMPLETELY OFF-LIMITS FOR CHANGES >> > > If you are forking the code with such unnecessary changes I will NO > LONGER CONTRIBUTE to this or any other Opensolaris.org project. > Roland and I had a long conversation about this. Generally such a hardline does not work with projects that are part ON. I can think of no other project that is part of ON and has a hard and fast rule such as this. If such a rule was desired, then the project should probably have remained outside of ON (perhaps as SFW). All of which is to say that forking the code from the upstream is not to be taken lightly. But neither is it an absolute requirement that code stay 100% true to the upstream. The upstream projects will often have different goals from the OpenSolaris project, and reasonable people can disagree. When an impasse is reached, each project must do what it deems is best for itself. Furthermore, there can be cases where a support engineer may make changes to the code base in order to fix an urgent bug -- such a change is not necessarily guaranteed to receive Roland's (or any other particular individual's) approval, nor is it guaranteed to be synchronized with the upstream. These are just the rules of engagement for ON. I really hope that nobody leaves the project over an issue like this, but it is important to understand the ROE -- it would be very unfortunate if (whether as part of this case or as part of any other case) such a change took place and people upset to the point of quitting the project over it. - Garrett From joshhurst@gmail.com Sun Jul 26 09:23:01 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QGN0f6020794 for ; Sun, 26 Jul 2009 09:23:01 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6QGMwmG019924 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 17:22:59 +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 <0KNE00G03DIBGY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:22:59 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE008VBDIB0490@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:22:59 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6QGJ6BR022393 for ; Sun, 26 Jul 2009 16:22:58 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-203238 for PSARC-ext@sun.com; Sun, 26 Jul 2009 16:22:58 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-10156074 for PSARC-ext@sun.com; Sun, 26 Jul 2009 16:22:53 +0000 (Z) Received: from mail-qy0-f190.google.com ([209.85.221.190] [209.85.221.190]) by relay1i.sun.com with ESMTP id BT-MMP-11181556 for PSARC-ext@sun.com; Sun, 26 Jul 2009 16:21:37 +0000 (Z) Received: by qyk28 with SMTP id 28so153255qyk.30 for ; Sun, 26 Jul 2009 09:21:18 -0700 (PDT) Received: by 10.220.75.211 with SMTP id z19mr3198471vcj.43.1248625278443; Sun, 26 Jul 2009 09:21:18 -0700 (PDT) Date: Sun, 26 Jul 2009 18:21:18 +0200 From: Josh Hurst Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> To: Korn Shell 93 integration/migration project discussion , Roland Mainz Cc: John Sonnenschein , PSARC-ext@sun.com, James Carlson , Busybox development Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fFYGWbGFr1ODXz0Wxk6gGPl99qLYREgSccx6I4fDFsY=; b=ii+BFdyvXjZE+1nCMkTm2KwbnAv3wyEnMxGIKiK16G4uXs1MXMNtx9TtCwReqlMjvz 5RvYYkEKcukJtYeUCW5gbvfPO4d5anN8ko+KrHl6jftQBsy2hw7oWyrLgqWMCjgQWU9l LyztYABlPuCLTqJYoOQWPYTpsi9WjkuM+N7KY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mi2pYRpGUyToY2JCyAdbxWPyPbXt3UUIgkkoJImBGWp4JQoTJCQKVZHYeOKqKhSHBC h5ZSzMPzJiq9YXWLr75OW47mZoBtF8T0XgkaTd7QCLO7ctYDyfaRAJcfNQoADOQHaA8k LpDlc5i8pVq9u7OveFnIW4QkhWbc/QYjipCUE= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 4.353sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> <4A6BE107.47F65A19@nrubsig.org> <4A6BE395.9060108@sun.com> <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> Status: RO Content-Length: 4247 On 7/26/09, Jennifer Pioch wrote: > On 7/26/09, Garrett D'Amore wrote: > > Roland Mainz wrote: > > > > > John Sonnenschein wrote: > > > > > > > > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote: > > > > > > > > > > > > > John Sonnenschein wrote: > > > > > > > > > > > > > > > > I've got a question about this... > > > > > > Whose responsibility is it to update the man pages and --man > > > > > > command then? The people whose jobs it is to update man pages, or > > > > > > the people whose jobs it is to update the command line utility? > > > > > > Basically if a new flag is added in the future for some reason, how > > > > > > will one synchronize the man pages? > > > > > > > > > > > > > > > > > Usually, that's done by filing a bug against the man pages. > > > > > > > > > > The advantage of keeping the documentation separate is that it's in > > > > > the hands of professional documentation writers, who are able to > > > > > keep a consistent style across all of the system man pages. > > > > > > > > > > I'm with Garrett about the inadvisability of baking man page > > > > > documentation into executables, but for ksh93-related things, I > > > > > think that ship has unfortunately sailed. > > > > > > > > > > > > > > Sure but for the sake of argument if we have some tools that have -- > > > > man and also man pages, does that mean that the docs people will be > > > > putting back to ON, > > > > > > > > > > > > > > Erm... why should the documentation people do putback into OS/Net ? The > > > strings used by getopts are used for argument parsing and are - as "nice > > > side-effect" - reused to generate the output for --help, --version, > > > --man etc. > > > > > > > > > > I have no objections to --version, --help. My concerns relate to --man, > > --nroff, and --html. > > > > > > > > > > > > > > or will there be a desynchronization between the > > > > man pages and the --man pages ? > > > > > > > > > > > > > > They _may_ be out-of-sync shortly after code putback if we add new > > > options to the |getopts()| string until the documentation folks caught > > > up with the code changes. But as I am trying to say over and over again > > > (and I am starting to feel _ignored_) that the output for --help, --man > > > etc. is generated from the getopts string template used for argument > > > parsing. This string is there to "drive" the argument parsing and is > > > absolutely the wrong place for Solaris-specific edits. We have a real, > > > seperate and maintained manual page for that purpose ([1]). > > > > > > > > > > Apparently the upstream disagrees with you. They (well Glenn) in fact > > *recommend* that the man page generated automatically from the --nroff > > output. > > > > > > > [1]=(And as said _several_ times that we could use a DocBook/XML manual > > > page as master source file shared between documentation and code folks > > > in the future from which both the Solaris manpage and the getopts string > > > can be generated from (this would eliminate all the "manpages > > > out-of-sync" concerns described in this thread)) > > > > > > > > > > That helps address some, but not all, of the concerns. You still wind up > > with the situation of two physical copies of the documentation on the media. > > > > This approach also seems not to match what the upstream suppliers seem to > > be saying... > > > > I rather strongly suspect that in the end we will be faced with one of two > > choices: > > > > 1) fork the code base and do what we feel is right for Solaris, or > > > Didn't you read what Roland wrote about the project rules? > > > in several major and unbreakable rules for this project which > > includes: > > - WE DO NOT FORK THE CODE > > - WE DO NOT BREAK THE KSH93 TEST SUITE > > - THE KSH93 TEST SUITE IS COMPLETELY OFF-LIMITS FOR CHANGES > > > If you are forking the code with such unnecessary changes I will NO > LONGER CONTRIBUTE to this or any other Opensolaris.org project. I will not contribute either if Sun decides to fork with silly justifications. Taking away --man is an incompatible change and must not be tolerated. Josh From Alan.Coopersmith@sun.com Sun Jul 26 09:51:11 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QGpAuI020852 for ; Sun, 26 Jul 2009 09:51:11 -0700 (PDT) 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 n6QGp2T0022443 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 00:51:09 +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 <0KNE00M05ET8DQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:51:08 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00AQ1ET8S6B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:51:08 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QGp8M2017993 for ; Sun, 26 Jul 2009 09:51:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNE00I00ENI2900@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:51:08 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNE003REET75660@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:51:08 -0700 (PDT) Date: Sun, 26 Jul 2009 09:51:07 -0700 From: Alan Coopersmith Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B4FBB.1070808@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: Chris Pickett , Korn Shell 93 integration/migration project discussion , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <4A6C897B.5020408@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 824 Garrett D'Amore wrote: > When the --man output really is a manual page, I still object. It > doesn't matter what you call it -- the problem is that we have two > copies of the same information, the on-line manual page and the bits in > the binary. Will your opinion text also recommend to the PAC that they delete all the admin guides, user guides, and all other docs other than the man pages from the Solaris documentation and docs.sun.com because they are multiple copies of the same information? This is the cost of having human users - it's often more usable to provide the same information in multiple ways, and the cost is that we need to remember to update all of them when modifying the software. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Sun Jul 26 09:56:14 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QGuDZs021213 for ; Sun, 26 Jul 2009 09:56:14 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6QGu73x004314 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 17:56:13 +0100 (BST) 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 <0KNE00C01F1NO300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 10:56:11 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00J3CF1MF560@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 10:56:10 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QGuAml000724 for ; Sun, 26 Jul 2009 09:56:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNE00K00EXL7F00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:56:10 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNE00B3YF1K0Y40@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 09:56:08 -0700 (PDT) Date: Sun, 26 Jul 2009 09:56:08 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6C897B.5020408@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: Chris Pickett , Korn Shell 93 integration/migration project discussion , PSARC-ext@sun.com, busybox-dev@opensolaris.org Message-id: <4A6C8AA8.5030702@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6C897B.5020408@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1140 Alan Coopersmith wrote: > Garrett D'Amore wrote: > >> When the --man output really is a manual page, I still object. It >> doesn't matter what you call it -- the problem is that we have two >> copies of the same information, the on-line manual page and the bits in >> the binary. >> > > Will your opinion text also recommend to the PAC that they delete all > the admin guides, user guides, and all other docs other than the man > pages from the Solaris documentation and docs.sun.com because they are > multiple copies of the same information? > No, because of two reasons: 1) the "man pages" are sourced by the same process and originate from the same text 2) those bits are not delivered to the end-users on the media Of course, if you want to add some text to the potential opinion (which may or may not be a minority opinion), feel free to send me draft text after the vote. - Garrett > This is the cost of having human users - it's often more usable to provide > the same information in multiple ways, and the cost is that we need to > remember to update all of them when modifying the software. > > From unixconsole@yahoo.com Sun Jul 26 10:21:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QHLijY021421 for ; Sun, 26 Jul 2009 10:21:44 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6QHLght014524 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 18:21:43 +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 <0KNE00501G878D00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 10:21:43 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00L32G864O80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 10:21:42 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6QHFIEl013721 for ; Sun, 26 Jul 2009 17:21:42 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-205012 for PSARC-ext@sun.com; Sun, 26 Jul 2009 17:21:42 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-10276599 for PSARC-ext@sun.com; Sun, 26 Jul 2009 17:21:41 +0000 (Z) Received: from web30805.mail.mud.yahoo.com ([68.142.200.148] [68.142.200.148]) by relay1i.sun.com id BT-MMP-8305269 for PSARC-ext@sun.com; Sun, 26 Jul 2009 17:21:41 +0000 (Z) Received: (qmail 20921 invoked by uid 60001); Sun, 26 Jul 2009 17:21:35 +0000 Received: from [67.232.108.234] by web30805.mail.mud.yahoo.com via HTTP; Sun, 26 Jul 2009 10:21:35 -0700 (PDT) Date: Sun, 26 Jul 2009 10:21:35 -0700 (PDT) From: Octave Orgeron Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6BE107.47F65A19@nrubsig.org> To: Roland Mainz , John Sonnenschein Cc: Alan Coopersmith , Busybox development , "Garrett D'Amore" , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <360931.20852.qm@web30805.mail.mud.yahoo.com> MIME-version: 1.0 X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1248628895; bh=BjPxvNeial+9s0SIbH4Rnxda2IYAqWrkBXrtGcwSvhQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6SCxqHHZOGApwRqNBybHaLSaWTBhUBZBnsR0JWkmldMHDb6Oy+7KJiRdtVdyGzLCdIw6/ygfK0JiM0k1Q6hRw229j8+P492IpNYrQrYQTzVQ/0RCQFnq5lw2jxZ+289dv4Eh37ClfG/rwt+wKWYpRO9lqLDLZgLZt7fPqmmqwy4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nJZGu1gF06QhVf2qXvVuFqAPvfIz3gZv0xvVf+Yp6LXfFTxZOk+sPdA82dEMvEtKuMBcwzUi6LYXF0NAQCsmvL4+u9g+MhYsHnFwOE/TiQijtniqS8nYmFLn25IM1LW9WGsNmxeZYnn7wONA2tPBib8uENOWftps0KEGkpUOj20=; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-YMail-OSG: 8SPEvsAVM1nAYs5NcEwf2NDHNLWMrNCS0cFtBdjne1O5bxnm2SkzWCs.LYUDYL2Lh6PezuoYP6q3an.RpLYX.94.kYidcR412yGrDdVR7WA5As7j3l1BknTrsGvK5fIuzItfx9TXiVrToqnK.mm4gaFq9lsaZJ9XaSgxKDLCTK0Ig8k28Vfv5vYt.evC0YWKapGEbX.0qSJksxkBRKW8.GThR5HveGJwpttwvXK5846byRN2kkPTOIIlvhVBc6RgAsPpZvEdXwtSTxhKSD5dYf6UfHHGLK45hpGV0OxLwSxC71O9PAHL9i3Iq4ZGlT5OqruaEUb.KieZTJojYodtY78- X-Antispam: No, score=0.0/5.0, scanned in 0.105sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> <4A6BE107.47F65A19@nrubsig.org> Status: RO Content-Length: 3975 Hi Roland, I'm not against having multiple ways of accessing the man page data as long as the output is consistent. The solution you mentioned below I think is reasonable and something that can be maintained. Having the docbook/xml master source would solve a lot of issues and could be the single source for Solaris/OpenSolaris binaries, manpages, and docs.sun.com entries. I would like to recommend that this path be taken and brought before the ARC to make it the standard generation and maintenance interface for man pages. It may be appropriate for such a project to be sponsored by the Documentation community. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixconsole@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ----- Original Message ---- From: Roland Mainz To: John Sonnenschein Cc: Alan Coopersmith ; Busybox development ; Garrett D'Amore ; ksh93-integration-discuss@opensolaris.org; PSARC-ext@sun.com Sent: Saturday, July 25, 2009 11:52:23 PM Subject: Re: [busybox-dev] AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] John Sonnenschein wrote: > On 25-Jul-09, at 4:59 PM, James Carlson wrote: > > John Sonnenschein wrote: > >> I've got a question about this... > >> Whose responsibility is it to update the man pages and --man > >> command then? The people whose jobs it is to update man pages, or > >> the people whose jobs it is to update the command line utility? > >> Basically if a new flag is added in the future for some reason, how > >> will one synchronize the man pages? > > > > Usually, that's done by filing a bug against the man pages. > > > > The advantage of keeping the documentation separate is that it's in > > the hands of professional documentation writers, who are able to > > keep a consistent style across all of the system man pages. > > > > I'm with Garrett about the inadvisability of baking man page > > documentation into executables, but for ksh93-related things, I > > think that ship has unfortunately sailed. > > Sure but for the sake of argument if we have some tools that have -- > man and also man pages, does that mean that the docs people will be > putting back to ON, Erm... why should the documentation people do putback into OS/Net ? The strings used by getopts are used for argument parsing and are - as "nice side-effect" - reused to generate the output for --help, --version, --man etc. > or will there be a desynchronization between the > man pages and the --man pages ? They _may_ be out-of-sync shortly after code putback if we add new options to the |getopts()| string until the documentation folks caught up with the code changes. But as I am trying to say over and over again (and I am starting to feel _ignored_) that the output for --help, --man etc. is generated from the getopts string template used for argument parsing. This string is there to "drive" the argument parsing and is absolutely the wrong place for Solaris-specific edits. We have a real, seperate and maintained manual page for that purpose ([1]). [1]=(And as said _several_ times that we could use a DocBook/XML manual page as master source file shared between documentation and code folks in the future from which both the Solaris manpage and the getopts string can be generated from (this would eliminate all the "manpages out-of-sync" concerns described in this thread)) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org From pickychris@googlemail.com Sun Jul 26 11:25:26 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QIPPOq021990 for ; Sun, 26 Jul 2009 11:25:26 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6QIPEtT013049; Sun, 26 Jul 2009 19:25:23 +0100 (BST) 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 <0KNE00M05J6AB900@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 12:25:22 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00JINJ67F1A0@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 12:25:21 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QIPEFk005064; Sun, 26 Jul 2009 18:25:18 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-996122; Sun, 26 Jul 2009 18:25:06 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-18843473; Sun, 26 Jul 2009 18:25:03 +0000 (Z) Received: from mail-bw0-f211.google.com ([209.85.218.211] [209.85.218.211]) by relay4i.sun.com with ESMTP id BT-MMP-10182993; Sun, 26 Jul 2009 18:25:03 +0000 (Z) Received: by bwz7 with SMTP id 7so2247056bwz.8 for ; Sun, 26 Jul 2009 11:25:01 -0700 (PDT) Received: by 10.204.116.15 with SMTP id k15mr2202167bkq.118.1248632701576; Sun, 26 Jul 2009 11:25:01 -0700 (PDT) Date: Sun, 26 Jul 2009 20:25:00 +0200 From: Chris Pickett Subject: Re: [ksh93-integration-discuss] [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: Sender: pickychris@googlemail.com To: Korn Shell 93 integration/migration project discussion , "Garrett D'Amore" Cc: Roland Mainz , PSARC-ext@sun.com, John Sonnenschein , James Carlson , Busybox development Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=K5ON1HGkzwpACEGFhRB4uN15z5Rgc8haD+eQFW2qbXQ=; b=guBFp70U1ABNWnrCZ0BVIs2huQiFyxfo0ZMVm10hNrpJxnyn0ICSr1QT/Jmjm0EZFY RhK9/ocsxu6O1APsUqyerr9FOhuQ3D4p40tS8EJwHD+0oZdcH4/oXlCpHy5ObqzYEjMj GeJUqfeB1iO+pyDZe3T+IXEn2yfdxdg1Nb8MU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=i56Kon9XtUvMC5hv5M9SglaQoJtiKni7sdzvy6y37QjB32X9D4F2zIReHGwbWpDeSb 1aabvi5cIpUX0+OqgtUUxbgxZaVLYuAi+ae16VEOxMFEgf/EWL5hthJPiRLqmsvjgXEo QDe1vlINSZir23/SfSpMjEhSjsAbabZQG6DYE= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 09cca01a4af93235 X-Antispam: No, score=-2.6/5.0, scanned in 3.165sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> <4A6BE107.47F65A19@nrubsig.org> <4A6BE395.9060108@sun.com> <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> Status: RO Content-Length: 4845 On 7/26/09, Josh Hurst wrote: > On 7/26/09, Jennifer Pioch wrote: > > On 7/26/09, Garrett D'Amore wrote: > > > Roland Mainz wrote: > > > > > > > John Sonnenschein wrote: > > > > > > > > > > > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote: > > > > > > > > > > > > > > > > John Sonnenschein wrote: > > > > > > > > > > > > > > > > > > > I've got a question about this... > > > > > > > Whose responsibility is it to update the man pages and --man > > > > > > > command then? The people whose jobs it is to update man pages, or > > > > > > > the people whose jobs it is to update the command line utility? > > > > > > > Basically if a new flag is added in the future for some reason, how > > > > > > > will one synchronize the man pages? > > > > > > > > > > > > > > > > > > > > Usually, that's done by filing a bug against the man pages. > > > > > > > > > > > > The advantage of keeping the documentation separate is that it's in > > > > > > the hands of professional documentation writers, who are able to > > > > > > keep a consistent style across all of the system man pages. > > > > > > > > > > > > I'm with Garrett about the inadvisability of baking man page > > > > > > documentation into executables, but for ksh93-related things, I > > > > > > think that ship has unfortunately sailed. > > > > > > > > > > > > > > > > > Sure but for the sake of argument if we have some tools that have -- > > > > > man and also man pages, does that mean that the docs people will be > > > > > putting back to ON, > > > > > > > > > > > > > > > > > > Erm... why should the documentation people do putback into OS/Net ? The > > > > strings used by getopts are used for argument parsing and are - as "nice > > > > side-effect" - reused to generate the output for --help, --version, > > > > --man etc. > > > > > > > > > > > > > > I have no objections to --version, --help. My concerns relate to --man, > > > --nroff, and --html. > > > > > > > > > > > > > > > > > > > or will there be a desynchronization between the > > > > > man pages and the --man pages ? > > > > > > > > > > > > > > > > > > They _may_ be out-of-sync shortly after code putback if we add new > > > > options to the |getopts()| string until the documentation folks caught > > > > up with the code changes. But as I am trying to say over and over again > > > > (and I am starting to feel _ignored_) that the output for --help, --man > > > > etc. is generated from the getopts string template used for argument > > > > parsing. This string is there to "drive" the argument parsing and is > > > > absolutely the wrong place for Solaris-specific edits. We have a real, > > > > seperate and maintained manual page for that purpose ([1]). > > > > > > > > > > > > > > Apparently the upstream disagrees with you. They (well Glenn) in fact > > > *recommend* that the man page generated automatically from the --nroff > > > output. > > > > > > > > > > [1]=(And as said _several_ times that we could use a DocBook/XML manual > > > > page as master source file shared between documentation and code folks > > > > in the future from which both the Solaris manpage and the getopts string > > > > can be generated from (this would eliminate all the "manpages > > > > out-of-sync" concerns described in this thread)) > > > > > > > > > > > > > > That helps address some, but not all, of the concerns. You still wind up > > > with the situation of two physical copies of the documentation on the media. > > > > > > This approach also seems not to match what the upstream suppliers seem to > > > be saying... > > > > > > I rather strongly suspect that in the end we will be faced with one of two > > > choices: > > > > > > 1) fork the code base and do what we feel is right for Solaris, or > > > > > > Didn't you read what Roland wrote about the project rules? > > > > > in several major and unbreakable rules for this project which > > > includes: > > > - WE DO NOT FORK THE CODE > > > - WE DO NOT BREAK THE KSH93 TEST SUITE > > > - THE KSH93 TEST SUITE IS COMPLETELY OFF-LIMITS FOR CHANGES > > > > > > If you are forking the code with such unnecessary changes I will NO > > LONGER CONTRIBUTE to this or any other Opensolaris.org project. > > > I will not contribute either if Sun decides to fork with silly > justifications. Taking away --man is an incompatible change and must > not be tolerated. I agree with Josh. Neither I will contribute to Opensolaris if Sun forks the AST code just to enforce their silly politics. -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris@users.sourceforge.net From roland.mainz@nrubsig.org Sun Jul 26 15:22:50 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QMMoKA027557 for ; Sun, 26 Jul 2009 15:22:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QMMnAk007873 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 16:22:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00L05U613V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Sun, 26 Jul 2009 15:22:49 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE005IEU5YTL50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Sun, 26 Jul 2009 15:22:47 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6QMMkYf007518 for ; Sun, 26 Jul 2009 22:22:46 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-214955 for PSARC-ext@Sun.Com; Sun, 26 Jul 2009 22:22:46 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-8114337 for PSARC-ext@Sun.Com; Sun, 26 Jul 2009 22:22:45 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay1i.sun.com with ESMTP id BT-MMP-5540980 for PSARC-ext@Sun.Com; Sun, 26 Jul 2009 22:19:54 +0000 (Z) Received: from mail-in-20-z2.arcor-online.net (mail-in-20-z2.arcor-online.net [151.189.8.85]) by mx.arcor.de (Postfix) with ESMTP id 311671B381B; Mon, 27 Jul 2009 00:19:34 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-20-z2.arcor-online.net (Postfix) with ESMTP id 22F8D107F9A; Mon, 27 Jul 2009 00:19:34 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-072-228.pools.arcor-ip.net [84.59.72.228]) by mail-in-06.arcor-online.net (Postfix) with ESMTPS id A614139A54D; Mon, 27 Jul 2009 00:19:32 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6QMJTdT000949; Mon, 27 Jul 2009 00:19:29 +0200 (CEST) Date: Mon, 27 Jul 2009 00:19:29 +0200 From: Roland Mainz Subject: Some clarifications about "--help" and "--man" / Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: Busybox development Cc: PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org Message-id: <4A6CD671.C536E21F@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net A614139A54D X-Antispam: No, score=0.0/5.0, scanned in 0.181sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> Status: RO Content-Length: 1759 Alan Coopersmith wrote: > I'm sponsoring this fast-track request on behalf of the > ksh93-integration and busybox projects. The timeout is > set for Friday, July 31, 2009. [snip] Just to clarify (since both points have IMHO been either ignored or misinterpreted several times): 1. We do _not_ intent to remove or discontinue normal documentation, including manual pages (in fact I've been a long-term advocate of getting Solaris moved to DocBook/XML-based manual pages (including _shipping_ them as part of the installation instead of the nroff versions (that's why I even worked on a /usr/bin/man replacement codebase))). 2. The whole idea of "--man" was to re-use the existing information used by the |libast::getopts()| call to provide quick access to _never_ information. It was _never_ intended (by this project (but not upstream (for which the --nroff/--man output is _sufficient_))) to be a _complete_ manual page with all manpage sections required by Solaris. From an ARC point of view I only see this (and intent to treat it) as an extended form of the "--help" option which AFAIK has significant amount of precendet. I really wish ARC would simply see "--man" as such, too. What I still try to offer is the "truce" of letting us work in _peace_ on the idea of having one master DocBook/XML manual page file from which both the normal manpages and the getopts strings are generated from (manpages have the full information, the getopts stuff just the terse information to keep it small). Garret, would you accept the "truce" and remove the "de-rail", please ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore@sun.com Sun Jul 26 16:01:01 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QN11kb006702 for ; Sun, 26 Jul 2009 16:01:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QN0s4b013768 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 16:01:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00403VXMDW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sun, 26 Jul 2009 16:00:58 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00GK5VXM0F30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sun, 26 Jul 2009 16:00:58 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QN0vtc023439 for ; Sun, 26 Jul 2009 16:00:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNE00A00VSJ0N00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 26 Jul 2009 16:00:57 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNE002MJVXL8F30@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 26 Jul 2009 16:00:57 -0700 (PDT) Date: Sun, 26 Jul 2009 16:00:57 -0700 From: "Garrett D'Amore" Subject: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6CD671.C536E21F@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Busybox development , PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org Message-id: <4A6CE029.9030304@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2550 Roland Mainz wrote: > Alan Coopersmith wrote: > >> I'm sponsoring this fast-track request on behalf of the >> ksh93-integration and busybox projects. The timeout is >> set for Friday, July 31, 2009. >> > [snip] > > Just to clarify (since both points have IMHO been either ignored or > misinterpreted several times): > 1. We do _not_ intent to remove or discontinue normal documentation, > including manual pages (in fact I've been a long-term advocate of > getting Solaris moved to DocBook/XML-based manual pages (including > _shipping_ them as part of the installation instead of the nroff > versions (that's why I even worked on a /usr/bin/man replacement > codebase))). > I heard you. However, the upstream sources have *not* agreed with this approach. > 2. The whole idea of "--man" was to re-use the existing information used > by the |libast::getopts()| call to provide quick access to _never_ > information. It was _never_ intended (by this project (but not upstream > (for which the --nroff/--man output is _sufficient_))) to be a > _complete_ manual page with all manpage sections required by Solaris. > From an ARC point of view I only see this (and intent to treat it) as an > extended form of the "--help" option which AFAIK has significant amount > of precendet. I really wish ARC would simply see "--man" as such, too. > The problem is that this distinction is lost to *users*. You're calling it --man, and you're presenting it as a manual page. Saying its one thing, then presenting it as something else doesn't make sense. > What I still try to offer is the "truce" of letting us work in _peace_ > on the idea of having one master DocBook/XML manual page file from which > both the normal manpages and the getopts strings are generated from > (manpages have the full information, the getopts stuff just the terse > information to keep it small). > > Garret, would you accept the "truce" and remove the "de-rail", please ? > No, its too late for that. The project has been derailed for a vote. As I said, you don't have do anything else at this point except wait for the vote on Wednesday (unless you'd prefer us to reschedule for another date). Actually lets make this more explicit. Would you like us to take a vote on Wednesday, or would you like to defer this to another meeting? Its your project, so we can do the vote at any regular PSARC meeting that you feel is appropriate. I'd recommend trying to be present at the meeting, however. - Garrett > ---- > > Bye, > Roland > > From roland.mainz@nrubsig.org Sun Jul 26 16:21:01 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QNL0P4001251 for ; Sun, 26 Jul 2009 16:21:01 -0700 (PDT) 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 n6QNKgNt022379; Mon, 27 Jul 2009 07:20:58 +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 <0KNE00A03WUWYW00@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 17:20:56 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE004L9WUWUIE0@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 17:20:56 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QNKtsL010979; Sun, 26 Jul 2009 23:20:56 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-216738; Sun, 26 Jul 2009 23:20:55 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-8209047; Sun, 26 Jul 2009 23:20:54 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay1i.sun.com with ESMTP id BT-MMP-8996507; Sun, 26 Jul 2009 23:20:54 +0000 (Z) Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mx.arcor.de (Postfix) with ESMTP id 181B51B3698; Mon, 27 Jul 2009 01:20:53 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id 08D755BEBB; Mon, 27 Jul 2009 01:20:53 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-072-228.pools.arcor-ip.net [84.59.72.228]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id 7D89E1B3698; Mon, 27 Jul 2009 01:20:49 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6QNKl60000964; Mon, 27 Jul 2009 01:20:47 +0200 (CEST) Date: Mon, 27 Jul 2009 01:20:47 +0200 From: Roland Mainz Subject: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Busybox development , PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org Message-id: <4A6CE4CF.A3692F8E@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net 7D89E1B3698 X-Antispam: No, score=0.0/5.0, scanned in 0.696sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> Status: RO Content-Length: 886 Garrett D'Amore wrote: > Roland Mainz wrote: > > Alan Coopersmith wrote: [snip] > > What I still try to offer is the "truce" of letting us work in _peace_ > > on the idea of having one master DocBook/XML manual page file from which > > both the normal manpages and the getopts strings are generated from > > (manpages have the full information, the getopts stuff just the terse > > information to keep it small). > > > > Garret, would you accept the "truce" and remove the "de-rail", please ? > > No, its too late for that. Ok... I really tried to mediate a way though this but it seems we're stuck and right now it looks we're getting too much damage... ... here hereby _withdraw_ this ARC case. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz@nrubsig.org Sun Jul 26 16:21:01 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QNL0P4001251 for ; Sun, 26 Jul 2009 16:21:01 -0700 (PDT) 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 n6QNKgNt022379; Mon, 27 Jul 2009 07:20:58 +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 <0KNE00A03WUWYW00@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 17:20:56 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE004L9WUWUIE0@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 17:20:56 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6QNKtsL010979; Sun, 26 Jul 2009 23:20:56 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-216738; Sun, 26 Jul 2009 23:20:55 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-8209047; Sun, 26 Jul 2009 23:20:54 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay1i.sun.com with ESMTP id BT-MMP-8996507; Sun, 26 Jul 2009 23:20:54 +0000 (Z) Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mx.arcor.de (Postfix) with ESMTP id 181B51B3698; Mon, 27 Jul 2009 01:20:53 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id 08D755BEBB; Mon, 27 Jul 2009 01:20:53 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-072-228.pools.arcor-ip.net [84.59.72.228]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id 7D89E1B3698; Mon, 27 Jul 2009 01:20:49 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6QNKl60000964; Mon, 27 Jul 2009 01:20:47 +0200 (CEST) Date: Mon, 27 Jul 2009 01:20:47 +0200 From: Roland Mainz Subject: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Busybox development , PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org Message-id: <4A6CE4CF.A3692F8E@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net 7D89E1B3698 X-Antispam: No, score=0.0/5.0, scanned in 0.696sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> Status: RO Content-Length: 886 Garrett D'Amore wrote: > Roland Mainz wrote: > > Alan Coopersmith wrote: [snip] > > What I still try to offer is the "truce" of letting us work in _peace_ > > on the idea of having one master DocBook/XML manual page file from which > > both the normal manpages and the getopts strings are generated from > > (manpages have the full information, the getopts stuff just the terse > > information to keep it small). > > > > Garret, would you accept the "truce" and remove the "de-rail", please ? > > No, its too late for that. Ok... I really tried to mediate a way though this but it seems we're stuck and right now it looks we're getting too much damage... ... here hereby _withdraw_ this ARC case. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz@nrubsig.org Sun Jul 26 16:30:14 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QNUEwn001314 for ; Sun, 26 Jul 2009 16:30:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QNUDJg009367; Sun, 26 Jul 2009 16:30:13 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00603XADEE00@nwk-avmta-2.sfbay.sun.com>; Sun, 26 Jul 2009 16:30:13 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00G4FXAD0H50@nwk-avmta-2.sfbay.sun.com>; Sun, 26 Jul 2009 16:30:13 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6QNUDA4012437; Sun, 26 Jul 2009 23:30:13 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-1006482; Sun, 26 Jul 2009 23:30:13 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-21456788; Sun, 26 Jul 2009 23:30:12 +0000 (Z) Received: from mail-in-05.arcor-online.net ([151.189.21.45] [151.189.21.45]) by relay4i.sun.com with ESMTP id BT-MMP-22894576; Sun, 26 Jul 2009 23:30:11 +0000 (Z) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mx.arcor.de (Postfix) with ESMTP id 26D173327D3; Mon, 27 Jul 2009 01:30:11 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id 1712B724710; Mon, 27 Jul 2009 01:30:11 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-072-228.pools.arcor-ip.net [84.59.72.228]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id BC3841B3698; Mon, 27 Jul 2009 01:30:09 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6QNU70r000969; Mon, 27 Jul 2009 01:30:07 +0200 (CEST) Date: Mon, 27 Jul 2009 01:30:07 +0200 From: Roland Mainz Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com, Busybox development Message-id: <4A6CE6FF.AC216295@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net BC3841B3698 X-Antispam: No, score=0.0/5.0, scanned in 0.317sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> Status: RO Content-Length: 1055 Roland Mainz wrote: > Garrett D'Amore wrote: > > Roland Mainz wrote: > > > Alan Coopersmith wrote: > [snip] > > > What I still try to offer is the "truce" of letting us work in _peace_ > > > on the idea of having one master DocBook/XML manual page file from which > > > both the normal manpages and the getopts strings are generated from > > > (manpages have the full information, the getopts stuff just the terse > > > information to keep it small). > > > > > > Garret, would you accept the "truce" and remove the "de-rail", please ? > > > > No, its too late for that. > > Ok... I really tried to mediate a way though this but it seems we're > stuck and right now it looks we're getting too much damage... > > ... here hereby _withdraw_ this ARC case. s/here/I/ I think the best option is now to drop this subject and discuss this on the next OpenSolaris summit... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz@nrubsig.org Sun Jul 26 16:30:14 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6QNUEwn001314 for ; Sun, 26 Jul 2009 16:30:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6QNUDJg009367; Sun, 26 Jul 2009 16:30:13 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNE00603XADEE00@nwk-avmta-2.sfbay.sun.com>; Sun, 26 Jul 2009 16:30:13 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNE00G4FXAD0H50@nwk-avmta-2.sfbay.sun.com>; Sun, 26 Jul 2009 16:30:13 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6QNUDA4012437; Sun, 26 Jul 2009 23:30:13 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-1006482; Sun, 26 Jul 2009 23:30:13 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-21456788; Sun, 26 Jul 2009 23:30:12 +0000 (Z) Received: from mail-in-05.arcor-online.net ([151.189.21.45] [151.189.21.45]) by relay4i.sun.com with ESMTP id BT-MMP-22894576; Sun, 26 Jul 2009 23:30:11 +0000 (Z) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mx.arcor.de (Postfix) with ESMTP id 26D173327D3; Mon, 27 Jul 2009 01:30:11 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id 1712B724710; Mon, 27 Jul 2009 01:30:11 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-072-228.pools.arcor-ip.net [84.59.72.228]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id BC3841B3698; Mon, 27 Jul 2009 01:30:09 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n6QNU70r000969; Mon, 27 Jul 2009 01:30:07 +0200 (CEST) Date: Mon, 27 Jul 2009 01:30:07 +0200 From: Roland Mainz Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com, Busybox development Message-id: <4A6CE6FF.AC216295@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.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net BC3841B3698 X-Antispam: No, score=0.0/5.0, scanned in 0.317sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> Status: RO Content-Length: 1055 Roland Mainz wrote: > Garrett D'Amore wrote: > > Roland Mainz wrote: > > > Alan Coopersmith wrote: > [snip] > > > What I still try to offer is the "truce" of letting us work in _peace_ > > > on the idea of having one master DocBook/XML manual page file from which > > > both the normal manpages and the getopts strings are generated from > > > (manpages have the full information, the getopts stuff just the terse > > > information to keep it small). > > > > > > Garret, would you accept the "truce" and remove the "de-rail", please ? > > > > No, its too late for that. > > Ok... I really tried to mediate a way though this but it seems we're > stuck and right now it looks we're getting too much damage... > > ... here hereby _withdraw_ this ARC case. s/here/I/ I think the best option is now to drop this subject and discuss this on the next OpenSolaris summit... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From carlsonj@workingcode.com Sun Jul 26 18:16:24 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6R1GKhO002565 for ; Sun, 26 Jul 2009 18:16:23 -0700 (PDT) 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 n6R1GF5q015754 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 09:16:20 +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 <0KNF001012771M00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 19:16:19 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNF00BID277A940@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 19:16:19 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6R1GHt6004513 for ; Mon, 27 Jul 2009 01:16:18 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-328164 for PSARC-ext@sun.com; Mon, 27 Jul 2009 01:16:17 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-8508716 for PSARC-ext@sun.com; Mon, 27 Jul 2009 01:16:16 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-9157636 for PSARC-ext@sun.com; Mon, 27 Jul 2009 01:14:53 +0000 (Z) Received: from [192.168.254.181] (dhcp-181 [192.168.254.181]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n6R1Dweq022143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jul 2009 21:13:59 -0400 (EDT) Date: Sun, 26 Jul 2009 21:13:48 -0400 From: James Carlson Subject: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6CD671.C536E21F@nrubsig.org> To: Roland Mainz Cc: Busybox development , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6CFF4C.8000304@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=4 Fuz1=4 Fuz2=4 X-Antispam: No, score=0.0/5.0, scanned in 0.154sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Status: RO Content-Length: 1211 Roland Mainz wrote: > Garret, would you accept the "truce" and remove the "de-rail", please ? I think you're confused about the process that's in use in the ARC. "De-rail" does not in any way mean "deny." In fact, it doesn't even mean that there's anything wrong with the proposed project. I've even derailed my *own* projects. What "derail" means -- in ARC terms -- is one of the following: - that at least some of the reviewers think that a written ARC opinion is needed. or: - that some reviewers think that the project either isn't as "obvious" or "simple" as is required for a formal fast-track request. The effect of "derailing" is that (a) the fast-track timer is stopped, (b) the case turns into a full review, and (c) the ARC member who derailed is now the case owner and is on the hook to write the ARC's opinion. It's certainly not an indictment of your work, and if you read it that way, you're just going to get yourself (and others!) frustrated for no reason whatsoever. No "truce" is needed here, because there's no "battle." Please. Take a breath. Perhaps two. And then think about replying again. -- James Carlson 42.703N 71.076W From gsf@research.att.com Sun Jul 26 19:56:22 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6R2uL60003667 for ; Sun, 26 Jul 2009 19:56:22 -0700 (PDT) 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 n6R2uFZ1003100 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 10:56:20 +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 <0KNF00D096TU1I00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 20:56:18 -0600 (MDT) 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 <0KNF00B7G6TTAH90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 20:56:17 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6R2uCqP021690 for ; Mon, 27 Jul 2009 02:56:17 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-330906 for PSARC-ext@sun.com; Mon, 27 Jul 2009 02:56:12 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-11265405 for PSARC-ext@sun.com; Mon, 27 Jul 2009 02:56:12 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-9348334 for PSARC-ext@sun.com; Mon, 27 Jul 2009 02:50:21 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-blue.research.att.com (Postfix) with ESMTP id 1224BF0E5F; Sun, 26 Jul 2009 22:49:34 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6R2nXqp017475; Sun, 26 Jul 2009 22:49:33 -0400 Date: Sun, 26 Jul 2009 22:49:33 -0400 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] Some clarifications about "--help" and "--man" / Re: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: ksh93-integration-discuss@opensolaris.org, roland.mainz@nrubsig.org Cc: busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <200907270249.n6R2nXqp017475@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.056sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> Status: RO Content-Length: 949 On Sun, 26 Jul 2009 16:00:57 -0700 Garrett D'Amore wrote: > Roland Mainz wrote: > > Alan Coopersmith wrote: > > > >> I'm sponsoring this fast-track request on behalf of the > >> ksh93-integration and busybox projects. The timeout is > >> set for Friday, July 31, 2009. > >> > > [snip] > > > > Just to clarify (since both points have IMHO been either ignored or > > misinterpreted several times): > > 1. We do _not_ intent to remove or discontinue normal documentation, > > including manual pages (in fact I've been a long-term advocate of > > getting Solaris moved to DocBook/XML-based manual pages (including > > _shipping_ them as part of the installation instead of the nroff > > versions (that's why I even worked on a /usr/bin/man replacement > > codebase))). > I heard you. However, the upstream sources have *not* agreed with this > approach. you want upstream to agree to an approach that even solaris hasn't settled on yet? From Nicolas.Williams@sun.com Sun Jul 26 20:57:16 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6R3vGaW007374 for ; Sun, 26 Jul 2009 20:57:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6R3v3g1027032; Sun, 26 Jul 2009 20:57:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNF00N099NE2H00@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 21:57:14 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNF00B5V9NDA9C0@brm-avmta-1.central.sun.com>; Sun, 26 Jul 2009 21:57:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n6R3kjsW006397; Sun, 26 Jul 2009 22:46:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6R3kjqY006396; Sun, 26 Jul 2009 22:46:45 -0500 (CDT) Date: Sun, 26 Jul 2009 22:46:45 -0500 From: Nicolas Williams Subject: "derail" is not a bad thing (Re: PSARC/2009/414 _withdrawn_) In-reply-to: <4A6CE4CF.A3692F8E@nrubsig.org> To: Korn Shell 93 integration/migration project discussion Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Busybox development Message-id: <20090727034645.GU1020@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 465 A "derail" doesn't mean the project is dead. It only means that the ARC will have to vote and issue an opinion. The word "derail" relates to "fast-track" -- a fast-track is a case that's "on the fast track to approval", while the "slow track" means that there could be an actual meeting, a vote, and an opinion. That's all. It's _not_ a bad thing unless the i-team is in a hurry and can't wait to have a scheduled meeting, vote and opinion published. Nico -- From gdamore@sun.com Sun Jul 26 21:21:10 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6R4L9m7007623 for ; Sun, 26 Jul 2009 21:21:10 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6R4L6p0028984 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 05:21:08 +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 <0KNF00301AR8P400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 21:21:08 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNF00JF0AR5UNC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 21:21:08 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6R4L52d016455 for ; Sun, 26 Jul 2009 21:21:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNF00800AQ9CG00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 21:21:05 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNF006YQAR49Q00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 26 Jul 2009 21:21:05 -0700 (PDT) Date: Sun, 26 Jul 2009 21:21:04 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] Some clarifications about "--help" and "--man" / Re: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <200907270249.n6R2nXqp017475@penguin.research.att.com> Sender: Garrett.Damore@sun.com To: Glenn Fowler Cc: ksh93-integration-discuss@opensolaris.org, roland.mainz@nrubsig.org, busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6D2B30.2060105@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <200907270249.n6R2nXqp017475@penguin.research.att.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2206 Glenn Fowler wrote: > On Sun, 26 Jul 2009 16:00:57 -0700 Garrett D'Amore wrote: > >> Roland Mainz wrote: >> >>> Alan Coopersmith wrote: >>> >>> >>>> I'm sponsoring this fast-track request on behalf of the >>>> ksh93-integration and busybox projects. The timeout is >>>> set for Friday, July 31, 2009. >>>> >>>> >>> [snip] >>> >>> Just to clarify (since both points have IMHO been either ignored or >>> misinterpreted several times): >>> 1. We do _not_ intent to remove or discontinue normal documentation, >>> including manual pages (in fact I've been a long-term advocate of >>> getting Solaris moved to DocBook/XML-based manual pages (including >>> _shipping_ them as part of the installation instead of the nroff >>> versions (that's why I even worked on a /usr/bin/man replacement >>> codebase))). >>> > > >> I heard you. However, the upstream sources have *not* agreed with this >> approach. >> > > you want upstream to agree to an approach that even solaris hasn't settled on yet? > Well that much is true (we've not settled yet) -- the decision *would* have been good to have (either way), which is why I derailed it... I felt that such a decision deserved explicit consideration rather than coming in as an implementation detail. That said... I received the following text in an e-mail message from you (also delivered to the list): in almost all other cases the optget() usage string *is* the man page src, and we have no intention of ever maintaining separate .1 man pages, save the traditional exceptions for the long ones like sh(1) if there are concerns about maintaining separate optget() usage strings and .1 text files for ast commands on solaris, then I recommend generating the man page from the --nroff output; So while the question of a separate XML file wasn't specifically raised and answered, I had taken the above text to indicate that you (collectively as the ksh93 upstream) were also rejecting other schemes to move this kind of documentation out of the cooked binary. I'm sorry if I've misunderstood either you or Roland on this, or if I've misapplied what you said. - Garrett From cedric.blancher@googlemail.com Mon Jul 27 00:02:46 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6R72jub000764 for ; Mon, 27 Jul 2009 00:02:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6R72iZ3002546 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 01:02:45 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNF00G07I8K9D00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 00:02:44 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNF00BYFI8KMP60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 00:02:44 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6R72hE1029515 for ; Mon, 27 Jul 2009 07:02:43 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-232328 for PSARC-ext@sun.com; Mon, 27 Jul 2009 07:02:43 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-11693161 for PSARC-ext@sun.com; Mon, 27 Jul 2009 07:02:38 +0000 (Z) Received: from mail-bw0-f211.google.com ([209.85.218.211] [209.85.218.211]) by relay1i.sun.com with ESMTP id BT-MMP-12764564 for PSARC-ext@sun.com; Mon, 27 Jul 2009 06:56:31 +0000 (Z) Received: by bwz7 with SMTP id 7so2418538bwz.8 for ; Sun, 26 Jul 2009 23:55:46 -0700 (PDT) Received: by 10.204.55.201 with SMTP id v9mr2726638bkg.54.1248677746417; Sun, 26 Jul 2009 23:55:46 -0700 (PDT) Date: Mon, 27 Jul 2009 08:55:46 +0200 From: Cedric Blancher Subject: Re: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> To: Busybox development Cc: Korn Shell 93 integration/migration project discussion , John Sonnenschein , PSARC-ext@sun.com, James Carlson Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kbEtSKHh9BrLzGNLZ3BC/CEvQkMQa297oRVtoGwbQCQ=; b=E+0sJk1JatXIc46x9WM7IOE5Si/icxu4e2F1b3tvTXXgkcyDod3xKwQdOG+I/j75Zh K/u+K5KvzkrsaGdI5vgoXBtkBMU5VQhyfhpcl48IHVzkZoKxp/fZwXe2/sSRJ2v8ntWT LqLbSgnEA+HV6WqM9cimYOuSm+osrxemRFKCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LGxJNuyYvAGegvFpNcRgdyoMm6uHbLzy5fWUqldodyGG8uy3YTnOpUBdoAgZ1heSRn TKwrjGXejwoPG2dK84o0KWu9zvLC0Hw/HtORbDAIAd6/gHvZ+VX+y3RM61W0hcQUO/jj FAHNONUmrhHDCEKFhfoUwI8kQXsj486y6b6zU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 4.121sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> <4A6BE107.47F65A19@nrubsig.org> <4A6BE395.9060108@sun.com> <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> Status: RO Content-Length: 4217 On 26/07/2009, Jennifer Pioch wrote: > On 7/26/09, Garrett D'Amore wrote: > > Roland Mainz wrote: > > > > > John Sonnenschein wrote: > > > > > > > > > > On 25-Jul-09, at 4:59 PM, James Carlson wrote: > > > > > > > > > > > > > John Sonnenschein wrote: > > > > > > > > > > > > > > > > I've got a question about this... > > > > > > Whose responsibility is it to update the man pages and --man > > > > > > command then? The people whose jobs it is to update man pages, or > > > > > > the people whose jobs it is to update the command line utility? > > > > > > Basically if a new flag is added in the future for some reason, how > > > > > > will one synchronize the man pages? > > > > > > > > > > > > > > > > > Usually, that's done by filing a bug against the man pages. > > > > > > > > > > The advantage of keeping the documentation separate is that it's in > > > > > the hands of professional documentation writers, who are able to > > > > > keep a consistent style across all of the system man pages. > > > > > > > > > > I'm with Garrett about the inadvisability of baking man page > > > > > documentation into executables, but for ksh93-related things, I > > > > > think that ship has unfortunately sailed. > > > > > > > > > > > > > > Sure but for the sake of argument if we have some tools that have -- > > > > man and also man pages, does that mean that the docs people will be > > > > putting back to ON, > > > > > > > > > > > > > > Erm... why should the documentation people do putback into OS/Net ? The > > > strings used by getopts are used for argument parsing and are - as "nice > > > side-effect" - reused to generate the output for --help, --version, > > > --man etc. > > > > > > > > > > I have no objections to --version, --help. My concerns relate to --man, > > --nroff, and --html. > > > > > > > > > > > > > > or will there be a desynchronization between the > > > > man pages and the --man pages ? > > > > > > > > > > > > > > They _may_ be out-of-sync shortly after code putback if we add new > > > options to the |getopts()| string until the documentation folks caught > > > up with the code changes. But as I am trying to say over and over again > > > (and I am starting to feel _ignored_) that the output for --help, --man > > > etc. is generated from the getopts string template used for argument > > > parsing. This string is there to "drive" the argument parsing and is > > > absolutely the wrong place for Solaris-specific edits. We have a real, > > > seperate and maintained manual page for that purpose ([1]). > > > > > > > > > > Apparently the upstream disagrees with you. They (well Glenn) in fact > > *recommend* that the man page generated automatically from the --nroff > > output. > > > > > > > [1]=(And as said _several_ times that we could use a DocBook/XML manual > > > page as master source file shared between documentation and code folks > > > in the future from which both the Solaris manpage and the getopts string > > > can be generated from (this would eliminate all the "manpages > > > out-of-sync" concerns described in this thread)) > > > > > > > > > > That helps address some, but not all, of the concerns. You still wind up > > with the situation of two physical copies of the documentation on the media. > > > > This approach also seems not to match what the upstream suppliers seem to > > be saying... > > > > I rather strongly suspect that in the end we will be faced with one of two > > choices: > > > > 1) fork the code base and do what we feel is right for Solaris, or > > > Didn't you read what Roland wrote about the project rules? > > > in several major and unbreakable rules for this project which > > includes: > > - WE DO NOT FORK THE CODE > > - WE DO NOT BREAK THE KSH93 TEST SUITE > > - THE KSH93 TEST SUITE IS COMPLETELY OFF-LIMITS FOR CHANGES > > > If you are forking the code with such unnecessary changes I will NO > LONGER CONTRIBUTE to this or any other Opensolaris.org project. I will not contribute either if Sun forks the code. -- Cedric Blancher Institute Pasteur From piochjennifer@googlemail.com Mon Jul 27 02:05:51 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6R95pHx015437 for ; Mon, 27 Jul 2009 02:05:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6R95pse010600 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 02:05:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNF00D03NXQ6000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 02:05:50 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNF004X5NXQV030@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 02:05:50 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6R95nOc011747 for ; Mon, 27 Jul 2009 09:05:50 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-240135 for PSARC-ext@sun.com; Mon, 27 Jul 2009 09:05:49 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-11925232 for PSARC-ext@sun.com; Mon, 27 Jul 2009 09:05:45 +0000 (Z) Received: from mail-pz0-f189.google.com ([209.85.222.189] [209.85.222.189]) by relay1i.sun.com with ESMTP id BT-MMP-10027780 for PSARC-ext@sun.com; Mon, 27 Jul 2009 09:05:45 +0000 (Z) Received: by pzk27 with SMTP id 27so1131238pzk.30 for ; Mon, 27 Jul 2009 02:05:44 -0700 (PDT) Received: by 10.143.19.16 with SMTP id w16mr725401wfi.292.1248685544710; Mon, 27 Jul 2009 02:05:44 -0700 (PDT) Date: Mon, 27 Jul 2009 11:05:44 +0200 From: Jennifer Pioch Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: To: James Carlson Cc: Korn Shell 93 integration/migration project discussion , "PSARC-ext@sun.com" , "busybox-dev@opensolaris.org" Message-id: <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l8k1ZWTdjfFpAgNSkBqm+FfRna6e1v2zT8Ni9CrjrAs=; b=tNdzvHATC1CH9enKG54lvhDJOY3rc7AtHSiKjuZYW/IOBCO2cgB4xSfddvrOkzFKUb mhCRyAKb5+TbNAKrOibh6hc1gPzvOeFm+WvO9ez91HJRe4EtHwb4YD9SVOjYoNQnaiT1 xP2Tfg7bzPqzB/QnpU7P2mdjG+aO4hFgOJJa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BCXyxPmShsUVv77J5CBEr8dPjQJr3LVq+7SVBVEfb9l8VR8it83aTZv3ZkxgiNSS4A JiIKzQmzbf+EaNdEi6vSEqnG0LZH2hc69Ongi11ENUO0RKmA0Db+HEPUvF3Me3hwpOH0 vjU4RuYwvP8cvzwxEjgCvwFAyrv7NYsa8gzuk= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 4.164sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> Status: RO Content-Length: 1019 On 7/26/09, James Carlson wrote: > On Jul 26, 2009, at 9:44 AM, Jennifer Pioch > wrote: > > > > > > > On Wednesday at the PSARC meeting. Only regular PSARC members can vote. > > > > > > > Who elected the PSARC members? > > > > Nobody. Sun's CTO founded the ARC 19 years ago. So let me get this straight: Since 19 years there is a company-appointed group of grey bearded gurus from Shang Gri la who decides about the fate of projects. Is that correct? Don't you think this is undemocratic, unfair and contradicts the spirit and intention of OPEN source? Going even further: I think the current ARC business contradicts the fundamental believes behind OPEN source: Open source means that processes, procedures and groups are OPEN to everyone and not some company-appointed group. Open source projects are either driven by democracy or meritocracy and not some invitation-only club for the wealthy company grey beards. Jenny -- Jennifer Pioch, Uni Frankfurt From Alan.Hargreaves@sun.com Mon Jul 27 02:25:16 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6R9PFCP015621 for ; Mon, 27 Jul 2009 02:25:15 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6R9PC7G005864 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 10:25:14 +0100 (BST) 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 <0KNF0020FOU1VX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 02:25:13 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNF000Z7OTT7M20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 02:25:13 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6R9P5D1000782 for ; Mon, 27 Jul 2009 09:25:05 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNF00A00OQOLB00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 17:25:05 +0800 (SGT) Received: from [129.158.12.60] ([unknown] [129.158.12.60]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNF00N7ROTQ0OI0@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 17:25:05 +0800 (SGT) Date: Mon, 27 Jul 2009 19:24:00 +1000 From: Alan Hargreaves Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> Sender: Alan.Hargreaves@sun.com To: Jennifer Pioch Cc: James Carlson , Korn Shell 93 integration/migration project discussion , "PSARC-ext@sun.com" , "busybox-dev@opensolaris.org" Message-id: <4A6D7230.6050208@Sun.COM> MIME-version: 1.0 Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090706) Status: RO Content-Length: 3261

And if this was what PSARC did, you could be right. Unfortunately we are seeing a lot of sweeping generalisations being made here from grossly inadequate (and quite frankly some of it is incorrect) information.

If you want to see what the *actual* role of the ARCs with Solaris is, you should look at the ARC community pages at http://opensolaris.org/os/community/arc/

I would certainly suggest before condemning a process that folks should actually perhaps do a little research rather than work from hearsay.

 I will say from my experience of being a part of the process over the last five years is that the ARCs work harder to get things integrated rather than to kill projects. Indeed I can't think of the last time (if EVER) a project was killed by an ARC.

I can't put it any better than James Carlson did, ...

No "truce" is needed here, because there's no "battle."

Please.  Take a breath.  Perhaps two.  And then think about replying again.

Regards,
Alan Hargreaves
(A PSARC Intern)


Jennifer Pioch wrote: 
On 7/26/09, James Carlson <carlsonj@workingcode.com> wrote:
  
On Jul 26, 2009, at 9:44 AM, Jennifer Pioch <piochjennifer@googlemail.com>
wrote:


    
On Wednesday at the PSARC meeting.  Only regular PSARC members can vote.

        
Who elected the PSARC members?

      
 Nobody. Sun's CTO founded the ARC 19 years ago.
    

So let me get this straight: Since 19 years there is a
company-appointed group of grey bearded gurus from Shang Gri la who
decides about the fate of projects. Is that correct?

Don't you think this is undemocratic, unfair and contradicts the
spirit and intention of OPEN source? Going even further:
I think the current ARC business contradicts the fundamental believes
behind OPEN source:
Open source means that processes, procedures and groups are OPEN to
everyone and not some company-appointed group.
Open source projects are either driven by democracy or meritocracy and
not some invitation-only club for the wealthy company grey beards.

Jenny
  

-- 
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Asia Pacific/Emerging Markets
Sun Microsystems
From gsf@research.att.com Mon Jul 27 03:56:06 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6RAu6KH017185 for ; Mon, 27 Jul 2009 03:56:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6RAu23M046577; Mon, 27 Jul 2009 04:56:05 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNF00B01T1GC100@nwk-avmta-1.sfbay.Sun.COM>; Mon, 27 Jul 2009 03:56:04 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNF004SQT1GV0E0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 27 Jul 2009 03:56:04 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RAqxlR002972; Mon, 27 Jul 2009 10:56:03 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-354717; Mon, 27 Jul 2009 10:56:03 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-207323; Mon, 27 Jul 2009 10:56:00 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-13221346; Mon, 27 Jul 2009 10:55:59 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-blue.research.att.com (Postfix) with ESMTP id 6E824F0EA1; Mon, 27 Jul 2009 03:30:05 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6R7U330021722; Mon, 27 Jul 2009 03:30:03 -0400 Date: Mon, 27 Jul 2009 03:30:03 -0400 From: Glenn Fowler Subject: Re: [ksh93-integration-discuss] Some clarifications about "--help" and "--man" / Re: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: gdamore@sun.com, gsf@research.att.com Cc: busybox-dev@opensolaris.org, ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com, roland.mainz@nrubsig.org Message-id: <200907270730.n6R7U330021722@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 3.286sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <200907270249.n6R2nXqp017475@penguin.research.att.com> <4A6D2B30.2060105@sun.com> Status: RO Content-Length: 5771 there seems to be a reasonable understanding of issues on both sides I don't believe I have been misrepresented/misinterpreted to show that the ast side is not being bone-headed about not wanting to change, there is more to the ast upstream than is (or proposed to be) in solaris I don't expect this to weigh much either way for the ARC decision, but I think its important to understand motivation on the upstream side, which is basically a 3 person organization (the code authors) I just grep'd ~400 instances of ast optget self documentation which includes .c optget / .sh getopts usage strings, self-documenting library discipline/method routines (http://citeseerx.ist.psu.edu/search?q="The+discipline+and+method+architecture+for+reusable+libraries), and self-documenting plugins (runtime shared library discipline/method routines) if you can't tell by now the ast setup is, among other things, geared to minimize the work required by coders to maintain a working system by keeping code/documentation/configuration fairly localized e.g., when a new method or plugin (e.g., sum method, archive format, sort method) is added to ast it is self-contained and rarely requires a change to the corresponding utility wrapper there is no way that we could commit to a *vaporware* proposal of reworking the self-documentation which would impact the { source, build, packaging, installation, testing, l10n } steps in our software configuration to consider switching we would need: - a portable xml-whatever-to-whatever implementation - a way to automatically convert existing code to the proposed form - a way to handle both static and dynamic (runtime) documentation sources - a way to ensure that changes to the master source(s) make their way to build targets and all of this working in a posix conforming sandbox configuration but even then I don't know if its worth the effort on the ast side because it pretty much guarantess a disconnect between the command a user executes and the documentation shown by man on systems that provide multiple implementations of the same command (e.g., vendor vs xpg* vs gnu vs ast) here are two proposals (1) something similar already mentioned on the list(s) modify "man foo" to check for self-documenting foo this could be done by checking for e.g. some-dir/foo.sd and if found run foo --man 2>&1 nroff-magic some-dir/foo.sd where some-dir/foo.sd could contain solaris-specific sections not supplied by ast this would satisfy the upstream because man documentation would always be up to date (and it requires no source mods:), and the dowstream because it could append its own documentation requirements independent of the upstream (2) there is one #ifdef SOLARIS the upstream can consider the upstream will add and maintain code in libast that will intercept generic libast::optget() options objectionable to solaris and first fork/exec man and if that fails then emit the ast self-documentation; it will be up to the downstream to provide the man input and maintain consistency between that and the implementation; the man input could be generated by a mechanism similar to the man mods in (1) (hmm, just checked "man does-not-exist" on solaris 5.10 and it exits 0! failure detection would have to check man stdout for "No manual entry for ...") I don't care for (2) because it forks ast behavior between solaris vs non-solaris, but I also don't want to impede the progress roland has made -- Glenn Fowler -- at&t Research, Florham Park NJ -- On Sun, 26 Jul 2009 21:21:04 -0700 Garrett D'Amore wrote: > Glenn Fowler wrote: > > On Sun, 26 Jul 2009 16:00:57 -0700 Garrett D'Amore wrote: > >> Roland Mainz wrote: > >>> Alan Coopersmith wrote: > >>>> I'm sponsoring this fast-track request on behalf of the > >>>> ksh93-integration and busybox projects. The timeout is > >>>> set for Friday, July 31, 2009. > >>> [snip] > >>> Just to clarify (since both points have IMHO been either ignored or > >>> misinterpreted several times): > >>> 1. We do _not_ intent to remove or discontinue normal documentation, > >>> including manual pages (in fact I've been a long-term advocate of > >>> getting Solaris moved to DocBook/XML-based manual pages (including > >>> _shipping_ them as part of the installation instead of the nroff > >>> versions (that's why I even worked on a /usr/bin/man replacement > >>> codebase))). > >> I heard you. However, the upstream sources have *not* agreed with this > >> approach. > > you want upstream to agree to an approach that even solaris hasn't settled on yet? > Well that much is true (we've not settled yet) -- the decision *would* > have been good to have (either way), which is why I derailed it... I > felt that such a decision deserved explicit consideration rather than > coming in as an implementation detail. > That said... I received the following text in an e-mail message from you > (also delivered to the list): > in almost all other cases the optget() usage string *is* the man > page src, > and we have no intention of ever maintaining separate .1 man pages, > save the traditional exceptions for the long ones like sh(1) > if there are concerns about maintaining separate optget() usage strings > and .1 text files for ast commands on solaris, then I recommend > generating the man page from the --nroff output; > So while the question of a separate XML file wasn't specifically raised > and answered, I had taken the above text to indicate that you > (collectively as the ksh93 upstream) were also rejecting other schemes > to move this kind of documentation out of the cooked binary. > I'm sorry if I've misunderstood either you or Roland on this, or if I've > misapplied what you said. > - Garrett From Alan.Coopersmith@sun.com Mon Jul 27 07:15:11 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6REFAhp027024 for ; Mon, 27 Jul 2009 07:15:10 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6REF30G022120 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 15:15:09 +0100 (BST) 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 <0KNG00M0R298BJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:15:08 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG00JTE295JC70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:15:07 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6REF53Q006061 for ; Mon, 27 Jul 2009 07:15:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNG0090024WFF00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:15:05 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNG00B1U294BV00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:15:05 -0700 (PDT) Date: Mon, 27 Jul 2009 07:15:04 -0700 From: Alan Coopersmith Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> Sender: Alan.Coopersmith@sun.com To: Jennifer Pioch Cc: James Carlson , Korn Shell 93 integration/migration project discussion , "PSARC-ext@sun.com" , "busybox-dev@opensolaris.org" Message-id: <4A6DB668.9010705@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 731 Jennifer Pioch wrote: > So let me get this straight: Since 19 years there is a > company-appointed group of grey bearded gurus from Shang Gri la who > decides about the fate of projects. Is that correct? No. > Open source projects are either driven by democracy or meritocracy and > not some invitation-only club for the wealthy company grey beards. The ARC membership has been opened up, and external people are participating. It is a meritocracy, so it will take some time for external people to have put in the time required to merit full voting membership, but there is no reason to think that won't happen. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Mon Jul 27 07:25:32 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6REPV6g027094 for ; Mon, 27 Jul 2009 07:25:31 -0700 (PDT) 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 n6REPM9Q023861 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 22:25:30 +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 <0KNG00M012QHX600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:25:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG00JLB2QGJB70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:25:28 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6REPSIP006931 for ; Mon, 27 Jul 2009 07:25:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNG00F002FF9T00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:25:28 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNG00BFR2QDBV30@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 07:25:25 -0700 (PDT) Date: Mon, 27 Jul 2009 07:25:25 -0700 From: Alan Coopersmith Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> Sender: Alan.Coopersmith@sun.com To: John Sonnenschein Cc: James Carlson , "Garrett D'Amore" , ksh93-integration-discuss@opensolaris.org, Busybox development , PSARC-ext@sun.com Message-id: <4A6DB8D5.6010303@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> <4A6B9C4F.4090302@workingcode.com> <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 777 John Sonnenschein wrote: > Sure but for the sake of argument if we have some tools that have --man > and also man pages, does that mean that the docs people will be putting > back to ON, or will there be a desynchronization between the man pages > and the --man pages ? Hopefully the ON design flaw of keeping man pages in a separate tree will be fixed as part of the planned package refactoring after the move to IPS, in which man pages will be in the packages for the commands they document, like many of the other consolidations already do. That will allow atomic putbacks of changes with their documentation to reduce the odds of getting out of sync. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Neal.Pollack@sun.com Mon Jul 27 11:06:06 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6RI66VC006925 for ; Mon, 27 Jul 2009 11:06:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6RI667J013865 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 11:06:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNG00I09CY6ZW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 12:06:06 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG003YQCY1RUD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 12:06:06 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6RI61SQ004372 for ; Mon, 27 Jul 2009 11:06:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNG00D00CMY0V00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 11:06:01 -0700 (PDT) Received: from [10.1.48.130] ([unknown] [10.1.48.130]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNG00N42CXV4020@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 11:05:59 -0700 (PDT) Date: Mon, 27 Jul 2009 11:05:55 -0700 From: Neal Pollack Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6D7230.6050208@Sun.COM> Sender: Neal.Pollack@sun.com To: Alan Hargreaves Cc: Jennifer Pioch , James Carlson , Korn Shell 93 integration/migration project discussion , "PSARC-ext@sun.com" , "busybox-dev@opensolaris.org" Message-id: <4A6DEC83.9060407@Sun.Com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wrilYIz1VZvVY1wGYyij4A)" X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> <4A6D7230.6050208@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 9421 This is a multi-part message in MIME format. --Boundary_(ID_wrilYIz1VZvVY1wGYyij4A) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 07/27/09 02:24 AM, Alan Hargreaves wrote: > > And if this was what PSARC did, you could be right. Unfortunately we > are seeing a lot of sweeping generalisations being made here from > grossly inadequate (and quite frankly some of it is incorrect) > information. > > If you want to see what the *actual* role of the ARCs with Solaris is, > you should look at the ARC community pages at > http://opensolaris.org/os/community/arc/ > > I would certainly suggest before condemning a process that folks > should actually perhaps do a little research rather than work from > hearsay. > > I will say from my experience of being a part of the process over the > last five years is that the ARCs work harder to get things integrated > rather than to kill projects. Indeed I can't think of the last time > (if EVER) a project was killed by an ARC. > > I can't put it any better than James Carlson did, ... > > No "truce" is needed here, because there's no "battle." > > Please. Take a breath. Perhaps two. And then think about replying again. > +1 I constantly see too much tension between the emotional side and the logical side. Most people do not study the process very deeply before submitting an ARC case. So without that training or knowledge, all the replies are mis-interpreted on an emotional (normal human behavior lacking additional information) basis; - questions or feedback == attack or trying to block my project - derail == attack or trying to block my project. But if we first study the purpose and process of ARC, we translate to; - derail == we should schedule a meeting or vote and get some deeper consensus on this issue to ensure a quality solution - questions/feedback == attempts to seek consistency, quality, and perhaps deeper thinking of creative solutions by the dev team so that the project will have sound architectural foundation consistent with the rest of Solaris where possible. On the logical side, both of the above statements are routine design discussion, simple thought and collaboration processes. But in my 18 years here, I keep seeing far too much of the emotional side, which I suppose comes from a simple lack of understanding the purpose and process of ARC. Perhaps ARC needs to start holding an open meeting every other month that is simply a tutorial review of what ARC does, and what the terminology and lines of questions are for, and are trying to achieve? Neal > Regards, > Alan Hargreaves > (A PSARC Intern) > > > Jennifer Pioch wrote: >> On 7/26/09, James Carlson wrote: >> >>> On Jul 26, 2009, at 9:44 AM, Jennifer Pioch >>> wrote: >>> >>> >>> >>>>> On Wednesday at the PSARC meeting. Only regular PSARC members can vote. >>>>> >>>>> >>>> Who elected the PSARC members? >>>> >>>> >>> Nobody. Sun's CTO founded the ARC 19 years ago. >>> >> >> So let me get this straight: Since 19 years there is a >> company-appointed group of grey bearded gurus from Shang Gri la who >> decides about the fate of projects. Is that correct? >> >> Don't you think this is undemocratic, unfair and contradicts the >> spirit and intention of OPEN source? Going even further: >> I think the current ARC business contradicts the fundamental believes >> behind OPEN source: >> Open source means that processes, procedures and groups are OPEN to >> everyone and not some company-appointed group. >> Open source projects are either driven by democracy or meritocracy and >> not some invitation-only club for the wealthy company grey beards. >> >> Jenny >> > > -- > Alan Hargreaves - http://blogs.sun.com/tpenta > Staff Engineer (Kernel/VOSJEC/Performance) > Asia Pacific/Emerging Markets > Sun Microsystems > --Boundary_(ID_wrilYIz1VZvVY1wGYyij4A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 07/27/09 02:24 AM, Alan Hargreaves wrote:

And if this was what PSARC did, you could be right. Unfortunately we are seeing a lot of sweeping generalisations being made here from grossly inadequate (and quite frankly some of it is incorrect) information.

If you want to see what the *actual* role of the ARCs with Solaris is, you should look at the ARC community pages at http://opensolaris.org/os/community/arc/

I would certainly suggest before condemning a process that folks should actually perhaps do a little research rather than work from hearsay.

 I will say from my experience of being a part of the process over the last five years is that the ARCs work harder to get things integrated rather than to kill projects. Indeed I can't think of the last time (if EVER) a project was killed by an ARC.

I can't put it any better than James Carlson did, ...

No "truce" is needed here, because there's no "battle."

Please.  Take a breath.  Perhaps two.  And then think about replying again.

+1

I constantly see too much tension between the emotional side and the logical side.
Most people do not study the process very deeply before submitting an ARC case.
So without that training or knowledge, all the replies are mis-interpreted on an
emotional (normal human behavior lacking additional information) basis;

- questions or feedback == attack or trying to block my project
- derail == attack or trying to block my project.

But if we first study the purpose and process of ARC, we translate to;

- derail == we should schedule a meeting or vote and get some deeper
  consensus on this issue to ensure a quality solution

- questions/feedback  == attempts to seek consistency, quality, and perhaps
   deeper thinking of creative solutions by the dev team so that the project
   will have sound architectural foundation consistent with the rest of
   Solaris where possible.

On the logical side, both of the above statements are routine design discussion,
simple thought and collaboration processes.  But in my 18 years here, I keep
seeing far too much of the emotional side, which I suppose comes from a simple
lack of understanding the purpose and process of ARC.

Perhaps ARC needs to start holding an open meeting every other month that
is simply a tutorial review of what ARC does, and what the terminology
and lines of questions are for, and are trying to achieve?

Neal

Regards,
Alan Hargreaves
(A PSARC Intern)


Jennifer Pioch wrote: 
On 7/26/09, James Carlson <carlsonj@workingcode.com> wrote:
  
On Jul 26, 2009, at 9:44 AM, Jennifer Pioch <piochjennifer@googlemail.com>
wrote:


    
On Wednesday at the PSARC meeting.  Only regular PSARC members can vote.

        
Who elected the PSARC members?

      
 Nobody. Sun's CTO founded the ARC 19 years ago.
    

So let me get this straight: Since 19 years there is a
company-appointed group of grey bearded gurus from Shang Gri la who
decides about the fate of projects. Is that correct?

Don't you think this is undemocratic, unfair and contradicts the
spirit and intention of OPEN source? Going even further:
I think the current ARC business contradicts the fundamental believes
behind OPEN source:
Open source means that processes, procedures and groups are OPEN to
everyone and not some company-appointed group.
Open source projects are either driven by democracy or meritocracy and
not some invitation-only club for the wealthy company grey beards.

Jenny
  

-- 
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Asia Pacific/Emerging Markets
Sun Microsystems

--Boundary_(ID_wrilYIz1VZvVY1wGYyij4A)-- From gdamore@sun.com Mon Jul 27 11:24:36 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6RIOZic007382 for ; Mon, 27 Jul 2009 11:24:36 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6RIOLEv028215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 19:24:35 +0100 (BST) 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 <0KNG00E17DSVZI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 11:24:31 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG00DXKDSVF400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 11:24:31 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6RIOVnL006690 for ; Mon, 27 Jul 2009 11:24:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNG00C00DI8AD00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 11:24:30 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNG004Z3DSTEFB0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 11:24:30 -0700 (PDT) Date: Mon, 27 Jul 2009 11:24:29 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6DEC83.9060407@Sun.Com> Sender: Garrett.Damore@sun.com To: Neal Pollack Cc: Alan Hargreaves , Jennifer Pioch , James Carlson , Korn Shell 93 integration/migration project discussion , "PSARC-ext@sun.com" , "busybox-dev@opensolaris.org" Message-id: <4A6DF0DD.2060003@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> <4A6D7230.6050208@Sun.COM> <4A6DEC83.9060407@Sun.Com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7043 Neal Pollack wrote: > On 07/27/09 02:24 AM, Alan Hargreaves wrote: >> >> And if this was what PSARC did, you could be right. Unfortunately we >> are seeing a lot of sweeping generalisations being made here from >> grossly inadequate (and quite frankly some of it is incorrect) >> information. >> >> If you want to see what the *actual* role of the ARCs with Solaris >> is, you should look at the ARC community pages at >> http://opensolaris.org/os/community/arc/ >> >> I would certainly suggest before condemning a process that folks >> should actually perhaps do a little research rather than work from >> hearsay. >> >> I will say from my experience of being a part of the process over >> the last five years is that the ARCs work harder to get things >> integrated rather than to kill projects. Indeed I can't think of the >> last time (if EVER) a project was killed by an ARC. >> >> I can't put it any better than James Carlson did, ... >> >> No "truce" is needed here, because there's no "battle." >> >> Please. Take a breath. Perhaps two. And then think about replying again. >> > > +1 > > I constantly see too much tension between the emotional side and the > logical side. > Most people do not study the process very deeply before submitting an > ARC case. > So without that training or knowledge, all the replies are > mis-interpreted on an > emotional (normal human behavior lacking additional information) basis; > > - questions or feedback == attack or trying to block my project > - derail == attack or trying to block my project. > > But if we first study the purpose and process of ARC, we translate to; > > - derail == we should schedule a meeting or vote and get some deeper > consensus on this issue to ensure a quality solution > > - questions/feedback == attempts to seek consistency, quality, and > perhaps > deeper thinking of creative solutions by the dev team so that the > project > will have sound architectural foundation consistent with the rest of > Solaris where possible. > > On the logical side, both of the above statements are routine design > discussion, > simple thought and collaboration processes. But in my 18 years here, > I keep > seeing far too much of the emotional side, which I suppose comes from > a simple > lack of understanding the purpose and process of ARC. > > Perhaps ARC needs to start holding an open meeting every other month that > is simply a tutorial review of what ARC does, and what the terminology > and lines of questions are for, and are trying to achieve? I don't know about every other month, but having a preso, with explanations and archived slides, every so often, would not be a bad idea. I know Plocher had some of this, although I've not reviewed it recently to see how current it is, and whether its in a format that non-Sun folks can readily consume. This would be a nice project for some enterprising Intern to look into... (hint hint). I still want to get a regular full member on PSARC who is not a Sun employee. (Ideally more than one of them, but right now we have only one Intern.) So let me state right up front -- almost anyone can volunteer to be an Intern, which is a mandatory step before becoming a full PSARC member. I'd *really* like to see more external Interns (right now we only have Mark Martin, and I don't think he's going to remain an Intern much longer... he's on track for Membership.) At ARC we have some 'technology' issues which are making it hard for non-Sun parties to participate, but we can work around those for now. In the meantime, I'd like to invite anyone who thinks they can contribute meaningfully to present themselves as an Intern. Here's what you should expect as a PSARC participant: * discussions centered around technical and architectural issues * healthy constructive debate -- you must not be afraid to raise issues and can't be a shy person * a desire to be helpful -- we are frequently asked to help project teams through the process, and this means being able to work with folks who may not know the process * however, no debate or criticism for its "own" sake -- members don't go around looking for fights * members and interns should have some significant visibility in the community as a technical contributor (hanging out on mailing lists and answering questions doesn't count here -- PSARC is made up -- currently -- of software engineering folks) * willingness to spend a few hours a week on PSARC. interns should expect to spend at most about 4 hours (and I think most spend far far less than that) and members up to 8 hours (but I've yet to spend that much time) on PSARC. In reality I think I get away with about 2-4 hours a week, and I do more than most because I'm also the PSARC co-chair. * ability to be on the phone or in person at PSARC meetings -- they take place at 10am PDT on Wednesdays * a true belief in the value of the process as a tool to improve the quality of what is delivered into OpenSolaris * a certain amount of willingness to deal with administrivia and paperwork -- Interns are often selected to write opinions and help out with the paperwork for other cases Most of the same things apply to LSARC as well, (I think the only thing that is different is the meeting time.) Anyone who thinks they fit the qualifications and is interested in this should probably e-mail either me directly, or contact another PSARC member. (Internal candidates can send mail to psarc-chair at sun dot com -- I'm not sure whether that e-mail alias is accessible externally though.) - Garrett > > Neal > >> Regards, >> Alan Hargreaves >> (A PSARC Intern) >> >> >> Jennifer Pioch wrote: >>> On 7/26/09, James Carlson wrote: >>> >>>> On Jul 26, 2009, at 9:44 AM, Jennifer Pioch >>>> wrote: >>>> >>>> >>>> >>>>>> On Wednesday at the PSARC meeting. Only regular PSARC members can vote. >>>>>> >>>>>> >>>>> Who elected the PSARC members? >>>>> >>>>> >>>> Nobody. Sun's CTO founded the ARC 19 years ago. >>>> >>> >>> So let me get this straight: Since 19 years there is a >>> company-appointed group of grey bearded gurus from Shang Gri la who >>> decides about the fate of projects. Is that correct? >>> >>> Don't you think this is undemocratic, unfair and contradicts the >>> spirit and intention of OPEN source? Going even further: >>> I think the current ARC business contradicts the fundamental believes >>> behind OPEN source: >>> Open source means that processes, procedures and groups are OPEN to >>> everyone and not some company-appointed group. >>> Open source projects are either driven by democracy or meritocracy and >>> not some invitation-only club for the wealthy company grey beards. >>> >>> Jenny >>> >> >> -- >> Alan Hargreaves - http://blogs.sun.com/tpenta >> Staff Engineer (Kernel/VOSJEC/Performance) >> Asia Pacific/Emerging Markets >> Sun Microsystems >> > From carlsonj@workingcode.com Mon Jul 27 12:44:56 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6RJit6Q013209 for ; Mon, 27 Jul 2009 12:44:56 -0700 (PDT) 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 n6RJioRV002885; Tue, 28 Jul 2009 03:44:51 +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 <0KNG00K0DHIP6400@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Jul 2009 12:44:49 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG00DCOHIPFH60@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Jul 2009 12:44:49 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RJcXeC005305; Mon, 27 Jul 2009 19:44:49 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-395746; Mon, 27 Jul 2009 19:44:48 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-423879; Mon, 27 Jul 2009 19:44:47 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-11180406; Mon, 27 Jul 2009 19:44:46 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n6RJhvfl024924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 15:43:57 -0400 (EDT) Date: Mon, 27 Jul 2009 15:43:57 -0400 From: James Carlson Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6DF0DD.2060003@sun.com> To: "Garrett D'Amore" Cc: Neal Pollack , Alan Hargreaves , Jennifer Pioch , Korn Shell 93 integration/migration project discussion , "PSARC-ext@sun.com" , "busybox-dev@opensolaris.org" Message-id: <4A6E037D.8080402@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-URT-Metrics: carlson 1060; Body=7 Fuz1=7 Fuz2=7 X-Antispam: No, score=0.0/5.0, scanned in 0.221sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> <4A6D7230.6050208@Sun.COM> <4A6DEC83.9060407@Sun.Com> <4A6DF0DD.2060003@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1273 Garrett D'Amore wrote: > In the meantime, I'd like to invite anyone who thinks they can > contribute meaningfully to present themselves as an Intern. Here's what > you should expect as a PSARC participant: That's a pretty good list. I'd add to it: * an understanding and acceptance that the ARC is explicitly and intentionally _not_ a representative body, and that your participation in it is expected to be for the good of all of OpenSolaris engineering, and not as an ambassador for your project / technology / product / company. If you want such a role, you'll need to look elsewhere. It's crucially important that all ARC participants understand this issue. As soon as any of those people start behaving as 'advocates' rather than as technical reviewers, the process falls apart. In fact, a "good" intern will question projects with which he has some affiliation much more carefully and critically than others. It's generally seen as a good quality if interns are as broad as possible, and this is also why there are intentionally no rules requiring recusal. (We've had to take administrative action in the past in order to ensure this outcome, and it's never a pleasant thing.) -- James Carlson 42.703N 71.076W From dcragun@sonic.net Mon Jul 27 12:50:33 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6RJoWUO013263 for ; Mon, 27 Jul 2009 12:50:33 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6RJoTsu022254; Mon, 27 Jul 2009 20:50:31 +0100 (BST) 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 <0KNG00K03HS6IY00@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Jul 2009 12:50:30 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG00DEGHS5FC50@nwk-avmta-2.sfbay.sun.com>; Mon, 27 Jul 2009 12:50:29 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RJfYnY017681; Mon, 27 Jul 2009 19:50:28 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-171079; Mon, 27 Jul 2009 19:50:28 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-10393782; Mon, 27 Jul 2009 19:50:22 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-7895885; Mon, 27 Jul 2009 19:49:30 +0000 (Z) Received: from webmail.sonic.net (a.webmail.sonic.net [64.142.100.132]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n6RJmelK011421; Mon, 27 Jul 2009 12:48:40 -0700 Received: from 76.191.129.144 (SquirrelMail authenticated user dcragun) by webmail.sonic.net with HTTP; Mon, 27 Jul 2009 12:48:40 -0700 (PDT) Date: Mon, 27 Jul 2009 12:48:40 -0700 (PDT) From: Don Cragun Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] To: gdamore@sun.com Cc: ksh93-integration-discuss@opensolaris.org, busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <20970.76.191.129.144.1248724120.squirrel@webmail.sonic.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 5.565sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ User-Agent: SquirrelMail/1.4.9a Status: RO Content-Length: 2032 On Mon, 27 Jul 2009 11:24:29, Garrett D'Amore wrote: ... ... ... > So let me state right up front -- almost anyone can volunteer to be an > Intern, which is a mandatory step before becoming a full PSARC member. > I'd *really* like to see more external Interns (right now we only have > Mark Martin, and I don't think he's going to remain an Intern much > longer... he's on track for Membership.) Garrett, Actually, you have two external interns (Mark and me). I doubt, however, that I'm on track to become a full member. > > At ARC we have some 'technology' issues which are making it hard for > non-Sun parties to participate, but we can work around those for now. The following "technology issues" have been making it hard for non-Sun parties to participate for more than six months: 1. The posted meeting agenda for external participants ( http://www.opensolaris.org/os/community/arc/announcements/ ) is over a week old by the time PSARC meets. Some fast track cases on the agenda have been closed before the meeting starts; some cases are discussed that are not on the agenda. This week's agenda shows that one full case is to be discussed, but I believe a second case has been added. 2. External interns and members can't add case materials to the case directories except into the mail log without physical help from an internal member, intern, licensee, or administrative staff. (This is especially a nuisance when trying to add issues to the issues file for an upcoming case.) 3. Issues files for full cases are frequently updated by internal participants just before or even during the meeting. External participants frequently aren't able to see these comments until hours after the meeting has concluded. 4. Some half-duplex phones being used on some of the calls effectively block all input from other people trying to participate over the phone. Are there any plans (or even proposals) for fixing the known list of technology issues? ... ... ... Cheers, Don From gdamore@sun.com Mon Jul 27 13:00:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6RK0bP0014009 for ; Mon, 27 Jul 2009 13:00:37 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6RK0SXK027353 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 21:00:36 +0100 (BST) 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 <0KNG00709I8ZMA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 14:00:35 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG00MLEI8ZTDA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 14:00:35 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6RK0YL9018306 for ; Mon, 27 Jul 2009 13:00:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNG00C00I7U5T00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 13:00:34 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNG00MEZI8Y6EC0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 13:00:34 -0700 (PDT) Date: Mon, 27 Jul 2009 13:00:34 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <20970.76.191.129.144.1248724120.squirrel@webmail.sonic.net> Sender: Garrett.Damore@sun.com To: Don Cragun Cc: ksh93-integration-discuss@opensolaris.org, busybox-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6E0762.9010308@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20970.76.191.129.144.1248724120.squirrel@webmail.sonic.net> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3678 Don Cragun wrote: > On Mon, 27 Jul 2009 11:24:29, Garrett D'Amore wrote: > ... ... ... > >> So let me state right up front -- almost anyone can volunteer to be an >> Intern, which is a mandatory step before becoming a full PSARC member. >> I'd *really* like to see more external Interns (right now we only have >> Mark Martin, and I don't think he's going to remain an Intern much >> longer... he's on track for Membership.) >> > > Garrett, > Actually, you have two external interns (Mark and me). I doubt, however, > that I'm on track to become a full member. > > >> At ARC we have some 'technology' issues which are making it hard for >> non-Sun parties to participate, but we can work around those for now. >> > > The following "technology issues" have been making it hard for non-Sun > parties to participate for more than six months: > 1. The posted meeting agenda for external participants ( > http://www.opensolaris.org/os/community/arc/announcements/ ) is over > a week old by the time PSARC meets. Some fast track cases on the > agenda have been closed before the meeting starts; some cases are > discussed that are not on the agenda. This week's agenda shows that > one full case is to be discussed, but I believe a second case has been added. > That should be easy to fix. Let me see if we can get that done in the next week or so -- even if it requires someone manually synchronizing the agenda. > 2. External interns and members can't add case materials to the case > directories except into the mail log without physical help from an internal > member, intern, licensee, or administrative staff. (This is especially a > nuisance when trying to add issues to the issues file for an upcoming case.) > Yes, its a real annoyance. Fixing this is probably not "trivial"... for now the mail log and involvement of PSARC staff will have to do. I hope to replace the whole infrastructure at some point with something that works better for external members. The process of figuring out how to do this has not even seriously started the investigation phase yet. > 3. Issues files for full cases are frequently updated by internal participants > just before or even during the meeting. External participants frequently > aren't able to see these comments until hours after the meeting has > > concluded. > Hmm... that's annoying. I wonder if we can do something to trigger an update to mirror this automatically. > 4. Some half-duplex phones being used on some of the calls effectively block > all input from other people trying to participate over the phone. > Really? I've not had a problem, and I use the same remote dial-in code that other people use. However, maybe we can deal with this procedurally. In the past the meetings have been rather free form, but maybe more structure would be desirable... one way would be to require a speaker to recognized by the chair. Doing this over the phone is challenging, but if we could involve IRC side band, then at least OOB notifications could be used. I'll bring this up at the next meeting just to get other members thinking about the problem. > Are there any plans (or even proposals) for fixing the known list of technology > issues? > I put the technology issues on the agenda for a members-only discussion for both PSARC and LSARC last week. Asa is still working on scheduling this, I believe. One of the higher priorities I have taken upon myself as PSARC chair is to make some forward progress on this before my 3 month tenure is up. - Garrett > ... ... ... > > Cheers, > Don > > > From Alan.Coopersmith@sun.com Mon Jul 27 14:13:00 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6RLCxw4017413 for ; Mon, 27 Jul 2009 14:13:00 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6RLCshh013506 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Jul 2009 22:12:59 +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 <0KNG00D09LLMI800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 14:12:58 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNG00C9XLLL9U10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 14:12:57 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6RLCvvW026905 for ; Mon, 27 Jul 2009 14:12:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNG00M00LE2RW00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 14:12:57 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNG005O8LLLOZ70@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 14:12:57 -0700 (PDT) Date: Mon, 27 Jul 2009 14:12:57 -0700 From: Alan Coopersmith Subject: Re: [busybox-dev] AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-reply-to: <4A6B4E91.6020002@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: Roland Mainz , Busybox development , ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <4A6E1859.8060901@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> <4A6A9FCF.5020100@sun.com> <4A6B3970.2000400@sun.com> <4A6B4E91.6020002@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 4748 [Combining responses to multiple subthreads to try to reduce mail load.] Garrett D'Amore wrote: >>> 4) Furthermore, the --man output doesn't reflect standards required for >>> Sun man pages. For example, there is no >>> ATTRIBUTES table. >>> >> >> That's a good reason why there should also be a traditional man page, and >> --man shouldn't replace it, just supplement it. >> > > Your response here conflicts with your response to point #3 above. > Either we have one canonical copy of the documentation that should > always be correct and maintained, or we risk having the two copies get > out of sync or become inaccurate. Which should it be? We've always had to manage the risk of getting out of sync between the implementation, the built-in help, the man pages, docs.sun.com, and other forms of documentation. --man is just another way of formatting the built-in help, so doesn't add any more risk there. If this option had been called "--verbose-help" or "--help-me-more", would you be objecting as much as you are? Is it just the confusion of the "built-in help formatted like man" vs. an actual man page that worries you? > Yes, I believe in tight code. Yes I believe memory should still be > treated as a precious resource. No, I don't think it is unreasonable to > ask to be able to use an operating system with 128 MB of RAM. That's certainly reasonable for operating systems which have accepted that limit. The one we're discussing here though, has not, so that doesn't apply. The current documented minimum RAM for OpenSolaris (and thus likely Solaris.Next) are 512mb. The current documented minimum RAM for Solaris 10 is 384mb for UFS root, 768mb for ZFS root. [1] [1] http://docs.sun.com/app/docs/doc/820-7273/installbugs-113?a=view >> Translators don't have to translate every string in the application. > > Since when? I thought that pretty much every human interaction had to > be l10n'd in order to be qualified as localized. This is the first time > I've heard of "partially" localizing an application. Are there any > other precedents for this? Since gettext() and catgets() were invented. In practice, this happens every time someone adds a string to a localized application, as that string is not translated instantly, but in the next update of translated strings. As a whole, Solaris has always been only partially localized, and never claimed to be, attempted to be, or aspired to be fully localized. Some portions were fairly fully localized in the past, but that is an ever smaller portion of the OS in recent years, due to the combination of budget shrinking while the content included continues to grow. >> Will your opinion text also recommend to the PAC that they delete all >> the admin guides, user guides, and all other docs other than the man >> pages from the Solaris documentation and docs.sun.com because they are >> multiple copies of the same information? >> > > No, because of two reasons: > > 1) the "man pages" are sourced by the same process and originate from > the same text No, the other documents are very different text, with different processes for creating and updating them. For an example from the small part of the OS you're most familiar with, there is a huge difference between the text in the "Writing Device Drivers" guide and the section 7 man pages - as there should be since they are different sorts of documents - tutorial vs. reference. When you update the DDI, you need to make sure both are updated - just filing a man page bug won't change the device drivers guide unless the human who processes your bug notices for you that you forgot to request updates to both. > 2) those bits are not delivered to the end-users on the media We have delivered documentation CD's in the past with those bits on, and once upon a time, even printed copies of them in the boxes with the media. We do deliver some documentation on the media other than man pages - built in help in GUI applications, the "Getting Started" guide, the GNU info docs, all the files in /usr/share/doc/, and so on. > Of course, if you want to add some text to the potential opinion (which > may or may not be a minority opinion), feel free to send me draft text > after the vote. "The majority feels that the minority belief that there should be exactly one canonical source of documentation for any portion of the system, and that all others be removed, is contrary to both the long standing Solaris implementation history and recognized industry best practice, and a dangerous reduction of Solaris usability, with little measurable benefit." -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Jyri.Virkki@sun.com Mon Jul 27 20:32:22 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6S3WL9A001906 for ; Mon, 27 Jul 2009 20:32:22 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6S3WILk016047 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 04:32:21 +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 <0KNH00M0335WVA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 20:32:20 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00MKM35VF980@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 20:32:19 -0700 (PDT) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6S3VkxY012092; Tue, 28 Jul 2009 03:31:46 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n6S3Vje13423; Mon, 27 Jul 2009 20:31:46 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n6S3Vjok016339; Mon, 27 Jul 2009 20:31:45 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n6S3VjLR016338; Mon, 27 Jul 2009 20:31:45 -0700 (PDT) Date: Mon, 27 Jul 2009 20:31:45 -0700 From: Jyri Virkki Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6CE4CF.A3692F8E@nrubsig.org> To: Roland Mainz Cc: Busybox development , PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org Message-id: <20090728033144.GB4724@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1244 Roland Mainz wrote: > > Ok... I really tried to mediate a way though this but it seems we're > stuck and right now it looks we're getting too much damage... > > ... here hereby _withdraw_ this ARC case. I'm only an observer on this case, but I am an ARC member so have some context.. While withdrawing a case is certainly your call, it would be unfortunate if it is - as it seems from the choice of your words above - due only to some confusion on ARC process terminology. Please note nothing is "stuck" and there is no "damage". People expressing opinions on a mailing list is not damage. None of it is binding. At a high level[1], "derail" only means the case will be talked about at the next (or chosen) meeting and voted on. That, and Garrett generated some work for himself due to having to write an opinion summarizing what went on. That's all. Procedurally the vote can result in a Deny but historically that is unlikely[2] so taking action based on something that has not happened is quite premature. [1] For the full details there's always: http://www.opensolaris.org/os/community/arc/ [2] "Past Performance is No Guarantee of Future Results". But often it is. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Jyri.Virkki@sun.com Mon Jul 27 20:32:22 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6S3WL9A001906 for ; Mon, 27 Jul 2009 20:32:22 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6S3WILk016047 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 04:32:21 +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 <0KNH00M0335WVA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 20:32:20 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00MKM35VF980@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 20:32:19 -0700 (PDT) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6S3VkxY012092; Tue, 28 Jul 2009 03:31:46 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n6S3Vje13423; Mon, 27 Jul 2009 20:31:46 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n6S3Vjok016339; Mon, 27 Jul 2009 20:31:45 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n6S3VjLR016338; Mon, 27 Jul 2009 20:31:45 -0700 (PDT) Date: Mon, 27 Jul 2009 20:31:45 -0700 From: Jyri Virkki Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6CE4CF.A3692F8E@nrubsig.org> To: Roland Mainz Cc: Busybox development , PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org Message-id: <20090728033144.GB4724@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> User-Agent: Mutt/1.5.11 x_sac_archived: PSARC/2009/414 Status: RO Content-Length: 1244 Roland Mainz wrote: > > Ok... I really tried to mediate a way though this but it seems we're > stuck and right now it looks we're getting too much damage... > > ... here hereby _withdraw_ this ARC case. I'm only an observer on this case, but I am an ARC member so have some context.. While withdrawing a case is certainly your call, it would be unfortunate if it is - as it seems from the choice of your words above - due only to some confusion on ARC process terminology. Please note nothing is "stuck" and there is no "damage". People expressing opinions on a mailing list is not damage. None of it is binding. At a high level[1], "derail" only means the case will be talked about at the next (or chosen) meeting and voted on. That, and Garrett generated some work for himself due to having to write an opinion summarizing what went on. That's all. Procedurally the vote can result in a Deny but historically that is unlikely[2] so taking action based on something that has not happened is quite premature. [1] For the full details there's always: http://www.opensolaris.org/os/community/arc/ [2] "Past Performance is No Guarantee of Future Results". But often it is. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Alan.Coopersmith@Sun.COM Mon Jul 27 21:46:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6S4kkDX002828 for ; Mon, 27 Jul 2009 21:46:47 -0700 (PDT) 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 n6S4kjGx023448 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 12:46:45 +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 <0KNH00F096LWEK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00F126LWDD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6S4kioT027384 for ; Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNH008006B41100@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNH002MB6LVGBB0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Date: Mon, 27 Jul 2009 21:46:43 -0700 From: Alan Coopersmith Subject: Re: PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <20090728033144.GB4724@sun.com> Sender: Alan.Coopersmith@Sun.COM To: Jyri Virkki Cc: Roland Mainz , Busybox development , PSARC-ext@Sun.COM, ksh93-integration-discuss@opensolaris.org Message-id: <4A6E82B3.3090300@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2254 Jyri Virkki wrote: > Roland Mainz wrote: >> Ok... I really tried to mediate a way though this but it seems we're >> stuck and right now it looks we're getting too much damage... >> >> ... here hereby _withdraw_ this ARC case. > > I'm only an observer on this case, but I am an ARC member so have some > context.. > > While withdrawing a case is certainly your call, it would be > unfortunate if it is - as it seems from the choice of your words above - > due only to some confusion on ARC process terminology. > > Please note nothing is "stuck" and there is no "damage". > > People expressing opinions on a mailing list is not damage. None of it > is binding. Correct. As the case owner, I haven't marked the case withdrawn since the request to do so seems based on a misunderstanding. One ARC member has asked to call for a vote on whether the case should be approved as is, or approved with a change to remove the --man/--html/-nroff options. So far, I have not seen any other voting ARC members agree that such a change should be required. I have seen no one suggest that the case be denied in any form, just possibly required to be modified. The only way this project is "stuck" is if the project team decides to stop where they are instead instead of letting this case go forward. The only way this project is "damaged" is if the project team decides to go off and make changes before finding out what the ARC requires. Frankly, if you implemented the #ifdef SOLARIS changes Garrett required, I'd call for the ARC to require you to remove them as introducing unnecessary incompatibilities with other platforms, reducing familiarity and increasing the cost of ongoing maintenance in having to keep those patches up to date. This question needs to be resolved, and sooner is better than later, so we all know what the path forward is and can stop wasting time debating it and go do it. Deferring the question to the next ksh93 ARC case just increases the uncertainty of that case, and the anxiety of the people working on it, and doesn't change the basic question of whether a change to the design is needed or not. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@Sun.COM Mon Jul 27 21:46:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6S4kkDX002828 for ; Mon, 27 Jul 2009 21:46:47 -0700 (PDT) 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 n6S4kjGx023448 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 12:46:45 +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 <0KNH00F096LWEK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00F126LWDD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6S4kioT027384 for ; Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNH008006B41100@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNH002MB6LVGBB0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Jul 2009 21:46:44 -0700 (PDT) Date: Mon, 27 Jul 2009 21:46:43 -0700 From: Alan Coopersmith Subject: Re: PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <20090728033144.GB4724@sun.com> Sender: Alan.Coopersmith@Sun.COM To: Jyri Virkki Cc: Roland Mainz , Busybox development , PSARC-ext@Sun.COM, ksh93-integration-discuss@opensolaris.org Message-id: <4A6E82B3.3090300@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) x_sac_archived: PSARC/2009/414 Status: RO Content-Length: 2254 Jyri Virkki wrote: > Roland Mainz wrote: >> Ok... I really tried to mediate a way though this but it seems we're >> stuck and right now it looks we're getting too much damage... >> >> ... here hereby _withdraw_ this ARC case. > > I'm only an observer on this case, but I am an ARC member so have some > context.. > > While withdrawing a case is certainly your call, it would be > unfortunate if it is - as it seems from the choice of your words above - > due only to some confusion on ARC process terminology. > > Please note nothing is "stuck" and there is no "damage". > > People expressing opinions on a mailing list is not damage. None of it > is binding. Correct. As the case owner, I haven't marked the case withdrawn since the request to do so seems based on a misunderstanding. One ARC member has asked to call for a vote on whether the case should be approved as is, or approved with a change to remove the --man/--html/-nroff options. So far, I have not seen any other voting ARC members agree that such a change should be required. I have seen no one suggest that the case be denied in any form, just possibly required to be modified. The only way this project is "stuck" is if the project team decides to stop where they are instead instead of letting this case go forward. The only way this project is "damaged" is if the project team decides to go off and make changes before finding out what the ARC requires. Frankly, if you implemented the #ifdef SOLARIS changes Garrett required, I'd call for the ARC to require you to remove them as introducing unnecessary incompatibilities with other platforms, reducing familiarity and increasing the cost of ongoing maintenance in having to keep those patches up to date. This question needs to be resolved, and sooner is better than later, so we all know what the path forward is and can stop wasting time debating it and go do it. Deferring the question to the next ksh93 ARC case just increases the uncertainty of that case, and the anxiety of the people working on it, and doesn't change the basic question of whether a change to the design is needed or not. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gsf@research.att.com Tue Jul 28 07:19:00 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SEJ0JI021624 for ; Tue, 28 Jul 2009 07:19:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6SEIxvw010979; Tue, 28 Jul 2009 07:19:00 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNH00509X3NRS00@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Jul 2009 07:18:59 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00HRCX3NVVB0@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Jul 2009 07:18:59 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6SE9tMg025720; Tue, 28 Jul 2009 14:18:59 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-347253; Tue, 28 Jul 2009 14:18:57 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-584620; Tue, 28 Jul 2009 14:18:54 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-16148784; Tue, 28 Jul 2009 14:08:46 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id 507A38534; Tue, 28 Jul 2009 10:07:48 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6SE7mYR027316; Tue, 28 Jul 2009 10:07:48 -0400 Date: Tue, 28 Jul 2009 10:07:48 -0400 From: Glenn Fowler Subject: Re: [busybox-dev] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] To: busybox-dev@opensolaris.org, Jyri.Virkki@sun.com Cc: ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <200907281407.n6SE7mYR027316@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.087sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> Status: RO Content-Length: 579 On Mon, 27 Jul 2009 21:46:43 -0700 Alan Coopersmith wrote: > The only way this project is "damaged" is if the project team decides to > go off and make changes before finding out what the ARC requires. > Frankly, if you implemented the #ifdef SOLARIS changes Garrett required, > I'd call for the ARC to require you to remove them as introducing > unnecessary incompatibilities with other platforms, reducing familiarity > and increasing the cost of ongoing maintenance in having to keep those > patches up to date. no codes were harmed during the production of these messages From gsf@research.att.com Tue Jul 28 07:19:00 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SEJ0JI021624 for ; Tue, 28 Jul 2009 07:19:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6SEIxvw010979; Tue, 28 Jul 2009 07:19:00 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNH00509X3NRS00@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Jul 2009 07:18:59 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00HRCX3NVVB0@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Jul 2009 07:18:59 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6SE9tMg025720; Tue, 28 Jul 2009 14:18:59 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-347253; Tue, 28 Jul 2009 14:18:57 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-584620; Tue, 28 Jul 2009 14:18:54 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1i.sun.com with ESMTP id BT-MMP-16148784; Tue, 28 Jul 2009 14:08:46 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id 507A38534; Tue, 28 Jul 2009 10:07:48 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n6SE7mYR027316; Tue, 28 Jul 2009 10:07:48 -0400 Date: Tue, 28 Jul 2009 10:07:48 -0400 From: Glenn Fowler Subject: Re: [busybox-dev] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] To: busybox-dev@opensolaris.org, Jyri.Virkki@sun.com Cc: ksh93-integration-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <200907281407.n6SE7mYR027316@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2009-06-09 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.087sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> x_sac_archived: PSARC/2009/414 Status: RO Content-Length: 579 On Mon, 27 Jul 2009 21:46:43 -0700 Alan Coopersmith wrote: > The only way this project is "damaged" is if the project team decides to > go off and make changes before finding out what the ARC requires. > Frankly, if you implemented the #ifdef SOLARIS changes Garrett required, > I'd call for the ARC to require you to remove them as introducing > unnecessary incompatibilities with other platforms, reducing familiarity > and increasing the cost of ongoing maintenance in having to keep those > patches up to date. no codes were harmed during the production of these messages From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Jul 28 07:29:53 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SETpMB022180 for ; Tue, 28 Jul 2009 07:29:52 -0700 (PDT) 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 n6SETnwN005561 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 22:29:50 +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 <0KNH0061BXLQED00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 07:29:50 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00HG9XLPVWD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 07:29:49 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SETS08026657 for ; Tue, 28 Jul 2009 14:29:49 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-1165085 for PSARC-ext@sun.com; Tue, 28 Jul 2009 14:29:31 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-22493327 for PSARC-ext@sun.com; Tue, 28 Jul 2009 14:28:52 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay4i.sun.com with ESMTP id BT-MMP-8074276 for PSARC-ext@sun.com; Tue, 28 Jul 2009 14:28:07 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 782256F0523; Tue, 28 Jul 2009 16:27:59 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id EAD9D6F0507; Tue, 28 Jul 2009 16:27:58 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n6SERwLe003929; Tue, 28 Jul 2009 16:27:58 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:27:58 +0200 Date: Tue, 28 Jul 2009 16:27:42 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6CE6FF.AC216295@nrubsig.org> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: roland.mainz@nrubsig.org, PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org, gdamore@sun.com, busybox-dev@opensolaris.org Message-id: <4a6f0ade.Gf+RMIOOtc1CvcqR%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 10.423sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <4A6CE6FF.AC216295@nrubsig.org> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 28 Jul 2009 14:27:58.0257 (UTC) FILETIME=[9AA2A210:01CA0F8F] Status: RO Content-Length: 637 Roland Mainz wrote: > I think the best option is now to drop this subject and discuss this on > the next OpenSolaris summit... It seems that we really need to discuss some related issues in the next OpenSolaris summit. This would however only work if the community could initiate sessions on the next summit. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Jul 28 07:29:53 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SETpMB022180 for ; Tue, 28 Jul 2009 07:29:52 -0700 (PDT) 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 n6SETnwN005561 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 22:29:50 +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 <0KNH0061BXLQED00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 07:29:50 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00HG9XLPVWD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 07:29:49 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SETS08026657 for ; Tue, 28 Jul 2009 14:29:49 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-1165085 for PSARC-ext@sun.com; Tue, 28 Jul 2009 14:29:31 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-22493327 for PSARC-ext@sun.com; Tue, 28 Jul 2009 14:28:52 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay4i.sun.com with ESMTP id BT-MMP-8074276 for PSARC-ext@sun.com; Tue, 28 Jul 2009 14:28:07 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 782256F0523; Tue, 28 Jul 2009 16:27:59 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id EAD9D6F0507; Tue, 28 Jul 2009 16:27:58 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n6SERwLe003929; Tue, 28 Jul 2009 16:27:58 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:27:58 +0200 Date: Tue, 28 Jul 2009 16:27:42 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6CE6FF.AC216295@nrubsig.org> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: roland.mainz@nrubsig.org, PSARC-ext@sun.com, ksh93-integration-discuss@opensolaris.org, gdamore@sun.com, busybox-dev@opensolaris.org Message-id: <4a6f0ade.Gf+RMIOOtc1CvcqR%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 10.423sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <4A6CE6FF.AC216295@nrubsig.org> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 28 Jul 2009 14:27:58.0257 (UTC) FILETIME=[9AA2A210:01CA0F8F] Status: RO Content-Length: 637 Roland Mainz wrote: > I think the best option is now to drop this subject and discuss this on > the next OpenSolaris summit... It seems that we really need to discuss some related issues in the next OpenSolaris summit. This would however only work if the community could initiate sessions on the next summit. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From joshhurst@gmail.com Tue Jul 28 07:37:12 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SEbCiW022526 for ; Tue, 28 Jul 2009 07:37:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6SEb2vn021450; Tue, 28 Jul 2009 07:37:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNH00F5ZXXXDK00@brm-avmta-1.central.sun.com>; Tue, 28 Jul 2009 08:37:09 -0600 (MDT) 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 <0KNH00H6QXXXLLD0@brm-avmta-1.central.sun.com>; Tue, 28 Jul 2009 08:37:09 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SEUYNl015837; Tue, 28 Jul 2009 14:37:08 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-457048; Tue, 28 Jul 2009 14:37:04 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-12207743; Tue, 28 Jul 2009 14:35:33 +0000 (Z) Received: from qw-out-1920.google.com ([74.125.92.145] [74.125.92.145]) by relay1i.sun.com with ESMTP id BT-MMP-16173826; Tue, 28 Jul 2009 14:25:11 +0000 (Z) Received: by qw-out-1920.google.com with SMTP id 5so29557qwf.50 for ; Tue, 28 Jul 2009 07:24:17 -0700 (PDT) Received: by 10.220.100.5 with SMTP id w5mr4569404vcn.62.1248790687936; Tue, 28 Jul 2009 07:18:07 -0700 (PDT) Date: Tue, 28 Jul 2009 16:18:07 +0200 From: Josh Hurst Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6E82B3.3090300@sun.com> To: Korn Shell 93 integration/migration project discussion Cc: Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ft4La/KFg9KWIzoNuRqHPicXrnzQmrTAWwZsXr7+L2Y=; b=gtZdfVf18zZwTpfORIXXpmgoJHt1S93/ReRLYIpC3xdG8ERA2YbY5UsYyGfo9hPiW+ iVB0Si4ttuCAu31xSiI5ztE5NY7r9AltAUbQ/p9BZTHUFfX7GL6LP9mKf1J8Qh2wSbQt 4EMowLUK4VrHb4S98VSKHljEiL6k0KXKdob2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O/7GAXHdcZ13aqWoXQDF5vDBXIcMTq/lZRovPWKUyVXn9MLp6rHginx8AHhfENNG/U vJIm/z6dG3Hn3KhIo8i6ENKLTCDBYUdaQXQd5TGKCyTH5+Qaqt4a+hEnZs891vTWEffe AdhSKGkFtWMCNoKvoaxiZp+cBDLYrPOJmlLMk= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 8.193sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> Status: RO Content-Length: 1006 On 7/28/09, Alan Coopersmith wrote: > Jyri Virkki wrote: > > Roland Mainz wrote: > >> Ok... I really tried to mediate a way though this but it seems we're > >> stuck and right now it looks we're getting too much damage... > >> > >> ... here hereby _withdraw_ this ARC case. > > > > I'm only an observer on this case, but I am an ARC member so have some > > context.. > > > > While withdrawing a case is certainly your call, it would be > > unfortunate if it is - as it seems from the choice of your words above - > > due only to some confusion on ARC process terminology. > > > > Please note nothing is "stuck" and there is no "damage". > > > > People expressing opinions on a mailing list is not damage. None of it > > is binding. > > Correct. As the case owner, I haven't marked the case withdrawn since > the request to do so seems based on a misunderstanding. Do you think it is a good idea to ignore us and ruin the reputation of ARC completely? Josh From joshhurst@gmail.com Tue Jul 28 07:37:12 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SEbCiW022526 for ; Tue, 28 Jul 2009 07:37:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6SEb2vn021450; Tue, 28 Jul 2009 07:37:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNH00F5ZXXXDK00@brm-avmta-1.central.sun.com>; Tue, 28 Jul 2009 08:37:09 -0600 (MDT) 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 <0KNH00H6QXXXLLD0@brm-avmta-1.central.sun.com>; Tue, 28 Jul 2009 08:37:09 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SEUYNl015837; Tue, 28 Jul 2009 14:37:08 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-457048; Tue, 28 Jul 2009 14:37:04 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-12207743; Tue, 28 Jul 2009 14:35:33 +0000 (Z) Received: from qw-out-1920.google.com ([74.125.92.145] [74.125.92.145]) by relay1i.sun.com with ESMTP id BT-MMP-16173826; Tue, 28 Jul 2009 14:25:11 +0000 (Z) Received: by qw-out-1920.google.com with SMTP id 5so29557qwf.50 for ; Tue, 28 Jul 2009 07:24:17 -0700 (PDT) Received: by 10.220.100.5 with SMTP id w5mr4569404vcn.62.1248790687936; Tue, 28 Jul 2009 07:18:07 -0700 (PDT) Date: Tue, 28 Jul 2009 16:18:07 +0200 From: Josh Hurst Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6E82B3.3090300@sun.com> To: Korn Shell 93 integration/migration project discussion Cc: Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ft4La/KFg9KWIzoNuRqHPicXrnzQmrTAWwZsXr7+L2Y=; b=gtZdfVf18zZwTpfORIXXpmgoJHt1S93/ReRLYIpC3xdG8ERA2YbY5UsYyGfo9hPiW+ iVB0Si4ttuCAu31xSiI5ztE5NY7r9AltAUbQ/p9BZTHUFfX7GL6LP9mKf1J8Qh2wSbQt 4EMowLUK4VrHb4S98VSKHljEiL6k0KXKdob2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O/7GAXHdcZ13aqWoXQDF5vDBXIcMTq/lZRovPWKUyVXn9MLp6rHginx8AHhfENNG/U vJIm/z6dG3Hn3KhIo8i6ENKLTCDBYUdaQXQd5TGKCyTH5+Qaqt4a+hEnZs891vTWEffe AdhSKGkFtWMCNoKvoaxiZp+cBDLYrPOJmlLMk= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 8.193sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> Status: RO Content-Length: 1006 On 7/28/09, Alan Coopersmith wrote: > Jyri Virkki wrote: > > Roland Mainz wrote: > >> Ok... I really tried to mediate a way though this but it seems we're > >> stuck and right now it looks we're getting too much damage... > >> > >> ... here hereby _withdraw_ this ARC case. > > > > I'm only an observer on this case, but I am an ARC member so have some > > context.. > > > > While withdrawing a case is certainly your call, it would be > > unfortunate if it is - as it seems from the choice of your words above - > > due only to some confusion on ARC process terminology. > > > > Please note nothing is "stuck" and there is no "damage". > > > > People expressing opinions on a mailing list is not damage. None of it > > is binding. > > Correct. As the case owner, I haven't marked the case withdrawn since > the request to do so seems based on a misunderstanding. Do you think it is a good idea to ignore us and ruin the reputation of ARC completely? Josh From Alan.Coopersmith@Sun.COM Tue Jul 28 07:43:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SEhkqh022728 for ; Tue, 28 Jul 2009 07:43:47 -0700 (PDT) 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 n6SEhQpP012385 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 22:43:45 +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 <0KNH00G05Y8QX800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:38 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH0051OY8PDI70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:37 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SEhbpX020078 for ; Tue, 28 Jul 2009 07:43:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNH00400XZVMW00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:37 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNH00E7TY8NNV60@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:36 -0700 (PDT) Date: Tue, 28 Jul 2009 07:43:35 -0700 From: Alan Coopersmith Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: Sender: Alan.Coopersmith@Sun.COM To: Korn Shell 93 integration/migration project discussion Cc: PSARC-ext@Sun.COM, Jyri Virkki , Busybox development Message-id: <4A6F0E97.8030209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1228 Josh Hurst wrote: > On 7/28/09, Alan Coopersmith wrote: >> Jyri Virkki wrote: >> > Roland Mainz wrote: >> > People expressing opinions on a mailing list is not damage. None of it >> > is binding. >> >> Correct. As the case owner, I haven't marked the case withdrawn since >> the request to do so seems based on a misunderstanding. > > Do you think it is a good idea to ignore us and ruin the reputation of > ARC completely? I have no idea who you are, or why I should listen to you. Do you think it's a good idea to ignore what's said in the mail and ruin your reputation before you have one? Why do you think allowing the project to go ahead is a bad option? Do you want to stop the integration of ksh93 projects? Why should I put your thoughts on that subject ahead of those of the person who has done the bulk of the ksh93 integration work? I am simply advocating letting this go forward to resolution now, instead of delaying and rehashing this later, when the basic facts won't have changed, and before any time is wasted making changes that are probably not needed. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@Sun.COM Tue Jul 28 07:43:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SEhkqh022728 for ; Tue, 28 Jul 2009 07:43:47 -0700 (PDT) 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 n6SEhQpP012385 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 22:43:45 +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 <0KNH00G05Y8QX800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:38 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH0051OY8PDI70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:37 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SEhbpX020078 for ; Tue, 28 Jul 2009 07:43:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNH00400XZVMW00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:37 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNH00E7TY8NNV60@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 28 Jul 2009 07:43:36 -0700 (PDT) Date: Tue, 28 Jul 2009 07:43:35 -0700 From: Alan Coopersmith Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: Sender: Alan.Coopersmith@Sun.COM To: Korn Shell 93 integration/migration project discussion Cc: PSARC-ext@Sun.COM, Jyri Virkki , Busybox development Message-id: <4A6F0E97.8030209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1228 Josh Hurst wrote: > On 7/28/09, Alan Coopersmith wrote: >> Jyri Virkki wrote: >> > Roland Mainz wrote: >> > People expressing opinions on a mailing list is not damage. None of it >> > is binding. >> >> Correct. As the case owner, I haven't marked the case withdrawn since >> the request to do so seems based on a misunderstanding. > > Do you think it is a good idea to ignore us and ruin the reputation of > ARC completely? I have no idea who you are, or why I should listen to you. Do you think it's a good idea to ignore what's said in the mail and ruin your reputation before you have one? Why do you think allowing the project to go ahead is a bad option? Do you want to stop the integration of ksh93 projects? Why should I put your thoughts on that subject ahead of those of the person who has done the bulk of the ksh93 integration work? I am simply advocating letting this go forward to resolution now, instead of delaying and rehashing this later, when the basic facts won't have changed, and before any time is wasted making changes that are probably not needed. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@Sun.COM Tue Jul 28 08:02:53 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SF2rIM016845 for ; Tue, 28 Jul 2009 08:02:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6SF2qcr008215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 08:02:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNH00H0VZ4STJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 09:02:52 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00G51Z4QUO10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 09:02:51 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SF2oqt018229 for ; Tue, 28 Jul 2009 08:02:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNH00B00Z1X3S00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 08:02:50 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNH00FT9Z4L05E0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 08:02:46 -0700 (PDT) Date: Tue, 28 Jul 2009 08:02:45 -0700 From: Alan Coopersmith Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4a6f0ade.Gf+RMIOOtc1CvcqR%Joerg.Schilling@fokus.fraunhofer.de> Sender: Alan.Coopersmith@Sun.COM To: Joerg Schilling Cc: roland.mainz@nrubsig.org, PSARC-ext@Sun.COM, ksh93-integration-discuss@opensolaris.org, gdamore@Sun.COM, busybox-dev@opensolaris.org Message-id: <4A6F1315.7030608@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <4A6CE6FF.AC216295@nrubsig.org> <4a6f0ade.Gf+RMIOOtc1CvcqR%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 663 Joerg Schilling wrote: > It seems that we really need to discuss some related issues in the next > OpenSolaris summit. This would however only work if the community could > initiate sessions on the next summit. The community has been able to initiate sessions at the past OpenSolaris summits - however waiting until "the next OpenSolaris summit" is a plan to fail, since there are no such summits planned at this time, and given Sun's recent financial results and pending acquisition, I have no idea when there will be funding for another one. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@Sun.COM Tue Jul 28 08:02:53 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6SF2rIM016845 for ; Tue, 28 Jul 2009 08:02:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6SF2qcr008215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 08:02:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNH00H0VZ4STJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 09:02:52 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNH00G51Z4QUO10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 09:02:51 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SF2oqt018229 for ; Tue, 28 Jul 2009 08:02:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNH00B00Z1X3S00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 08:02:50 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNH00FT9Z4L05E0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 08:02:46 -0700 (PDT) Date: Tue, 28 Jul 2009 08:02:45 -0700 From: Alan Coopersmith Subject: Re: PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp,pathchk,& tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4a6f0ade.Gf+RMIOOtc1CvcqR%Joerg.Schilling@fokus.fraunhofer.de> Sender: Alan.Coopersmith@Sun.COM To: Joerg Schilling Cc: roland.mainz@nrubsig.org, PSARC-ext@Sun.COM, ksh93-integration-discuss@opensolaris.org, gdamore@Sun.COM, busybox-dev@opensolaris.org Message-id: <4A6F1315.7030608@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <4A6CE6FF.AC216295@nrubsig.org> <4a6f0ade.Gf+RMIOOtc1CvcqR%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) x_sac_archived: PSARC/2009/414 Status: RO Content-Length: 663 Joerg Schilling wrote: > It seems that we really need to discuss some related issues in the next > OpenSolaris summit. This would however only work if the community could > initiate sessions on the next summit. The community has been able to initiate sessions at the past OpenSolaris summits - however waiting until "the next OpenSolaris summit" is a plan to fail, since there are no such summits planned at this time, and given Sun's recent financial results and pending acquisition, I have no idea when there will be funding for another one. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Tue Jul 28 19:19:31 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6T2JVwR026729 for ; Tue, 28 Jul 2009 19:19:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6T2JUB8015085 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 19:19:31 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNI00I05UGISX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 20:19:30 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNI00FNGUGINPC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 20:19:30 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6T2JUVT001747 for ; Tue, 28 Jul 2009 19:19:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNI00300UCF3M00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 19:19:30 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNI003MYUGGS680@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 19:19:28 -0700 (PDT) Date: Tue, 28 Jul 2009 19:19:28 -0700 From: Alan Coopersmith Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6E82B3.3090300@sun.com> Sender: Alan.Coopersmith@sun.com To: Korn Shell 93 integration/migration project discussion Cc: Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: <4A6FB1B0.2080602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1146 Alan Coopersmith wrote: > Correct. As the case owner, I haven't marked the case withdrawn since > the request to do so seems based on a misunderstanding. I've been informed that Roland has been away from e-mail due to personal business, so have still not done anything to update the case status. At the very least, I will need to confirm he understands what "withdrawn" means in the ARC status: "This state indicates that this case was neither approved or rejected, but rather will *never* be integrated into a product." Suspending the case while a new proposal is drawn up would normally fall under the status "waiting need spec" - of course, neither will stop the ARC from discussing the documentation issue or voting on it in the context of another case, it will just not be this case, but could be any other of the external open source reviews coming through ARC with similar built-in documentation, and this case could go back to being a simple fasttrack as long as it follows the precedent set by that other case. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Tue Jul 28 19:19:31 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6T2JVwR026729 for ; Tue, 28 Jul 2009 19:19:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6T2JUB8015085 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Jul 2009 19:19:31 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNI00I05UGISX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 20:19:30 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNI00FNGUGINPC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 20:19:30 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6T2JUVT001747 for ; Tue, 28 Jul 2009 19:19:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNI00300UCF3M00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 19:19:30 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNI003MYUGGS680@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Jul 2009 19:19:28 -0700 (PDT) Date: Tue, 28 Jul 2009 19:19:28 -0700 From: Alan Coopersmith Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6E82B3.3090300@sun.com> Sender: Alan.Coopersmith@sun.com To: Korn Shell 93 integration/migration project discussion Cc: Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: <4A6FB1B0.2080602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) x_sac_archived: PSARC/2009/414 Status: RO Content-Length: 1146 Alan Coopersmith wrote: > Correct. As the case owner, I haven't marked the case withdrawn since > the request to do so seems based on a misunderstanding. I've been informed that Roland has been away from e-mail due to personal business, so have still not done anything to update the case status. At the very least, I will need to confirm he understands what "withdrawn" means in the ARC status: "This state indicates that this case was neither approved or rejected, but rather will *never* be integrated into a product." Suspending the case while a new proposal is drawn up would normally fall under the status "waiting need spec" - of course, neither will stop the ARC from discussing the documentation issue or voting on it in the context of another case, it will just not be this case, but could be any other of the external open source reviews coming through ARC with similar built-in documentation, and this case could go back to being a simple fasttrack as long as it follows the precedent set by that other case. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Wed Mar 24 08:10:35 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OFAZBj025928 for ; Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2OFAZZH012863 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZS00005KTNKF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS000EGKTNBM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2OFAYtZ006377 for ; Wed, 24 Mar 2010 08:10:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00J00KOIS200@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:34 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00AFQKTMKR30@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:34 -0700 (PDT) Date: Wed, 24 Mar 2010 08:10:34 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6FB1B0.2080602@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: Korn Shell 93 integration/migration project discussion , Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: <4BAA2B6A.3020107@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> <4A6FB1B0.2080602@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 923 The project team would like to restart PSARC 2009/414 with a modification that --man and --nroff will be removed. Since this is was the reason I originally derailed the original case, now that those contentious (to me at least) parts of the case have been removed, I think it is fair to return this case to fast track status. I'll be posting updated man pages for the new commands into the materials directory shortly, but readers can be advised that the specification is identical to the original case with the --man and --nroff options elided. Given that this case was rather thoroughly debated and reviewed last year, and that the only bone of contention was removed, the project team would like a shortened timer. I'm going to go ahead and set the timer to expire on Friday, which is shorter than the normal week. If anyone wants more time, please speak up and we can extend the timer. - Garrett From gdamore@sun.com Wed Mar 24 08:10:35 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OFAZBj025928 for ; Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2OFAZZH012863 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZS00005KTNKF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS000EGKTNBM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:35 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2OFAYtZ006377 for ; Wed, 24 Mar 2010 08:10:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00J00KOIS200@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:34 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00AFQKTMKR30@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:10:34 -0700 (PDT) Date: Wed, 24 Mar 2010 08:10:34 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4A6FB1B0.2080602@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: Korn Shell 93 integration/migration project discussion , Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: <4BAA2B6A.3020107@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> <4A6FB1B0.2080602@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 x_sac_archived: PSARC/2009/414 Status: RO Content-Length: 923 The project team would like to restart PSARC 2009/414 with a modification that --man and --nroff will be removed. Since this is was the reason I originally derailed the original case, now that those contentious (to me at least) parts of the case have been removed, I think it is fair to return this case to fast track status. I'll be posting updated man pages for the new commands into the materials directory shortly, but readers can be advised that the specification is identical to the original case with the --man and --nroff options elided. Given that this case was rather thoroughly debated and reviewed last year, and that the only bone of contention was removed, the project team would like a shortened timer. I'm going to go ahead and set the timer to expire on Friday, which is shorter than the normal week. If anyone wants more time, please speak up and we can extend the timer. - Garrett From gdamore@Sun.COM Wed Mar 24 08:15:35 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OFFZUJ026115 for ; Wed, 24 Mar 2010 08:15:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2OFFVX5007260 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 24 Mar 2010 09:15:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZS0011XL1XL600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:34 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS0099RL1W4T90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:32 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2OFFWvY021311 for ; Wed, 24 Mar 2010 08:15:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00A00KR20V00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00192L1VSY40@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:31 -0700 (PDT) Date: Wed, 24 Mar 2010 08:15:31 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4BAA2B6A.3020107@sun.com> Sender: Garrett.Damore@Sun.COM To: Alan Coopersmith Cc: Korn Shell 93 integration/migration project discussion , Jyri Virkki , PSARC-ext@Sun.COM, Busybox development Message-id: <4BAA2C93.7070007@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> <4A6FB1B0.2080602@sun.com> <4BAA2B6A.3020107@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1131 Sorry, I forgot to mention, --html (which is another format for man pages) was *also* removed from this case. -- Garrett On 03/24/10 08:10 AM, Garrett D'Amore wrote: > The project team would like to restart PSARC 2009/414 with a > modification that --man and --nroff will be removed. Since this is > was the reason I originally derailed the original case, now that those > contentious (to me at least) parts of the case have been removed, I > think it is fair to return this case to fast track status. > > I'll be posting updated man pages for the new commands into the > materials directory shortly, but readers can be advised that the > specification is identical to the original case with the --man and > --nroff options elided. > > Given that this case was rather thoroughly debated and reviewed last > year, and that the only bone of contention was removed, the project > team would like a shortened timer. I'm going to go ahead and set the > timer to expire on Friday, which is shorter than the normal week. If > anyone wants more time, please speak up and we can extend the timer. > > - Garrett > From gdamore@Sun.COM Wed Mar 24 08:15:35 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OFFZUJ026115 for ; Wed, 24 Mar 2010 08:15:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2OFFVX5007260 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 24 Mar 2010 09:15:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZS0011XL1XL600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:34 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS0099RL1W4T90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:32 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2OFFWvY021311 for ; Wed, 24 Mar 2010 08:15:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00A00KR20V00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00192L1VSY40@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Mar 2010 08:15:31 -0700 (PDT) Date: Wed, 24 Mar 2010 08:15:31 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4BAA2B6A.3020107@sun.com> Sender: Garrett.Damore@Sun.COM To: Alan Coopersmith Cc: Korn Shell 93 integration/migration project discussion , Jyri Virkki , PSARC-ext@Sun.COM, Busybox development Message-id: <4BAA2C93.7070007@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> <4A6FB1B0.2080602@sun.com> <4BAA2B6A.3020107@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1131 Sorry, I forgot to mention, --html (which is another format for man pages) was *also* removed from this case. -- Garrett On 03/24/10 08:10 AM, Garrett D'Amore wrote: > The project team would like to restart PSARC 2009/414 with a > modification that --man and --nroff will be removed. Since this is > was the reason I originally derailed the original case, now that those > contentious (to me at least) parts of the case have been removed, I > think it is fair to return this case to fast track status. > > I'll be posting updated man pages for the new commands into the > materials directory shortly, but readers can be advised that the > specification is identical to the original case with the --man and > --nroff options elided. > > Given that this case was rather thoroughly debated and reviewed last > year, and that the only bone of contention was removed, the project > team would like a shortened timer. I'm going to go ahead and set the > timer to expire on Friday, which is shorter than the normal week. If > anyone wants more time, please speak up and we can extend the timer. > > - Garrett > From gdamore@sun.com Wed Mar 24 10:30:39 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OHUd7B001535 for ; Wed, 24 Mar 2010 10:30:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2OHUC52010549 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 24 Mar 2010 12:30:39 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZS0081JRASYI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:28 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS00F2ORAPEAF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2OHUPPr011290 for ; Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00E00QT02100@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00BJZRAOXA90@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Date: Wed, 24 Mar 2010 10:30:24 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4BAA2C93.7070007@sun.com> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore" Cc: Alan Coopersmith , Korn Shell 93 integration/migration project discussion , Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: <4BAA4C30.1050102@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> <4A6FB1B0.2080602@sun.com> <4BAA2B6A.3020107@sun.com> <4BAA2C93.7070007@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 111 This case was approved at PSARC today, as modified (i.e. without --man, --html, or --nroff.) - Garrett From gdamore@sun.com Wed Mar 24 10:30:39 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OHUd7B001535 for ; Wed, 24 Mar 2010 10:30:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2OHUC52010549 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 24 Mar 2010 12:30:39 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KZS0081JRASYI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:28 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS00F2ORAPEAF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2OHUPPr011290 for ; Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00E00QT02100@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00BJZRAOXA90@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 24 Mar 2010 10:30:25 -0700 (PDT) Date: Wed, 24 Mar 2010 10:30:24 -0700 From: "Garrett D'Amore" Subject: Re: [ksh93-integration-discuss] PSARC/2009/414 _NOT withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: [busybox-dev]AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-reply-to: <4BAA2C93.7070007@sun.com> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore" Cc: Alan Coopersmith , Korn Shell 93 integration/migration project discussion , Jyri Virkki , PSARC-ext@sun.com, Busybox development Message-id: <4BAA4C30.1050102@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> <4A6E82B3.3090300@sun.com> <4A6FB1B0.2080602@sun.com> <4BAA2B6A.3020107@sun.com> <4BAA2C93.7070007@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 111 This case was approved at PSARC today, as modified (i.e. without --man, --html, or --nroff.) - Garrett