From roland.mainz at nrubsig.org Mon Jul 6 16:09:53 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Tue, 07 Jul 2009 01:09:53 +0200 Subject: [busybox-dev] [Annoucement] ksh93-integration update2 2009-07-02 binaries available for download (for Solaris 11 Nevada >= B110+OpenSolaris/Indiana) ... Message-ID: <4A528441.8616FF3A@nrubsig.org> Hi! ---- 2009-07-02: ksh93-integration update 2 tarballs for Solaris 11 Nevada+OpenSolaris/Indiana These tarballs ([2]) are intended to be installed over an existing Solaris Nevada/Indiana/OpenSolaris >= B110 i386 or SPARC installation and provide ksh93t+_20090505 and the content described in PSARC/2009/248 ("ksh93 update to 2009-03-10") and PSARC/2009/249 ("more ksh93 command conversions"). Note that the binaries are provided for testing and evaluation purposes ONLY. Please report any problems/errors/bugs/comments to the ksh93-integration project bugzilla[5] or the ksh93-integration mailinglist[4] (please subscribe before posting). **** Quick links: - Download&&install instructions: http://www.opensolaris.org/os/project/ksh93-integration/downloads/2009-07-02/ - Webrev: http://cr.opensolaris.org/~gisburn/ksh93_integration_update2_20090702_webrev/ **** Highlights of this release: - Many bugfixes to ksh93, it's infrastructure and other commands, primarily focussing on stability, improved error checking, performance and fixing support for large, complex variable trees. - The several commands have been updated (or added) and now include common GNU+BSD+AST features, including: /usr/bin/cksum /usr/bin/cmp /usr/bin/comm /usr/bin/cut /usr/bin/head /usr/bin/join /usr/bin/kill /usr/bin/logname /usr/bin/mkfifo /usr/bin/paste /usr/bin/print /usr/bin/rev /usr/bin/sleep /usr/bin/sum /usr/bin/tail /usr/bin/tee /usr/bin/test /usr/bin/uniq /usr/bin/wait /usr/bin/wc /usr/xpg4/bin/tail (the full list of updated commands can be found below) - The following bugs/RFEs will be fixed by this putback: +--------------------------------------------------------------+ |BugID |Title | |-------+------------------------------------------------------| |4701104|*tail* tail -r has limitations on un-mmappable files | | |(/etc/mnttab) | |-------+------------------------------------------------------| |6605478|ksh93 profile shell option does not work | |-------+------------------------------------------------------| |6705126|first call to read does not honor new setting of | | |HISTFILE | |-------+------------------------------------------------------| |6764665|*libpp* Array overrun in libpp | |-------+------------------------------------------------------| |6765756|*libast* Array overruns in libast | |-------+------------------------------------------------------| |6769332|Recursive function+command substitutions terminate | | |shell after 257 iterations | |-------+------------------------------------------------------| |6778077|*ksh93* does not understand "THAW" as a signal for use| | |with trap | |-------+------------------------------------------------------| |6789247|[ku1] libast/ksh93 1-digit hexfloat base | | |conversion rounds incorrectly | |-------+------------------------------------------------------| |6790507|RFE: Update /usr/bin/tail and /usr/xpg4/bin/tail to | | |AT&T AST "tail" | |-------+------------------------------------------------------| |6791838|*ksh93* unset of a variable which is not set | | |should return 0 | |-------+------------------------------------------------------| |6793714|RFE: Update /usr/bin/comm to AT&T AST "comm" | |-------+------------------------------------------------------| |6793719|RFE: Update /usr/bin/cut to AT&T AST "cut" | |-------+------------------------------------------------------| |6793721|RFE: Update /usr/bin/paste to AT&T AST "paste" | |-------+------------------------------------------------------| |6793722|RFE: Update /usr/bin/cmp to AT&T AST "cmp" | |-------+------------------------------------------------------| |6793726|RFE: Update /usr/bin/uniq to AT&T AST "uniq" | |-------+------------------------------------------------------| |6793735|RFE: Update /usr/bin/wc to AT&T AST "wc" | |-------+------------------------------------------------------| |6793744|RFE: Add /usr/share/doc/ksh/ for ksh93 documentation | |-------+------------------------------------------------------| |6793747|RFE: Provide "print" builtin as /usr/bin/ | | |print for external applications | |-------+------------------------------------------------------| |6793763|RFE: Update /usr/bin/ksh93 to ast-ksh.2009-05-05 | |-------+------------------------------------------------------| |6794952|RFE: Enable "globstar" option in /etc/ksh.kshrc | |-------+------------------------------------------------------| |6805792|[ Moving local compound var into array does not work | |-------+------------------------------------------------------| |6805794| printf returns "invalid character constant" for | | |$ printf "%dn" "`;" | |-------+------------------------------------------------------| |6805795|[ku1] ksh93 does not differ between -0 and +0 | |-------+------------------------------------------------------| |6805797|[ku1]Can't append to nodes of an array of compound | | | vars if addressing them via nameref | |-------+------------------------------------------------------| |6805799|Indexed compound variable arrays do not work... | |-------+------------------------------------------------------| |6805800|[Declaring associative compound array does not work | |-------+------------------------------------------------------| |6805812|RFE: Update /usr/bin/head to AT&T AST "head" | |-------+------------------------------------------------------| |6805813|RFE: Update /usr/bin/join to AT&T AST "join" | |-------+------------------------------------------------------| |6805814|RFE: Update /usr/bin/mkfifo to AT&T AST "mkfifo" | |-------+------------------------------------------------------| |6805819|RFE: Update /usr/bin/tee to AT&T AST "tee" | |-------+------------------------------------------------------| |6809663|shlint missing ending newline on errors | |-------+------------------------------------------------------| |6811916|ksh93 repeatedly seg faults when "tee" builtin is | | |interupted via in inteactive mode | |-------+------------------------------------------------------| |6821113|SUNWosdem package issues | |-------+------------------------------------------------------| |6828644|RFE: Update /usr/bin/logname to AT&T AST "logname" | |-------+------------------------------------------------------| |6828692|RFE: Update /usr/bin/cksum to AT&T AST "cksum" | |-------+------------------------------------------------------| |6834184|ksh93 gets SIGSEGV if HISTFILE is changed in place. | |-------+------------------------------------------------------| |6834207|ksh93 gets SIGSEGV on interactive function definition | | |with HISTSIZE unset | |-------+------------------------------------------------------| |6835835|ksh93 "cat" builtin does not handle "-n" correctly | |-------+------------------------------------------------------| |6841442|Need exception list for OS/Net trees managed via | | |Subversion | |-------+------------------------------------------------------| |6848486|"echo ${test}" with test undefined crashes the shell | |-------+------------------------------------------------------| |6850672|ksh93 (VISUAL=vi) crashes with memory fault | | |while scolling through history | |-------+------------------------------------------------------| |6855875|typeset -X x ; print $x # does not print sufficient | | |digits to restore value | +--------------------------------------------------------------+ **** Install instructions: *** Basic installation: 1. Download the tarball: + i386/AMD64: http://www.opensolaris.org/os/project/ksh93-integration/downloads/ksh93_integration_20090702_snapshot_i386.tar.bz2 + SPARC: http://www.opensolaris.org/os/project/ksh93-integration/downloads/ksh93_integration_20090702_snapshot_sparc.tar.bz2 2. Verify the MD5 checksum: + i386/AMD64: MD5 (ksh93_integration_20090702_snapshot_i386.tar.bz2)= 67e91dcbbe715a66ecb20edcd5419b7a + SPARC: MD5 (ksh93_integration_20090702_snapshot_sparc.tar.bz2)= 7949f49e4f422d6b1490c1b0dfb1789e 3. Login as user "root": 4. Change directory to / and unpack the tarball with /usr/bin/tar using the "xvof" option ("o" is very important to set the file ownership to "root") ** Example for i386/AMD64: $ cd /tmp $ /usr/sfw/bin/wget \ http://www.opensolaris.org/os/project/ksh93-integration/downloads/ksh93_integration_20090702_snapshot_i386.tar.bz2 $ sum -x md5 ksh93_integration_20090702_snapshot_i386.tar.bz2 67e91dcbbe715a66ecb20edcd5419b7a ksh93_integration_20090702_snapshot_i386.tar.bz2 # cd / # sync ; sync # bzcat svn_genunix_org_on_branches_ksh93_gisburn_prototype021_rev_b111_1610.diff.txt o ... unified diff (http://www.opensolaris.org/os/project/ksh93-integration/downloads/svn_genunix_org_on_branches_ksh93_gisburn_prototype021_rev_b111_1610.diff.txt , 2.25MB, MD5 checksum is 6e33ae16efbeced80ff1beb52afa445b). o ... Mercurial/HG export bundle (http://www.opensolaris.org/os/project/ksh93-integration/downloads/ksh93_integration_update2_20090702_hg_export_001.hgexport.bz2 , 212KB, MD5 checksum is 2a977e5be3b2eaa57d76c9aa8cd9d5c5) + Alternatively webrev pages are available at http://cr.opensolaris.org/~gisburn/ksh93_integration_update2_20090702_webrev/ * "multiline" input mode is now enabled by default in /etc/ksh.kshrc to match input/editor behaviour of bash. * /etc/ksh.kshrc now sets a default prompt (PS1) which contains @:$ for normal users and @:# for user "root"; the prompt length itself is limited to ~~30 characters to ensure it only occupies ~~1/4 of a standard 80x24 terminal window. * was added to emacs/gmacs mode to clear the screen (per community requests and to be in sync with bash) * 64bit binaries and libraries are now included (and used by default if the hardware is 64bit capable) * "shcomp", the shell script compiler is now included as /usr/bin /shcomp. * AST l10n utilities are stored in /usr/ast/bin/. * Starting with ksh93s+ multibyte characters can be used for variable/function/etc.-names. Please test this functionality extensively. * The tarball was created using the build_ksh93_standalone_tarball.sh script which is available in the base directory of the prototype021 tree. Note: The script can only be used after a successfull $ cd usr/ src ; (cd tools ; make install) ; make setup ; \ dmake install #-sequence, otherwise the resulting tarball will be incomplete. * The tarballs do not provide a manual page for ksh93. Please use the manual page for ksh93s+ in the meantime. * The ksh93 binaries can be build from source like this: (Instructions are for Solaris i386/AMD64; SPARC requires minor adjustments) 1. Pull sources and extract closed bin stuff (files can be obtained from opensolaris.org): $ mkdir test_x86 ; cd test_x86 $ svn checkout -r 1610 \ svn://svn.genunix.org/on/branches/ksh93/gisburn/prototype021/usr $ bzcat <../download/on-closed-bins-nd.i386.tar.bz2 | \ tar -xf - $ bzcat <../download/on-closed-bins.i386.tar.bz2 | \ tar -xf - $ cd .. 2. Create opensolaris.sh. This is the usual opensolaris.sh with the paths adjusted to match your location of the sources. Example for the changes applies to opensolaris.sh (for my workspace): --- ./test1_x86/usr/src/tools/env/opensolaris.sh +++ ./opensolaris.sh @@ -43,10 +43,10 @@ # This is a variable for the rest of the script - GATE doesn't # matter to nightly itself -GATE=testws; export GATE +GATE=prototype021; export GATE +# workaround for B111 build issue +export NOT_UNDER_SCM=true # CODEMGR_WS - where is your workspace at (or what should # nightly name it) -CODEMGR_WS="/export/$GATE"; export CODEMGR_WS +CODEMGR_WS="/home/test001/ksh93/on_build1/$GATE"; export CODEMGR_WS # Location of encumbered binaries. ON_CLOSED_BINS="$CODEMGR_WS/closed"; export ON_CLOSED_BINS 3. Run "bldenv": $ env - SHELL=$SHELL TERM=$TERM HOME=$HOME LOGNAME=$LOGNAME \ DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY LANG=C LC_ALL=C \ PAGER=less MANPATH=$MANPATH /opt/onbld/bin/bldenv \ opensolaris.sh # 4. Build it (the quick way): $ cd prototype021/usr/src $ export CW_NO_SHADOW=1 $ time nice make setup 2>&1 | tee -a buildlog_setup.log $ time nice dmake install >buildlog.log 2>&1 Finally: Please check http://www.opensolaris.org/os/project/ksh93-integration/downloads/2009-07-02/ for any updates or additional comments... **** Links/References: [1]=ksh93-integration/migration project home page: http://www.opensolaris.org/os/project/ksh93-integration/ [2]=2009-07-02 ksh93-integration update2 test binaries: http://www.opensolaris.org/os/project/ksh93-integration/downloads/2009-07-02/ [3]=ksh93s+ manual page: http://www.opensolaris.org/os/project/ksh93-integration/docs/ksh93s/man/man1/sh/ [4]=ksh93-integration mailinglist: http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss/ ; please subscribe before posting (and please avoid flamewars) !! [5]=ksh93-integration project bugzilla: http://bugs.grommit.com/enter_bug.cgi?product=ksh93-integration ---- Bye, Roland P.S.: Reply-To: is set to ksh93-integration-discuss at opensolaris.org -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From joshhurst at gmail.com Wed Jul 8 14:03:47 2009 From: joshhurst at gmail.com (Josh Hurst) Date: Wed, 8 Jul 2009 23:03:47 +0200 Subject: [busybox-dev] New name for busybox project? Message-ID: Roland, Chris, can we or should we rename the project to prevent confusion with the busybox project at busybox.net? Their hostile attitude (lawyers et al.) against non-GPL projects pisses me off and I don't want to get a letter from them just because we use 'their' ??? name. Josh ---------- Forwarded message ---------- From: Chris Pickett Date: Apr 14, 2009 5:08 PM Subject: Re: [busybox-dev] Busybox porting To: eremin at milax.org, Busybox development On 4/9/09, Alexander wrote: > Hi guys, > what's the status of subject? Roland wrote his own version of busybox. http://svn.genunix.org/repos/on/branches/ksh93/gisburn/prototype021/usr/src/cmd/ksh/builtins/alias.c is the current switch application and uses commands from libcmd, libsed, libawk and libsolariscmd to run the commands. Chris -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris at users.sourceforge.net _______________________________________________ busybox-dev mailing list busybox-dev at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/busybox-dev From roland.mainz at nrubsig.org Thu Jul 16 22:51:32 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Fri, 17 Jul 2009 07:51:32 +0200 Subject: [busybox-dev] busybox updates for /usr/bin/tty and /usr/bin/mktemp ... Message-ID: <4A601164.85874F41@nrubsig.org> Hi! ---- Can anyone please check whether the ARC case for updating /usr/bin/tty and /usr/bin/mktemp to the AT&T AST versions at http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt looks Ok ? We'll try to get the update done shortly after the comment for ksh93-integration update2 ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From bugmail-sender at sun.com Fri Jul 17 00:02:56 2009 From: bugmail-sender at sun.com (bugmail-sender at sun.com) Date: Fri, 17 Jul 2009 01:02:56 -0600 (MDT) Subject: [busybox-dev] CR 6861633 Updated, P3 utility/shell RFE: Update /usr/bin/mktemp to AT&T AST "mktemp" Message-ID: <16748627.1247814176491.JavaMail.sbladm@swsblss4-new> *Synopsis*: RFE: Update /usr/bin/mktemp to AT&T AST "mktemp" CR 6861633 changed on Jul 17 2009 by === Field ============ === New Value ============= === Old Value ============= Category utility opensolaris SubCategory shell triage-queue ====================== =========================== =========================== *Change Request ID*: 6861633 *Synopsis*: RFE: Update /usr/bin/mktemp to AT&T AST "mktemp" Product: solaris Category: utility Subcategory: shell Type: RFE Subtype: Status: 1-Dispatched Substatus: Priority: 3-Medium Introduced In Release: Introduced In Build: Responsible Engineer: Keywords: opensolaris === *Description* ============================================================ Category solaris/utility (Solaris Utilities/Commands) Sub-Category text Description RFE: Update /usr/bin/mktemp to AT&T AST "mktemp". The utility is already available as ksh93 builtin and simply needs to be connected" to the /usr/bin/mktemp location once we have the confirmation that it passes the test suites and the usual row of other tests. As a side-effect we get: - GNU+BSD command line options (which increases interoperabilty) - Massive 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. - Living and _cooperative_ upstream who does bugfixing - Code remains under a CDDL(-compatible) license Frequency Always Regression No Steps to Reproduce - Expected Result - Actual Result - Error Message(s) - Test Case - Workaround - Additional configuration information Solaris 11/B110 *** (#1 of 1): 2009-07-17 05:21:18 GMT+00:00 === *Public Comments* ======================================================== === *Workaround* ============================================================= === *Additional Details* ===================================================== Targeted Release: Commit To Fix In Build: Fixed In Build: Integrated In Build: Verified In Build: See Also: Duplicate of: Hooks: Hook1: Hook2: Hook3: Hook4: Hook5: Hook6: Program Management: Root Cause: Fix Affects Documentation: No Fix Affects Localization: No === *History* ================================================================ Date Submitted: 2009-07-17 05:21:17 GMT+00:00 Submitted By: Status Changed Date Updated Updated By === *Service Request* ======================================================== Impact: Significant Functionality: Secondary Severity: 3 Product Name: solaris Product Release: solaris_nevada Product Build: snv_110 Operating System: solaris_nevada Hardware: generic Submitted Date: 2009-07-17 05:21:18 GMT+00:00 === *Multiple Release (MR) Cluster* - 0 ====================================== From iszczesniak at gmail.com Fri Jul 17 12:49:54 2009 From: iszczesniak at gmail.com (I. Szczesniak) Date: Fri, 17 Jul 2009 21:49:54 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] busybox updates for /usr/bin/tty and /usr/bin/mktemp ... In-Reply-To: <4A601164.85874F41@nrubsig.org> References: <4A601164.85874F41@nrubsig.org> Message-ID: The proposal looks OK. Are you sure you don't want to include fold and pathchk in this case? Irek On 7/17/09, Roland Mainz wrote: > > Hi! > > ---- > > Can anyone please check whether the ARC case for updating /usr/bin/tty > and /usr/bin/mktemp to the AT&T AST versions at > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > looks Ok ? We'll try to get the update done shortly after the comment > for ksh93-integration update2 ... > > ---- > > Bye, > Roland > > -- > __ . . __ > (o.\ \/ /.o) roland.mainz at nrubsig.org > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 3992797 > (;O/ \/ \O;) > _______________________________________________ > ksh93-integration-discuss mailing list > ksh93-integration-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss > From dcragun at sonic.net Fri Jul 17 22:25:24 2009 From: dcragun at sonic.net (Don Cragun) Date: Fri, 17 Jul 2009 22:25:24 -0700 (PDT) Subject: [busybox-dev] busybox updates for /usr/bin/tty and /usr/bin/mktemp ... Message-ID: <20043.76.191.129.144.1247894724.squirrel@webmail.sonic.net> Hi Roland, The entries for /usr/bin/mktemp and /usr/bin/tty both include the line: "For further information/specifications see the materials/-folder." You probably want to give a brief description of what will be found in the case's materials directory instead of just a direction to search for something that might or might not be present. Since you talk about adding new options for both of these utilities, I assume you'll have updated man pages as part of the case materials. Are there copies of the man pages we can look at now? Cheers, Don On Fri, 17 Jul 2009 07:51:32 +0200 Roland Mainz wrote: > > Hi! > > ---- > > Can anyone please check whether the ARC case for updating /usr/bin/tty > and /usr/bin/mktemp to the AT&T AST versions at > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > looks Ok ? We'll try to get the update done shortly after the comment > for ksh93-integration update2 ... > > ---- > > Bye, > Roland From roland.mainz at nrubsig.org Sat Jul 18 00:05:32 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat, 18 Jul 2009 09:05:32 +0200 Subject: [busybox-dev] busybox updates for /usr/bin/tty and /usr/bin/mktemp ... References: <20043.76.191.129.144.1247894724.squirrel@webmail.sonic.net> Message-ID: <4A61743C.6F8DBFFF@nrubsig.org> Don Cragun wrote: > On Fri, 17 Jul 2009 07:51:32 +0200 Roland Mainz wrote: > > Can anyone please check whether the ARC case for updating /usr/bin/tty > > and /usr/bin/mktemp to the AT&T AST versions at > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > > looks Ok ? We'll try to get the update done shortly after the comment > > for ksh93-integration update2 ... > The entries for /usr/bin/mktemp and /usr/bin/tty both include > the line: > "For further information/specifications see the materials/-folder." > You probably want to give a brief description of what will be > found in the case's materials directory instead of just a direction to > search for something that might or might not be present. Since you talk > about adding new options for both of these utilities, I assume you'll > have updated man pages as part of the case materials. Are there copies > of the man pages we can look at now? See http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/ - it has old, new and diff versions of the manual pages... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Sat Jul 18 00:09:04 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat, 18 Jul 2009 09:09:04 +0200 Subject: [busybox-dev] busybox updates for /usr/bin/tty and /usr/bin/mktemp ... References: <20043.76.191.129.144.1247894724.squirrel@webmail.sonic.net> Message-ID: <4A617510.B38D61F6@nrubsig.org> [REPOST - original email had the address of the ksh93-integration-discuss at opensolaris.org list somehow wrong... ;-( ] Don Cragun wrote: > On Fri, 17 Jul 2009 07:51:32 +0200 Roland Mainz wrote: > > Can anyone please check whether the ARC case for updating /usr/bin/tty > > and /usr/bin/mktemp to the AT&T AST versions at > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > > looks Ok ? We'll try to get the update done shortly after the comment > > for ksh93-integration update2 ... > The entries for /usr/bin/mktemp and /usr/bin/tty both include > the line: > "For further information/specifications see the materials/-folder." > You probably want to give a brief description of what will be > found in the case's materials directory instead of just a direction to > search for something that might or might not be present. Since you talk > about adding new options for both of these utilities, I assume you'll > have updated man pages as part of the case materials. Are there copies > of the man pages we can look at now? See http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/ - it has old, new and diff versions of the manual pages... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From pkchris at users.sourceforge.net Sat Jul 18 11:40:01 2009 From: pkchris at users.sourceforge.net (Chris Pickett) Date: Sat, 18 Jul 2009 20:40:01 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] busybox updates for /usr/bin/tty and /usr/bin/mktemp ... In-Reply-To: <4A601164.85874F41@nrubsig.org> References: <4A601164.85874F41@nrubsig.org> Message-ID: On 7/17/09, Roland Mainz wrote: > > Hi! > > ---- > > Can anyone please check whether the ARC case for updating /usr/bin/tty > and /usr/bin/mktemp to the AT&T AST versions at > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > looks Ok ? We'll try to get the update done shortly after the comment > for ksh93-integration update2 ... http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/tty.1.new.txt references http://www.opengroup.org/onlinepubs/9699919799/utilities/join.html in section SEE ALSO. Shouldn't this be http://www.opengroup.org/onlinepubs/9699919799/utilities/tty.html? Chris -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris at users.sourceforge.net From roland.mainz at nrubsig.org Wed Jul 22 21:11:30 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu, 23 Jul 2009 06:11:30 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] busybox updates for /usr/bin/ttyand /usr/bin/mktemp ... References: <4A601164.85874F41@nrubsig.org> Message-ID: <4A67E2F2.F1661918@nrubsig.org> Chris Pickett wrote: > On 7/17/09, Roland Mainz wrote: > > Can anyone please check whether the ARC case for updating /usr/bin/tty > > and /usr/bin/mktemp to the AT&T AST versions at > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > > looks Ok ? We'll try to get the update done shortly after the comment > > for ksh93-integration update2 ... > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/tty.1.new.txt > references http://www.opengroup.org/onlinepubs/9699919799/utilities/join.html > in section SEE ALSO. Shouldn't this be > http://www.opengroup.org/onlinepubs/9699919799/utilities/tty.html? Yes... my fault... ;-( ... fixed. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Wed Jul 22 22:42:44 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu, 23 Jul 2009 07:42:44 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] busybox updates for/usr/bin/tty and /usr/bin/mktemp ... References: <4A601164.85874F41@nrubsig.org> Message-ID: <4A67F854.510E0023@nrubsig.org> "I. Szczesniak" wrote: > On 7/17/09, Roland Mainz wrote: > > Can anyone please check whether the ARC case for updating /usr/bin/tty > > and /usr/bin/mktemp to the AT&T AST versions at > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > > looks Ok ? We'll try to get the update done shortly after the comment > > for ksh93-integration update2 ... > > The proposal looks OK. Are you sure you don't want to include fold and > pathchk in this case? The original plan was to only cover only those AST commands (e.g. "mktemp", "fold") where the codebase added with ksh93-integration update2 already passes all (standards) tests to make the putback work as easy as possible... ... on the other side the ARC case has the phrase "... 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. ..." which allows us to do the update in pieces and no longer as one all-in-one putback... I've added "pathchk" and "fold" to the ARC case... ... please check whether the new materials are Ok for you... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From pkchris at users.sourceforge.net Fri Jul 24 03:57:08 2009 From: pkchris at users.sourceforge.net (Chris Pickett) Date: Fri, 24 Jul 2009 12:57:08 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] busybox updates for/usr/bin/tty and /usr/bin/mktemp ... In-Reply-To: <4A67F854.510E0023@nrubsig.org> References: <4A601164.85874F41@nrubsig.org> <4A67F854.510E0023@nrubsig.org> Message-ID: On 7/23/09, Roland Mainz wrote: > "I. Szczesniak" wrote: > > On 7/17/09, Roland Mainz wrote: > > > > Can anyone please check whether the ARC case for updating /usr/bin/tty > > > and /usr/bin/mktemp to the AT&T AST versions at > > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/ksh93_commands_conversion2/onepager.txt > > > looks Ok ? We'll try to get the update done shortly after the comment > > > for ksh93-integration update2 ... > > > > > The proposal looks OK. Are you sure you don't want to include fold and > > pathchk in this case? > > > The original plan was to only cover only those AST commands (e.g. > "mktemp", "fold") where the codebase added with ksh93-integration > update2 already passes all (standards) tests to make the putback work as > easy as possible... > ... on the other side the ARC case has the phrase "... 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. ..." which > allows us to do the update in pieces and no longer as one all-in-one > putback... > > I've added "pathchk" and "fold" to the ARC case... > ... please check whether the new materials are Ok for you... Looks fine. Chris -- ^---^ (@)v(@) Chris Pickett | / IT consultant ===m==m=== pkchris at users.sourceforge.net From alan.coopersmith at Sun.Com Fri Jul 24 15:48:46 2009 From: alan.coopersmith at Sun.Com (Alan Coopersmith) Date: Fri, 24 Jul 2009 15:48:46 -0700 (PDT) Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Message-ID: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> 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 at 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 at sun.com Fri Jul 24 16:14:10 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Fri, 24 Jul 2009 16:14:10 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> Message-ID: <4A6A4042.8000700@sun.com> 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 at 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 at Sun.COM Fri Jul 24 16:20:02 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Fri, 24 Jul 2009 16:20:02 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6A4042.8000700@sun.com> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> Message-ID: <4A6A41A2.3090208@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore at sun.com Fri Jul 24 16:42:52 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Fri, 24 Jul 2009 16:42:52 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6A41A2.3090208@sun.com> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> Message-ID: <4A6A46FC.4040008@sun.com> 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 at nrubsig.org Fri Jul 24 17:41:58 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat, 25 Jul 2009 02:41:58 +0200 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> Message-ID: <4A6A54D6.95E62CA1@nrubsig.org> 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 at 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Fri Jul 24 18:28:44 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat, 25 Jul 2009 03:28:44 +0200 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A54D6.95E62CA1@nrubsig.org> Message-ID: <4A6A5FCC.841D1D50@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Fri Jul 24 18:47:15 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat, 25 Jul 2009 03:47:15 +0200 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> Message-ID: <4A6A6423.AB589940@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore at sun.com Fri Jul 24 23:01:51 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Fri, 24 Jul 2009 23:01:51 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6A6423.AB589940@nrubsig.org> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6A41A2.3090208@sun.com> <4A6A46FC.4040008@sun.com> <4A6A6423.AB589940@nrubsig.org> Message-ID: <4A6A9FCF.5020100@sun.com> 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 at research.att.com Sat Jul 25 01:47:11 2009 From: gsf at research.att.com (Glenn Fowler) Date: Sat, 25 Jul 2009 04:47:11 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <200907250847.n6P8lBon031464@penguin.research.att.com> 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 at gmail.com Sat Jul 25 03:20:00 2009 From: iszczesniak at gmail.com (I. Szczesniak) Date: Sat, 25 Jul 2009 12:20:00 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6A9FCF.5020100@sun.com> 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> Message-ID: 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 Alan.Coopersmith at Sun.COM Sat Jul 25 09:57:20 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sat, 25 Jul 2009 09:57:20 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6A9FCF.5020100@sun.com> 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> Message-ID: <4A6B3970.2000400@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From pkchris at users.sourceforge.net Sat Jul 25 11:14:17 2009 From: pkchris at users.sourceforge.net (Chris Pickett) Date: Sat, 25 Jul 2009 20:14:17 +0200 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> Message-ID: 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 at users.sourceforge.net From pkchris at users.sourceforge.net Sat Jul 25 11:22:31 2009 From: pkchris at users.sourceforge.net (Chris Pickett) Date: Sat, 25 Jul 2009 20:22:31 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: 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> Message-ID: > > #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 at users.sourceforge.net From pkchris at users.sourceforge.net Sat Jul 25 11:40:14 2009 From: pkchris at users.sourceforge.net (Chris Pickett) Date: Sat, 25 Jul 2009 20:40:14 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6B4E91.6020002@sun.com> 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> Message-ID: 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 at users.sourceforge.net From pkchris at users.sourceforge.net Sat Jul 25 11:48:16 2009 From: pkchris at users.sourceforge.net (Chris Pickett) Date: Sat, 25 Jul 2009 20:48:16 +0200 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> Message-ID: 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 at users.sourceforge.net From gdamore at sun.com Sat Jul 25 08:57:53 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 08:57:53 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: 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> Message-ID: <4A6B2B81.4090504@sun.com> 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 gdamore at sun.com Sat Jul 25 11:27:29 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 11:27:29 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6B3970.2000400@sun.com> 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> Message-ID: <4A6B4E91.6020002@sun.com> 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 gdamore at sun.com Sat Jul 25 11:32:27 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 11:32:27 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> Message-ID: <4A6B4FBB.1070808@sun.com> 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 unixconsole at yahoo.com Sat Jul 25 12:00:23 2009 From: unixconsole at yahoo.com (Octave Orgeron) Date: Sat, 25 Jul 2009 12:00:23 -0700 (PDT) Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> Message-ID: <543740.62070.qm@web30804.mail.mud.yahoo.com> 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 at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ----- Original Message ---- From: Garrett D'Amore To: Chris Pickett Cc: Korn Shell 93 integration/migration project discussion ; PSARC-ext at sun.com; Alan Coopersmith ; busybox-dev at 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 at opensolaris.org From unixconsole at yahoo.com Sat Jul 25 12:03:42 2009 From: unixconsole at yahoo.com (Octave Orgeron) Date: Sat, 25 Jul 2009 12:03:42 -0700 (PDT) Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: 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> Message-ID: <284568.16368.qm@web30803.mail.mud.yahoo.com> 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 at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ----- Original Message ---- From: I. Szczesniak To: Korn Shell 93 integration/migration project discussion Cc: PSARC-ext at 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 at opensolaris.org From gdamore at sun.com Sat Jul 25 12:25:11 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 12:25:11 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> Message-ID: <4A6B5C17.2000909@sun.com> 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 at sun.com Sat Jul 25 12:29:30 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 12:29:30 -0700 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> Message-ID: <4A6B5D1A.3060100@sun.com> 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 at sun.com Sat Jul 25 12:34:30 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 12:34:30 -0700 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <4A6B5D1A.3060100@sun.com> Message-ID: <4A6B5E46.9080508@sun.com> 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.Schilling at fokus.fraunhofer.de Sat Jul 25 13:02:33 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Sat, 25 Jul 2009 22:02:33 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> Message-ID: <4a6b64d9.t+U+sPjmqtv/jT2k%Joerg.Schilling@fokus.fraunhofer.de> 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 at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From johnsonnenschein at gmail.com Sat Jul 25 15:33:56 2009 From: johnsonnenschein at gmail.com (John Sonnenschein) Date: Sat, 25 Jul 2009 15:33:56 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6A9FCF.5020100@sun.com> 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> Message-ID: <99EA5DC1-F067-4B5D-9882-3AB9277F00F7@gmail.com> 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 at opensolaris.org From roland.mainz at nrubsig.org Sat Jul 25 17:06:06 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 26 Jul 2009 02:06:06 +0200 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <4A6B9DEE.6AA52908@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From carlsonj at workingcode.com Sat Jul 25 16:59:11 2009 From: carlsonj at workingcode.com (James Carlson) Date: Sat, 25 Jul 2009 19:59:11 -0400 Subject: [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> 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> Message-ID: <4A6B9C4F.4090302@workingcode.com> 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 matt at greenviolet.net Sat Jul 25 17:21:54 2009 From: matt at greenviolet.net (Matt Lewandowsky) Date: Sat, 25 Jul 2009 17:21:54 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] 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> 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> Message-ID: 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 at nrubsig.org Sat Jul 25 17:40:49 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 26 Jul 2009 02:40:49 +0200 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <4A6BA611.5C05D8F9@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Sat Jul 25 17:43:52 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 26 Jul 2009 02:43:52 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <4A6BA6C8.F52F1863@nrubsig.org> "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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore at sun.com Sat Jul 25 18:04:46 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 18:04:46 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6BA611.5C05D8F9@nrubsig.org> 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> Message-ID: <4A6BABAE.1060305@sun.com> 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 at nrubsig.org Sat Jul 25 18:16:33 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 26 Jul 2009 03:16:33 +0200 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <4A6BAE71.D8E03E03@nrubsig.org> 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 at opensolaris.org ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gsf at research.att.com Sat Jul 25 20:35:23 2009 From: gsf at research.att.com (Glenn Fowler) Date: Sat, 25 Jul 2009 23:35:23 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <200907260335.n6Q3ZNo9017329@penguin.research.att.com> 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 johnsonnenschein at gmail.com Sat Jul 25 19:19:37 2009 From: johnsonnenschein at gmail.com (John Sonnenschein) Date: Sat, 25 Jul 2009 19:19:37 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6B9C4F.4090302@workingcode.com> 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> Message-ID: <094CE525-A4ED-454B-B4CB-55C5C471DF22@gmail.com> 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 at research.att.com Sat Jul 25 21:09:11 2009 From: gsf at research.att.com (Glenn Fowler) Date: Sun, 26 Jul 2009 00:09:11 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <200907260409.n6Q49BRW017860@penguin.research.att.com> 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 at research.att.com Sat Jul 25 21:18:26 2009 From: gsf at research.att.com (Glenn Fowler) Date: Sun, 26 Jul 2009 00:18:26 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <200907260418.n6Q4IQXT018024@penguin.research.att.com> 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 at research.att.com Sat Jul 25 20:49:31 2009 From: gsf at research.att.com (Glenn Fowler) Date: Sat, 25 Jul 2009 23:49:31 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <200907260349.n6Q3nVXd017537@penguin.research.att.com> 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 at sun.com Sat Jul 25 21:45:21 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 21:45:21 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <200907260349.n6Q3nVXd017537@penguin.research.att.com> 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> Message-ID: <4A6BDF61.6050508@sun.com> 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 at sun.com Sat Jul 25 21:47:44 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 21:47:44 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <200907260409.n6Q49BRW017860@penguin.research.att.com> 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> Message-ID: <4A6BDFF0.8000500@sun.com> 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 at nrubsig.org Sat Jul 25 21:52:23 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 26 Jul 2009 06:52:23 +0200 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <4A6BE107.47F65A19@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore at sun.com Sat Jul 25 22:03:17 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sat, 25 Jul 2009 22:03:17 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6BE107.47F65A19@nrubsig.org> 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> Message-ID: <4A6BE395.9060108@sun.com> 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 at googlemail.com Sun Jul 26 06:42:21 2009 From: piochjennifer at googlemail.com (Jennifer Pioch) Date: Sun, 26 Jul 2009 15:42:21 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6BE395.9060108@sun.com> 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> Message-ID: <67079b830907260642x227fb18fhe6aedea0d6b167fd@mail.gmail.com> 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 piochjennifer at googlemail.com Sun Jul 26 06:44:38 2009 From: piochjennifer at googlemail.com (Jennifer Pioch) Date: Sun, 26 Jul 2009 15:44:38 +0200 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> Message-ID: <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> > On Wednesday at the PSARC meeting. Only regular PSARC members can vote. Who elected the PSARC members? Jenny -- Jennifer Pioch, Uni Frankfurt From joshhurst at gmail.com Sun Jul 26 09:21:18 2009 From: joshhurst at gmail.com (Josh Hurst) Date: Sun, 26 Jul 2009 18:21:18 +0200 Subject: [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> 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> Message-ID: 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 at Sun.COM Sun Jul 26 09:51:07 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sun, 26 Jul 2009 09:51:07 -0700 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> Message-ID: <4A6C897B.5020408@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From pkchris at users.sourceforge.net Sun Jul 26 11:25:00 2009 From: pkchris at users.sourceforge.net (Chris Pickett) Date: Sun, 26 Jul 2009 20:25:00 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: 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> Message-ID: 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 at users.sourceforge.net From carlsonj at workingcode.com Sun Jul 26 07:42:20 2009 From: carlsonj at workingcode.com (James Carlson) Date: Sun, 26 Jul 2009 10:42:20 -0400 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> Message-ID: 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 at sun.com Sun Jul 26 08:51:55 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sun, 26 Jul 2009 08:51:55 -0700 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> Message-ID: <4A6C7B9B.3040906@sun.com> 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 at sun.com Sun Jul 26 09:00:49 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sun, 26 Jul 2009 09:00:49 -0700 Subject: [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> 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> Message-ID: <4A6C7DB1.1050805@sun.com> 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 gdamore at sun.com Sun Jul 26 09:56:08 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sun, 26 Jul 2009 09:56:08 -0700 Subject: [busybox-dev] [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> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6C897B.5020408@sun.com> Message-ID: <4A6C8AA8.5030702@sun.com> 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 at yahoo.com Sun Jul 26 10:21:35 2009 From: unixconsole at yahoo.com (Octave Orgeron) Date: Sun, 26 Jul 2009 10:21:35 -0700 (PDT) Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6BE107.47F65A19@nrubsig.org> 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> Message-ID: <360931.20852.qm@web30805.mail.mud.yahoo.com> 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 at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ----- Original Message ---- From: Roland Mainz To: John Sonnenschein Cc: Alan Coopersmith ; Busybox development ; Garrett D'Amore ; ksh93-integration-discuss at opensolaris.org; PSARC-ext at 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ opensolaris-arc mailing list opensolaris-arc at opensolaris.org From roland.mainz at nrubsig.org Sun Jul 26 15:19:29 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Mon, 27 Jul 2009 00:19:29 +0200 Subject: [busybox-dev] Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> Message-ID: <4A6CD671.C536E21F@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Sun Jul 26 16:20:47 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Mon, 27 Jul 2009 01:20:47 +0200 Subject: [busybox-dev] PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> Message-ID: <4A6CE4CF.A3692F8E@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore at sun.com Sun Jul 26 16:00:57 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sun, 26 Jul 2009 16:00:57 -0700 Subject: [busybox-dev] Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6CD671.C536E21F@nrubsig.org> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> Message-ID: <4A6CE029.9030304@sun.com> 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 at nrubsig.org Sun Jul 26 16:30:07 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Mon, 27 Jul 2009 01:30:07 +0200 Subject: [busybox-dev] PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> Message-ID: <4A6CE6FF.AC216295@nrubsig.org> 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 at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From carlsonj at workingcode.com Sun Jul 26 18:13:48 2009 From: carlsonj at workingcode.com (James Carlson) Date: Sun, 26 Jul 2009 21:13:48 -0400 Subject: [busybox-dev] Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6CD671.C536E21F@nrubsig.org> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> Message-ID: <4A6CFF4C.8000304@workingcode.com> 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 at research.att.com Sun Jul 26 19:49:33 2009 From: gsf at research.att.com (Glenn Fowler) Date: Sun, 26 Jul 2009 22:49:33 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> Message-ID: <200907270249.n6R2nXqp017475@penguin.research.att.com> 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 at sun.com Sun Jul 26 20:46:45 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 26 Jul 2009 22:46:45 -0500 Subject: [busybox-dev] "derail" is not a bad thing (Re: PSARC/2009/414 _withdrawn_) In-Reply-To: <4A6CE4CF.A3692F8E@nrubsig.org> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> Message-ID: <20090727034645.GU1020@Sun.COM> 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 cedric.blancher at googlemail.com Sun Jul 26 23:55:46 2009 From: cedric.blancher at googlemail.com (Cedric Blancher) Date: Mon, 27 Jul 2009 08:55:46 +0200 Subject: [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> 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> Message-ID: 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 gsf at research.att.com Mon Jul 27 00:30:03 2009 From: gsf at research.att.com (Glenn Fowler) Date: Mon, 27 Jul 2009 03:30:03 -0400 Subject: [busybox-dev] [ksh93-integration-discuss] Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] 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> Message-ID: <200907270730.n6R7U330021722@penguin.research.att.com> 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 piochjennifer at googlemail.com Mon Jul 27 02:05:44 2009 From: piochjennifer at googlemail.com (Jennifer Pioch) Date: Mon, 27 Jul 2009 11:05:44 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6A4042.8000700@sun.com> <4A6B4FBB.1070808@sun.com> <4A6B5C17.2000909@sun.com> <67079b830907260644tb1c0fe5uc2fad0336fff8800@mail.gmail.com> Message-ID: <67079b830907270205o35813dc1t487b46e7c73ea153@mail.gmail.com> 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.Coopersmith at Sun.COM Mon Jul 27 07:15:04 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Mon, 27 Jul 2009 07:15:04 -0700 Subject: [busybox-dev] [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> 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> Message-ID: <4A6DB668.9010705@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith at Sun.COM Mon Jul 27 07:25:25 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Mon, 27 Jul 2009 07:25:25 -0700 Subject: [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> 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> Message-ID: <4A6DB8D5.6010303@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore at sun.com Sun Jul 26 21:21:04 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Sun, 26 Jul 2009 21:21:04 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <200907270249.n6R2nXqp017475@penguin.research.att.com> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <200907270249.n6R2nXqp017475@penguin.research.att.com> Message-ID: <4A6D2B30.2060105@sun.com> 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.Hargreaves at Sun.COM Mon Jul 27 02:24:00 2009 From: Alan.Hargreaves at Sun.COM (Alan Hargreaves) Date: Mon, 27 Jul 2009 19:24:00 +1000 Subject: [busybox-dev] [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> 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> Message-ID: <4A6D7230.6050208@Sun.COM> An HTML attachment was scrubbed... URL: From Alan.Hargreaves at Sun.COM Mon Jul 27 02:53:35 2009 From: Alan.Hargreaves at Sun.COM (Alan Hargreaves) Date: Mon, 27 Jul 2009 19:53:35 +1000 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty In-Reply-To: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> Message-ID: <4A6D791F.1010508@Sun.COM> I'm responding to the initial case here as I don't want this to be seen as an indictment on anyone who has participated in this "discussion" to this point. I've also taken the case out of the subject so this mail does not form part of the case log. Can I suggest that unless you have something constructive to add, that will further this case to a resolution acceptable to all parties, that you refrain from entering in to the discussion. Once one weeds out the noise, it can be seen that AlanC, Garrett, Roland and Glenn are actively trying to resolve Garett's concern. Threats of "I will no longer contribute to this project" are not helpful to this process, nor are ill-informed criticisms of the ARC process. If you wish to find out what the ARCs actually do, you should have a read of the Community page at http://opensolaris.org/os/community/arc/ You will also find there how *you* can participate in this process if you so desire. From my time interning with PSARC, it has been my experience that the ARC is a facilitator to having projects integrate in a consistent way with the existing codebase. Given the overview of all projects integrating, they have also quite often made suggestions of projects that a project team should talk with because of overlap that the project team were previously unaware of. As I stated in an earlier response, I can't think of the last time that the ARCs were responsible for killing a project, if indeed they ever were. Now if we let those folks who wish to discuss this constructively do so, we might actually get somewhere that will make everyone happy! Regards, Alan Hargreaves -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Asia Pacific/Emerging Markets Sun Microsystems From Neal.Pollack at Sun.COM Mon Jul 27 11:05:55 2009 From: Neal.Pollack at Sun.COM (Neal Pollack) Date: Mon, 27 Jul 2009 11:05:55 -0700 Subject: [busybox-dev] [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> 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> Message-ID: <4A6DEC83.9060407@Sun.Com> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdamore at sun.com Mon Jul 27 11:24:29 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Mon, 27 Jul 2009 11:24:29 -0700 Subject: [busybox-dev] [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> 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> Message-ID: <4A6DF0DD.2060003@sun.com> 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 dcragun at sonic.net Mon Jul 27 12:48:40 2009 From: dcragun at sonic.net (Don Cragun) Date: Mon, 27 Jul 2009 12:48:40 -0700 (PDT) Subject: [busybox-dev] [ksh93-integration-discuss] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] Message-ID: <20970.76.191.129.144.1248724120.squirrel@webmail.sonic.net> 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 Alan.Coopersmith at Sun.COM Mon Jul 27 14:12:57 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Mon, 27 Jul 2009 14:12:57 -0700 Subject: [busybox-dev] AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout 07/31/2009] In-Reply-To: <4A6B4E91.6020002@sun.com> 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> Message-ID: <4A6E1859.8060901@sun.com> [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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith at Sun.COM Mon Jul 27 21:46:43 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Mon, 27 Jul 2009 21:46:43 -0700 Subject: [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] In-Reply-To: <20090728033144.GB4724@sun.com> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <20090728033144.GB4724@sun.com> Message-ID: <4A6E82B3.3090300@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From gsf at research.att.com Tue Jul 28 07:07:48 2009 From: gsf at research.att.com (Glenn Fowler) Date: Tue, 28 Jul 2009 10:07:48 -0400 Subject: [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] 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> Message-ID: <200907281407.n6SE7mYR027316@penguin.research.att.com> 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 joshhurst at gmail.com Tue Jul 28 07:18:07 2009 From: joshhurst at gmail.com (Josh Hurst) Date: Tue, 28 Jul 2009 16:18:07 +0200 Subject: [busybox-dev] [ksh93-integration-discuss] 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] In-Reply-To: <4A6E82B3.3090300@sun.com> 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> Message-ID: 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 at Sun.COM Tue Jul 28 07:43:35 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Tue, 28 Jul 2009 07:43:35 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] 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] In-Reply-To: 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> Message-ID: <4A6F0E97.8030209@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith at Sun.COM Tue Jul 28 08:02:45 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Tue, 28 Jul 2009 08:02:45 -0700 Subject: [busybox-dev] PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: 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> 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> Message-ID: <4A6F1315.7030608@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering From carlsonj at workingcode.com Mon Jul 27 12:43:57 2009 From: carlsonj at workingcode.com (James Carlson) Date: Mon, 27 Jul 2009 15:43:57 -0400 Subject: [busybox-dev] [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> 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> Message-ID: <4A6E037D.8080402@workingcode.com> 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 gdamore at sun.com Mon Jul 27 13:00:34 2009 From: gdamore at sun.com (Garrett D'Amore) Date: Mon, 27 Jul 2009 13:00:34 -0700 Subject: [busybox-dev] [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> References: <20970.76.191.129.144.1248724120.squirrel@webmail.sonic.net> Message-ID: <4A6E0762.9010308@sun.com> 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 Jyri.Virkki at sun.com Mon Jul 27 20:31:45 2009 From: Jyri.Virkki at sun.com (Jyri Virkki) Date: Mon, 27 Jul 2009 20:31:45 -0700 Subject: [busybox-dev] PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about "--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-Reply-To: <4A6CE4CF.A3692F8E@nrubsig.org> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> Message-ID: <20090728033144.GB4724@sun.com> 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 at sun.com - Sun Microsystems From Joerg.Schilling at fokus.fraunhofer.de Tue Jul 28 07:27:42 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 28 Jul 2009 16:27:42 +0200 Subject: [busybox-dev] PSARC/2009/414 _withdrawn_ / was: Re: Some clarifications about"--help" and "--man" / Re: AST versions of fold, mktemp, pathchk, & tty [PSARC/2009/414 FastTrack timeout07/31/2009] In-Reply-To: <4A6CE6FF.AC216295@nrubsig.org> References: <200907242248.n6OMmkhp014589@sac.sfbay.sun.com> <4A6CD671.C536E21F@nrubsig.org> <4A6CE029.9030304@sun.com> <4A6CE4CF.A3692F8E@nrubsig.org> <4A6CE6FF.AC216295@nrubsig.org> Message-ID: <4a6f0ade.Gf+RMIOOtc1CvcqR%Joerg.Schilling@fokus.fraunhofer.de> 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 at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Alan.Coopersmith at Sun.COM Tue Jul 28 19:19:28 2009 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Tue, 28 Jul 2009 19:19:28 -0700 Subject: [busybox-dev] [ksh93-integration-discuss] 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] In-Reply-To: <4A6E82B3.3090300@sun.com> 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> Message-ID: <4A6FB1B0.2080602@sun.com> 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 at sun.com Sun Microsystems, Inc. - X Window System Engineering