From gdamore@sun.com Wed Apr 15 14:05:39 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3FL5dhs028709 for ; Wed, 15 Apr 2009 14:05:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3FL5clr000221 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 15 Apr 2009 15:05:39 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI500G3PULCFT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 15:05:36 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI500EUPUL8HU10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 15:05:32 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3FL5WN3000375 for ; Wed, 15 Apr 2009 14:05:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI500300U32KV00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 14:05:32 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI500HM9UL59JE0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 15 Apr 2009 14:05:30 -0700 (PDT) Date: Wed, 15 Apr 2009 14:05:29 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/228 ls enhancements Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <49E64C19.9080207@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7399 ARC infrastructure ate the materials for this case. The case timeout is extended to April 22, 2009, as a result. The proposal follows. Note that this case is submitted on behalf of Jason King, and is seeking patch binding, but expects only to push to OpenSolaris/Nevada at this point. Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ls enhancements 1.2. Name of Document Author/Supplier: Jason King 1.3. Date of This Document: 03/01/2009 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: ON 1.4.2. The ARC(s) you expect to review your project: 1.5. Email Aliases: 1.5.2. Responsible Engineer: 1.5.4. Interest List: on-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: Enhance ls to provide a number of features to increase compatibility with other ls implementations (with an emphasis on GNU ls). This is a combination of new flags and long aliases for existing flags. The project is requesting patch binding. 2.2. Risks and Assumptions: 3. Business Summary 3.1. Problem Area: The Solaris ls is missing a number of features found in other ls implementations. Color output is an especially popular missing feature. 3.2. Market/Requester: Opensolaris community 3.3. Business Justification: The current situation is a worst of all worlds situation. Common features found on other OSes are missing in Solaris ls. GNU ls does not support a number of key features in Solaris (NFS/ZFS ACLs and extended attributes). This leaves a user to choose one or the other. This project proposes to enhance Solaris to support a number of common GNU ls features (detailed below) 3.4. Competitive Analysis: 3.5. Opportunity Window/Exposure: 3.6. How will you know when you are done?: Solaris ls will support the listed features below. 4. Technical Description: 4.1. Details: The following flags will be added to ls(1) (/usr/bin/ls, /usr/xpg4/bin/ls, and /usr/xpg6/bin/ls): Aliases for existing flags: --all Alias for -a --almost-all Alias for -A --escape Alias for -b --classify Alias for -F --human-readable Alias for -h --dereference Alias for -L --dereference-command-link Alias for -H --full-time Alias for -E --inode Alias for -i --numeric-uid-gid Alias for -n --no-group Alias for -o --hide-control-chars Alias for -q --reverse Alias for -r --recursive Alias for -R --size Alias for -s New flags: -w=NN, --width=NN Force output width to NN columns. --block-size=NN Output sizes as multiples of NN. The suffixes 'kKmMgGtTpPeE' can be appended to scale the block size. -k Equivalent to --block-size=1024. --si Like -h, except powers of 10 are used. --color[=WHEN], --colour[=WHEN] Display output using colors. Colors are specified by the environment variable LS_COLORS. If not set, a default set of colors used. The format of LS_COLORS is compatible with GNU ls. WHEN is an optional flag indicating when color output should be used. Valid values are: always,yes,force: Always output color auto,tty,if-tty: Display color when run from a tty never,no,none: Never display color. The default setting is 'never'. --file-type Like the -F / --classify option, except * is not appended to executables. --time-style=[STYLE] Use STYLE as the output format for times. Does not imply -l option (but will not have any visible impact without -l). The notion of 'new' and 'old' files are unchanged from the current version of ls. Values of STYLE are: full-iso: Full iso output for all files, like -E long-iso: Use '%F %R' format for all files (YYYY-mm-dd HH:MM) iso: Use '%F' (YYYY-mm-dd) for older files and '%m-%d %H:%M' (mm-DD HH:MM) for newer files. locale: Use the locale defined format for old and new files (the default). +FMT: Use a custom format. Values of FMT are the same as strftime(3c). If a newline is embedded in FMT, then the first line is used for older files while the second line is used for newer files. If no newline is embedded, the single format is used for all files. Argument processing is done via getopt_long_only(3c) to prevent standards conformance issues. 4.2. Bug/RFE Number(s): 1122699 *ls* ls: would like to have -k option like du does 6803941 Make /usr/bin/ls more compatible with gnu ls 4.3. In Scope: 4.4. Out of Scope: 4.5. Interfaces: External: libtermcap 4.6. Doc Impact: Man page changes for ls(1) with changes included with case. 4.7. Admin/Config Impact: Additional cmdline flags only. 4.8. HA Impact: None 4.9. I18N/L10N Impact: Additional messages. 4.10. Packaging & Delivery: None 4.11. Security Impact: None 4.12. Dependencies: None 5. Reference Documents: // List of related documents, if any (BugID's, RFP's, papers). // Explain how/where to obtain the documents, and what each // contains, not just their titles. Identify any related projects // (by ID or case number, if possible). 6. Resources and Schedule: 6.1. Projected Availability: // Dates in appropriate precision (quarters, years) 6.2. Cost of Effort: // Order of magnitude people and time for the *whole* project, not // just the development engineering part. // You may wish to split the estimate between feature // implementation, implementing adminsitrative Interfaces, unit // tests, documentation, support training material, i18n, etc. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: 6.4.7. Target RTI Date/Release: // List target release & build and/or date. // RTI = Request to Integrate - when does *this* project // expect to be ready to integrate its changes back into // the master source tree? We are not asking when the // component wants to ship, but instead, when the // gatekeeper/PM needs to expect your changes to show up. // examples: S8u7_1, S9_45, Aug 2002... 6.4.8. Target Code Design Review Date: 6.5. ARC review type: SelfReview 6.6. ARC Exposure: open 6.6.1. Rationale: Part of OpenSolaris 7. Prototype Availability: 7.1. Prototype Availability: 7.2. Prototype Cost: From glenn.skinner@sun.com Thu Apr 16 09:49:33 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3GGnXZM004033 for ; Thu, 16 Apr 2009 09:49:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3GGnW0H049004 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 16 Apr 2009 10:49:32 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI70041DDEK2A00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 16 Apr 2009 09:49:32 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI7000QQDE0VO60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 16 Apr 2009 09:49:12 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id n3GGnCsZ012771 for ; Thu, 16 Apr 2009 09:49:12 -0700 (PDT) Date: Thu, 16 Apr 2009 09:49:12 -0700 (PDT) From: Glenn Skinner Subject: Re: PSARC 2009/228 ls enhancements To: PSARC-ext@sun.com Reply-to: Glenn Skinner Message-id: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: beisesnbQNK412Qx7BEbBw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 912 Date: Wed, 15 Apr 2009 14:05:29 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/228 ls enhancements ... The proposal follows. Note that this case is submitted on behalf of Jason King, and is seeking patch binding, but expects only to push to OpenSolaris/Nevada at this point. This information is Copyright 2007 Sun Microsystems ... 4. Technical Description: 4.1. Details: The following flags will be added to ls(1) (/usr/bin/ls, /usr/xpg4/bin/ls, and /usr/xpg6/bin/ls): ... This project is long overdue as a familiarity aid. My thanks to all who are helping make it happen. But before I give my +1, a quick question: Have you verified that adding the new flags to the /usr/xpg*/bin/ls variants is ok from the standpoint of standards conformance? If the answer is affirmative, I'm happy with the proposal. -- Glenn From jason.brian.king@gmail.com Thu Apr 16 10:07:27 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3GH7Qt9005035 for ; Thu, 16 Apr 2009 10:07:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3GH7Mg6026566; Thu, 16 Apr 2009 18:07:24 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI700I0NE8BL400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 16 Apr 2009 10:07:23 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI7004V6E8ATC80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 16 Apr 2009 10:07:22 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3GGpauO011188; Thu, 16 Apr 2009 17:07:22 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-465236; Thu, 16 Apr 2009 17:07:19 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-11331685; Thu, 16 Apr 2009 17:07:15 +0000 (Z) Received: from mail-qy0-f136.google.com ([209.85.221.136] [209.85.221.136]) by relay1i.sun.com with ESMTP id BT-MMP-9748437; Thu, 16 Apr 2009 17:07:15 +0000 (Z) Received: by mail-qy0-f136.google.com with SMTP id 42so99005qyk.30 for ; Thu, 16 Apr 2009 10:07:12 -0700 (PDT) Received: by 10.224.19.194 with SMTP id c2mr2066480qab.25.1239901632111; Thu, 16 Apr 2009 10:07:12 -0700 (PDT) Date: Thu, 16 Apr 2009 12:07:12 -0500 From: Jason King Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iDBwsecB7jIgf27k7P3uQLpZWUT12tPowAw87oGzbrY=; b=C9O15GEYaWGtgzW53akBD3q+jb/SsEMspOyQSSrg9CvPmf9R8iuPmzFi8+6b/PoF0S rRdwWk4YupTiY4fszM9ZyoubUH11fVs/v987LTzxCGJU9clI1TAHxT8qFowRYnq4azB5 jgA8R6UaNU3YQrmY8jLXStlHuOuBTQrS6/TKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YdC70qtEOXvT7KQCjgbg7ewY5MMkfwBfb17M+gnhj/X1S4j4uCc3jWr44l1lQeQqrs wp0gYQ7FkPFOEXZPQ+MGsM8n3n4FnwaYhvKs3Srt/P40fI4rS3xGTc3Zwjp/Uk2xWS4u WrcSLmIqGFcrWMb0x6vncLu3C0czBusckZ8WI= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.019sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n3GH7Qt9005035 Status: RO Content-Length: 1736 On Thu, Apr 16, 2009 at 11:49 AM, Glenn Skinner wrote: >    Date: Wed, 15 Apr 2009 14:05:29 -0700 >    From: "Garrett D'Amore" >    Subject: PSARC 2009/228 ls enhancements > >    ... >    The proposal follows.  Note that this case is submitted on behalf >    of Jason King, and is seeking patch binding, but expects only to >    push to OpenSolaris/Nevada at this point. > >    This information is Copyright 2007 Sun Microsystems > >    ... >    4. Technical Description: >        4.1. Details: >        The following flags will be added to ls(1) (/usr/bin/ls, >        /usr/xpg4/bin/ls, and /usr/xpg6/bin/ls): >        ... > > This project is long overdue as a familiarity aid.  My thanks to all > who are helping make it happen. > > But before I give my +1, a quick question:  Have you verified that > adding the new flags to the /usr/xpg*/bin/ls variants is ok from the > standpoint of standards conformance?  If the answer is affirmative, > I'm happy with the proposal. Unfortunately I'm not a standards language lawyer, so it's difficult for me to know what things I need to look out for. The one thing I'm aware of is the cmdline option processing (and to not reorder arguments). I was told using getopt_long_only(3c) avoids this issue (which is what the code does). If there are specific nits you are concerned about, there is a webrev you can browse at http://cr.opensolaris.org/~jason/ls -- I know the order is a bit backwards (code, then ARC), but was written mostly to illustrate that the time spent on the periodic gnu vs solaris ls/etc./ discussions take more time than to actually write the code to settle the issue, then it was 'ok, probably should get this integrated' :) From Jyri.Virkki@sun.com Thu Apr 16 16:24:26 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3GNOQYI008844 for ; Thu, 16 Apr 2009 16:24:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3GNOQjp000217; Thu, 16 Apr 2009 16:24:26 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI700301VOQN800@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Apr 2009 16:24:26 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI700KVIVOPIB60@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Apr 2009 16:24:26 -0700 (PDT) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GNOPFZ021288; Thu, 16 Apr 2009 23:24:25 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n3GNOPe04299; Thu, 16 Apr 2009 16:24:25 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n3GNOPIE004845; Thu, 16 Apr 2009 16:24:25 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n3GNOO7M004844; Thu, 16 Apr 2009 16:24:24 -0700 (PDT) Date: Thu, 16 Apr 2009 16:24:24 -0700 From: Jyri Virkki Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <49E64C19.9080207@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <20090416232424.GF28034@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <49E64C19.9080207@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 398 Garrett D'Amore wrote: > > 3.6. How will you know when you are done?: > Solaris ls will support the listed features below. Not really an issue, just out of curiosity... does this case add all flags to achieve option parity with GNU ls or is it a subset; if the latter, is there a table showing the ones this case doesn't tackle? -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From jason.brian.king@gmail.com Thu Apr 16 16:28:35 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3GNSYM1008861 for ; Thu, 16 Apr 2009 16:28:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3GNSJAV023837; Fri, 17 Apr 2009 07:28:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI700K01VVHBY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 16 Apr 2009 16:28:29 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI700MUYVVGO080@nwk-avmta-1.sfbay.Sun.COM>; Thu, 16 Apr 2009 16:28:29 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3GNNknG003122; Thu, 16 Apr 2009 23:28:28 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-490877; Thu, 16 Apr 2009 23:28:28 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-193370; Thu, 16 Apr 2009 23:28:28 +0000 (Z) Received: from rv-out-0708.google.com ([209.85.198.243] [209.85.198.243]) by relay1i.sun.com with ESMTP id BT-MMP-10380283; Thu, 16 Apr 2009 23:28:28 +0000 (Z) Received: by rv-out-0708.google.com with SMTP id l33so550896rvb.8 for ; Thu, 16 Apr 2009 16:28:22 -0700 (PDT) Received: by 10.141.12.15 with SMTP id p15mr959342rvi.43.1239924502005; Thu, 16 Apr 2009 16:28:22 -0700 (PDT) Date: Thu, 16 Apr 2009 18:28:21 -0500 From: Jason King Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <20090416232424.GF28034@sun.com> To: Jyri Virkki Cc: "Garrett D'Amore" , PSARC-ext Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MUg8kammEUxmRLKWCRaesAn/woMt8Xb+/byPyR9q21E=; b=CoP41Yxv0Ch6JvlI8hH2XXSGHpAIut8fpcAX9SsjGZr3qanAimhJ/ML6mPDr9G1rEO 1C6N9qcJFrznKFtcRR546ctMLDITffmjdjiACsVXsAzgW190/cEL/qZQIoyp3zGg+bsZ EjfYRarX7mO6iUlXCvZHwo1AiTaVjp4f4ntT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jdBKdCIvuYOPswZbUAwYjdyG0V8W9pyCm396YkFO4L7hiT0/zf0AwWOxguINlJ+eaT gXvdVuDYQgxjlD2RggBGLBwNYC2qi1GqkEU2/2mCXHMiCW3zYfGRnOH5B0s4gfJU0S+0 xCaJ1xUmDYwuIOGB0E83JGC4As2yeX95GOVd4= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <49E64C19.9080207@sun.com> <20090416232424.GF28034@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n3GNSYM1008861 Status: RO Content-Length: 499 On Thu, Apr 16, 2009 at 6:24 PM, Jyri Virkki wrote: > Garrett D'Amore wrote: >> >>   3.6. How will you know when you are done?: >>    Solaris ls will support the listed features below. > > Not really an issue, just out of curiosity... does this case add all > flags to achieve option parity with GNU ls or is it a subset; if the > latter, is there a table showing the ones this case doesn't tackle? A large subset, the biggest one being --color. I can create one if needed. From Jyri.Virkki@sun.com Thu Apr 16 17:37:37 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3H0baPI009809 for ; Thu, 16 Apr 2009 17:37:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3H0bYli029924 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 17 Apr 2009 01:37:36 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI700M05Z2MBT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 16 Apr 2009 18:37:34 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI7000XJZ2M2O90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 16 Apr 2009 18:37:34 -0600 (MDT) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3H0bWXL014218; Fri, 17 Apr 2009 00:37:32 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id n3H0bWV12174; Thu, 16 Apr 2009 17:37:32 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id n3H0bWD2007066; Thu, 16 Apr 2009 17:37:32 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id n3H0bW2s007065; Thu, 16 Apr 2009 17:37:32 -0700 (PDT) Date: Thu, 16 Apr 2009 17:37:32 -0700 From: Jyri Virkki Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: To: Jason King Cc: PSARC-ext Message-id: <20090417003731.GH28034@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <49E64C19.9080207@sun.com> <20090416232424.GF28034@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 463 Jason King wrote: > > > Not really an issue, just out of curiosity... does this case add all > > flags to achieve option parity with GNU ls or is it a subset; if the > > latter, is there a table showing the ones this case doesn't tackle? > > A large subset, the biggest one being --color. > > I can create one if needed. Not a requirement from me; just an informative nice-to-have if time permits. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Brian.Ruthven@sun.com Mon Apr 20 02:22:33 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3K9MVc3025941 for ; Mon, 20 Apr 2009 02:22:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3K9MSwA024998 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Apr 2009 10:22:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00M077DH1000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 02:22:29 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE00FKW7DFE560@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 02:22:28 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3K9MLHF016834; Mon, 20 Apr 2009 09:22:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00L005YMLM00@fe-emea-09.sun.com>; Mon, 20 Apr 2009 10:22:21 +0100 (BST) Received: from [129.156.173.239] ([unknown] [129.156.173.239]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE000TT7CTE8B0@fe-emea-09.sun.com>; Mon, 20 Apr 2009 10:22:07 +0100 (BST) Date: Mon, 20 Apr 2009 10:22:04 +0100 From: Brian Ruthven - Sun UK Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: Sender: Brian.Ruthven@sun.com To: Jason King Cc: Glenn Skinner , PSARC-ext@sun.com Message-id: <49EC3EBC.6090204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Status: RO Content-Length: 1165 Jason King wrote: > The one thing I'm aware of is the cmdline option processing (and to > not reorder arguments). I was told using getopt_long_only(3c) avoids > this issue (which is what the code does). > The man page (on snv_110 at least) for getopt_long(3C) discourages getopt_long_only for new apps: Use of getopt_long_only() is strongly discouraged by Sun and GNU for new applications. ... and again: NOTES ... The getopt_long_only() function is provided by Solaris and GNU for legacy applica- tions and its use is discouraged by both current conven- tions. Does this modification count as a "new application"? > If there are specific nits you are concerned about, there is a webrev > you can browse at http://cr.opensolaris.org/~jason/ls -- I know the Webrev location appears wrong (gives me a "D'oh!" page). It would seem to be: http://cr.opensolaris.org/~jbk/ls/ Is that right? Thanks, Brian -- Brian Ruthven Sun Microsystems UK Solaris Revenue Product Engineering Tel: +44 (0)1252 422 312 Sparc House, Guillemont Park, Camberley, GU17 9QG From jason.brian.king@gmail.com Mon Apr 20 07:35:41 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KEZeit025555 for ; Mon, 20 Apr 2009 07:35:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3KEZa4o014873 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 20 Apr 2009 22:35:39 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00G1HLVDU400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 20 Apr 2009 07:35:37 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE009IALV8VLA0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 20 Apr 2009 07:35:36 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KEWjnn023344 for ; Mon, 20 Apr 2009 14:35:32 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay12i.sun.com with ESMTP id BT-MMP-703752 for psarc-ext@sun.com; Mon, 20 Apr 2009 14:35:23 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-19583838 for psarc-ext@sun.com; Mon, 20 Apr 2009 14:35:19 +0000 (Z) Received: from yw-out-1718.google.com ([74.125.46.152] [74.125.46.152]) by relay1i.sun.com with ESMTP id BT-MMP-17131713 for psarc-ext@sun.com; Mon, 20 Apr 2009 14:35:07 +0000 (Z) Received: by yw-out-1718.google.com with SMTP id 4so1668756ywq.68 for ; Mon, 20 Apr 2009 07:34:58 -0700 (PDT) Received: by 10.151.45.6 with SMTP id x6mr6458459ybj.111.1240238098561; Mon, 20 Apr 2009 07:34:58 -0700 (PDT) Date: Mon, 20 Apr 2009 09:34:58 -0500 From: Jason King Subject: PSARC 2009/228 ls enhancements In-reply-to: Sender: jason.brian.king@gmail.com To: PSARC-ext Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=jRaOSyxAAwHITuMXLL8mkcFGsxHkdy52dfI74a9lzrM=; b=B/+yKo2UWrrYO2wCtcDZj4P+QqXyJOXPUWZxJZc9HCx8+OSQioWqZDSFYLiFCT3RPC UJ4IKmFMySNvO0Jw0wZkEbQiteIaIO1B3F2y/kpPmAXpxniyxHOkEN4hOhI+x/fMCRPt +8tKnAxdZJ+Xjtget2m1yGMrzf9K+M0ara38o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=rjgjeVKC8SxtDxoqx3srlGoIv7AhNYEJOSrz3EMs3AS7nrxrcZrmM6afoaBOmwYuI7 Ku4XSoUrssj5c2IK4SikH7qveWuBs/chn2ZSm1IZiIWjyf3VA9sgJA4qe5k3NF2UCNWR L0ChqanICBt/d7k71sAhh4BVOogce/AlRkMiM= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 6a827657e74fd72c X-Antispam: No, score=-0.2/5.0, scanned in 3.365sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> <49EC3EBC.6090204@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n3KEZeit025555 Status: RO Content-Length: 1716 On Mon, Apr 20, 2009 at 4:22 AM, Brian Ruthven - Sun UK wrote: > > > Jason King wrote: >> >> The one thing I'm aware of is the cmdline option processing (and to >> not reorder arguments).  I was told using getopt_long_only(3c) avoids >> this issue (which is what the code does). >> > > The man page (on snv_110 at least) for getopt_long(3C) discourages > getopt_long_only for new apps: > > >  Use of >    getopt_long_only() is strongly discouraged by  Sun  and  GNU >    for new applications. > ... > > and again: > > NOTES > ... >    The getopt_long_only() >    function is provided by Solaris and GNU for legacy  applica- >    tions  and  its  use  is discouraged by both current conven- >    tions. > > > Does this modification count as a "new application"? I'm not sure.  GNU ls has some options that are only available via long options.  There are few letters left to provide equivalent short options, so the other getopt_* functions cannot be used.  So then is support for those options dropped?  I'm not sure where the line is on that (probably a good ARC question though :) ). > > >> If there are specific nits you are concerned about, there is a webrev >> you can browse at http://cr.opensolaris.org/~jason/ls  -- I know the > > Webrev location appears wrong (gives me a "D'oh!" page). It would seem to > be: >   http://cr.opensolaris.org/~jbk/ls/ > Is that right? Whoops, yes ~jbk is the correct URL... fingers moving faster than the brian :) > > Thanks, > Brian > > -- > Brian Ruthven                                        Sun Microsystems UK > Solaris Revenue Product Engineering             Tel: +44 (0)1252 422 312 > Sparc House, Guillemont Park, Camberley, GU17 9QG > > From Darren.Moffat@sun.com Mon Apr 20 07:59:12 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KExCbh025980 for ; Mon, 20 Apr 2009 07:59:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KEwrLc011389 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Apr 2009 07:59:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE0081FMYMVN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 08:59:10 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE00F4LMYLYIC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 08:59:09 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KEx85f016991 for ; Mon, 20 Apr 2009 14:59:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00H00MNHCR00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 15:59:08 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00H5LMY3F040@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 15:58:51 +0100 (BST) Date: Mon, 20 Apr 2009 15:58:51 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: Sender: Darren.Moffat@sun.com To: Jason King Cc: PSARC-ext Message-id: <49EC8DAB.9020109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> <49EC3EBC.6090204@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1565 Given that the point of this case is to remodel the OpenSolaris ls to be more like the GNU ls I can say that the "when in Rome" rule from CLIP applies here and long options without a corresponding short one should be allowed. That is after all the point of this case, to make the OpenSolaris /usr/bin/ls more like the /usr/gnu/bin/ls one while still maintaining its OpenSolaris unique features. So does this set precedence to ignore the CLIP restriction ? No I don't think it does since all the long options introduced in this case have a 1:1 match in the corresponding GNU program. If on the other hand the case attempted to add new long options (without matching short ones) to ls that had no corresponding GNU option then I'd say it possibly violates the intent of the CLIP case. Or if that doesn't convince, my opinion is that GNU getopt got it correct and the CLIP case got it wrong. That is I fully support long options that have no corresponding short option, otherwise IMO there was really little point in adding the long options as all it reduces to is an alias, when the real point was moving beyond 26 (or may 26+9+some other small number for strange stuff like -/ and -@). So as far as long options are concerned I have no issue with this case. Before I give full endorsement I would like to review a table (or other way or presenting the data) that shows where the /usr/bin/ls would still be lacking from the GNU one, though I doubt the content of it will sway my choice (which is likely to be approval). -- Darren J Moffat From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.de Mon Apr 20 08:37:06 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KFb6ms022734 for ; Mon, 20 Apr 2009 08:37:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KFaeFN033034 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Apr 2009 09:37:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00J5BOPTXS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 08:37:05 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE00INJOO7LR50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 08:36:08 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KFa7R3027875 for ; Mon, 20 Apr 2009 15:36:07 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-708661 for PSARC-ext@sun.com; Mon, 20 Apr 2009 15:36:07 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-40985 for PSARC-ext@sun.com; Mon, 20 Apr 2009 15:36:04 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-17218769 for PSARC-ext@sun.com; Mon, 20 Apr 2009 15:36:04 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 2F24119400D; Mon, 20 Apr 2009 17:30:17 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id D7CCA6F0410; Mon, 20 Apr 2009 17:30:16 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id n3KFUHl7026226; Mon, 20 Apr 2009 17:30:17 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 17:30:16 +0200 Date: Mon, 20 Apr 2009 17:30:16 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <49EC8DAB.9020109@Sun.COM> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.de To: jason@ansipunx.net, Darren.Moffat@sun.com Cc: PSARC-ext@sun.com Message-id: <49ec9508.U7HOOL4OszSytBuw%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 1.462sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> <49EC3EBC.6090204@sun.com> <49EC8DAB.9020109@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 20 Apr 2009 15:30:16.0867 (UTC) FILETIME=[E81FFF30:01C9C1CC] Status: RO Content-Length: 3225 Darren J Moffat wrote: > So does this set precedence to ignore the CLIP restriction ? No I don't > think it does since all the long options introduced in this case have a > 1:1 match in the corresponding GNU program. If on the other hand the > case attempted to add new long options (without matching short ones) to > ls that had no corresponding GNU option then I'd say it possibly > violates the intent of the CLIP case. As I mentioned with some other case already, the POSIX standard does not forbid long options, it just gives rules that _should_ be followed. See: http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 The interesting thing here is that following POSIX, -help would ignore less POSIX CLI rules than --help does. In any case, there is absolutely no reason to require a related short option for each long option. This is true in special if the number of options is already > 60. Note that the POSIX standard does include a getopt() definition but it does not require programs to use this function. If you have a better implementation to parse options, it is of course permitted to use this rather than using getopt(). > Or if that doesn't convince, my opinion is that GNU getopt got it > correct and the CLIP case got it wrong. That is I fully support long > options that have no corresponding short option, otherwise IMO there was > really little point in adding the long options as all it reduces to is > an alias, when the real point was moving beyond 26 (or may 26+9+some > other small number for strange stuff like -/ and -@). I dislike - type option except when they do some useful thing like e.g. -/ in star where it allows the use of absolute path names. The GNU getopt_long() implementation is a real problem as it has plenty of implementation bugs. I did not check the implementation that is inside Sun's libc. There is a general problem with all long options that have arguments. The GNU getopt_long() implementation allows to use --foobar for a --foo option with a "bar" argument. Unfortunately GNU getopt_long() also allows abbreviations for long options and thus misstyped options may cause a similar option to get a parameter that cannot easily be detectes as illegal. In general, long options need planning in order to avoid common left side substrings and a useful option parser should allow to be told not to allow --foobar but only --foo=bar or --foo bar (or better -foo=bar / -foo bar see above). My option parser family "getargs" allows to control the behavior and it allows to do much more than GNU getopt_long(). If you are interedted to see how a an application that was designed for GNU getopt_long() can be converted to use getargs(), have a look at recent versions of mkisofs. BTW: The getargs family is more than 25 years old and predates the appearance of GNU getopt_long(). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From jason.brian.king@gmail.com Mon Apr 20 18:23:39 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3L1NcxD003389 for ; Mon, 20 Apr 2009 18:23:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3L1NUGu001606 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 21 Apr 2009 02:23:37 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIF00109FVCUX00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 20 Apr 2009 19:23:36 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIF009YGFVBDKD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 20 Apr 2009 19:23:35 -0600 (MDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3L1Mnhp023813 for ; Tue, 21 Apr 2009 01:23:35 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay12i.sun.com with ESMTP id BT-MMP-745114 for psarc-ext@sun.com; Tue, 21 Apr 2009 01:23:35 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-389793 for psarc-ext@sun.com; Tue, 21 Apr 2009 01:23:34 +0000 (Z) Received: from yw-out-1718.google.com ([74.125.46.156] [74.125.46.156]) by relay1i.sun.com with ESMTP id BT-MMP-17983453 for psarc-ext@sun.com; Tue, 21 Apr 2009 01:23:34 +0000 (Z) Received: by yw-out-1718.google.com with SMTP id 4so1893423ywq.68 for ; Mon, 20 Apr 2009 18:23:27 -0700 (PDT) Received: by 10.150.212.14 with SMTP id k14mr7418278ybg.194.1240277007080; Mon, 20 Apr 2009 18:23:27 -0700 (PDT) Date: Mon, 20 Apr 2009 20:23:27 -0500 From: Jason King Subject: PSARC 2009/228 ls enhancements In-reply-to: Sender: jason.brian.king@gmail.com To: PSARC-ext Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=3AAQZLjXBQJZNLgfYhIjAjd2w+SjM/e+NWlq4jj7ctE=; b=GOgFQoOvFx7nLtf9ogi8MDr9h1ycMF+Fu1pMcJq3WvHybNbD94hfwEMqJoymOA8uuQ 7MIwfm4nNByKHiK7Ez8EDovPToa6+wCYy9joJYDpiAGyg7Fnd6jRvoT95U4C6tHycpMG Sdhjmhndj8Um1ihkxV+VcvWFGx1qOmn+dfdXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=hcRwVBdXKfYJDtF1KLiiU2Fo8uIbX/1GGhH8/Kyx3VizSQyOafjj1Q4R5hCMzDYJHf 82NCsA9PorCyAeP6ZFfFLZ9sKzA3BofvgVxgTuhEFJn9xhTsxB3sWYDxUnsmERHMauIn m+WFXMj8B4MEFU6Qe+hRhtGPRhu7eSG9ztA2U= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 45ba2ccdae442e93 X-Antispam: No, score=0.0/5.0, scanned in 0.065sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> <20090420180544.GM1500@Sun.COM> Status: RO Content-Length: 2786 Instead of a single table detailing the options, I've broken it down, as I think that makes it a bit easier: New Flags --------------- -k -- Display size in multiples of 1024 bytes -U -- Do not sort output -w n, --width=n -- Force output to n columns wide --block-size=n -- Use multiples of N bytes as size --si -- Like -h, except powers of 10 are used instead of 2 --color=when, --colour=when -- Colorized output --file-type -- Like -F, except * isn't appended --time-style=s -- Use custom time output format s Aliases for existing flags (single letter flags are the current Solaris values) ----------------------------------- --all -a --almost-all -A --escape -b --classify -f --human-readable -h --dereference -L --dereference-command-line -H --ignore-backups -B --inode -i --numeric-uid-gid -n --no-group -o --hide-control-chars -q --reverse -r --recursive -R --size -s Not Implemented ------------------------- --author Display author of file -D, --dired Output in emacs dired format --dereference-command-link-symlink-to-dir follow symlinks that are to directories --hide=PATTERN Do not output files matching PATTERN (overridden by -a or -A) --indicator-style=WORD append indicator with style WORD to entry names -I, --ignore=PATTERN do not output files matching PATTERN -N, --literal Print raw entry names --show-control-chars show non graphic characters as-is -Q --quote-name enclose entry names in double quotes --quoting-style=WORD use quoting style WORD for entry names --sort=WORD sort by: extension, none, size, time, version, status, time, atime, access, use --time=WORD display WORD (atime, access, use, ctime, or status) for time, also used as sort key -T, --tabsize=COLS assume tab stops at every multiple of COLS instead of 8 -v sort by version -X sort alphabetically by entry extension From Darren.Moffat@sun.com Tue Apr 21 01:38:24 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3L8cNwk002272 for ; Tue, 21 Apr 2009 01:38:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3L8c7Og027527 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 21 Apr 2009 09:38:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIF00C01ZZX8000@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 01:38:21 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIF000GEZZWE450@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 01:38:21 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3L8cK0g015244 for ; Tue, 21 Apr 2009 08:38:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIF00900Z01P000@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 09:38:20 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIF00H4KZZI1M40@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 09:38:06 +0100 (BST) Date: Tue, 21 Apr 2009 09:38:07 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: Sender: Darren.Moffat@sun.com To: Jason King Cc: PSARC-ext Message-id: <49ED85EF.6080704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904161649.n3GGnCsZ012771@ivrel.sfbay.sun.com> <20090420180544.GM1500@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 512 Jason King wrote: > --sort=WORD sort by: > extension, none, size, time, version, status, time, atime, access, use > --time=WORD display WORD > (atime, access, use, ctime, or status) for time, also used as sort key Of those not implement these two seem the most interesting to me and it would be nice to see them implemented, but I won't hold the case up for that. As the case is specified it gets my +1. -- Darren J Moffat From glenn.skinner@sun.com Tue Apr 21 14:52:56 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LLqtqf010017 for ; Tue, 21 Apr 2009 14:52:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3LLqt5t018244 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 21 Apr 2009 15:52:55 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIH00I070S67G00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 14:52:54 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIH0066B0S59J60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 14:52:53 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id n3LLjNCb017322; Tue, 21 Apr 2009 14:45:23 -0700 (PDT) Date: Tue, 21 Apr 2009 14:45:23 -0700 (PDT) From: Glenn Skinner Subject: Re: PSARC 2009/228 ls enhancements To: jason@ansipunx.net Cc: psarc-ext@sun.com Reply-to: Glenn Skinner Message-id: <200904212145.n3LLjNCb017322@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Ceul8YaNKtqycxX/WKjXmw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1008 Date: Tue, 21 Apr 2009 09:38:07 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/228 ls enhancements Jason King wrote: > --sort=WORD sort by: > extension, none, size, time, version, status, time, atime, access, use > --time=WORD display WORD > (atime, access, use, ctime, or status) for time, also used as sort key Of those not implement these two seem the most interesting to me and it would be nice to see them implemented, but I won't hold the case up for that. As the case is specified it gets my +1. I'll go a bit further than Darren and will say that it would be good to supply the entire option set -- to completely eliminate any quibbles about deficiencies in the (revised) Solaris version. But as I said before, I'm very happy to see this project and don't propose to hold it up over this minor point. Reaffirming my +1. -- Glenn From jason.brian.king@gmail.com Tue Apr 21 15:05:53 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LM5rCt010817 for ; Tue, 21 Apr 2009 15:05:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3LM5kLM024968; Tue, 21 Apr 2009 16:05:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIH00J0T1DRUH00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 21 Apr 2009 15:05:51 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIH006FU1DQ9960@nwk-avmta-1.sfbay.Sun.COM>; Tue, 21 Apr 2009 15:05:50 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LM0dct005613; Tue, 21 Apr 2009 22:05:50 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay42i.sun.com with ESMTP id BT-MMP-1122788; Tue, 21 Apr 2009 22:05:50 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-434380; Tue, 21 Apr 2009 22:05:49 +0000 (Z) Received: from mail-gx0-f207.google.com ([209.85.217.207] [209.85.217.207]) by relay4i.sun.com with ESMTP id BT-MMP-20030807; Tue, 21 Apr 2009 22:05:49 +0000 (Z) Received: by gxk3 with SMTP id 3so6524269gxk.8 for ; Tue, 21 Apr 2009 15:03:43 -0700 (PDT) Received: by 10.150.49.15 with SMTP id w15mr4139174ybw.180.1240351423328; Tue, 21 Apr 2009 15:03:43 -0700 (PDT) Date: Tue, 21 Apr 2009 17:03:43 -0500 From: Jason King Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <200904212145.n3LLjNCb017322@ivrel.sfbay.sun.com> Sender: jason.brian.king@gmail.com To: Glenn Skinner Cc: psarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=7pH8vgrcVcoiu9PshK7TDjt0gv6wfeInMpixcwZxVoQ=; b=Ehj9rEuXkZ5Qtg6ulTl8CHhcBMBdUwyEakQLaTzyPMPltrSYSihhg3fSvZ3daOefVx MLxKUVR0TSmTGBcY0AimDaXAPiUE6K9OCukRmBp9w7Cy9+lHk1xz1F6ZPHSYTprU4cl9 OjUnkkWED310jIsBfpUsKloZd/Ad4g6AZucuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qHreE4nJLwQ3GK1y3DXUKvMmtJXtLstOHIT3oIiRGA5kCCnBdv9Z6Zezj4pqFnvKil 0XHLLNpftdM1cdgPqu28C1l8G0AH8vivRPMldjCuet3wNE4JP/ufCWH9WOEX3qAnXRHp dOwuxTU4Ggu+gBp0xhIcovnPEnxVVwcTRIVCc= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 3007b80fa09e6c68 X-Antispam: No, score=-0.7/5.0, scanned in 0.064sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904212145.n3LLjNCb017322@ivrel.sfbay.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n3LM5rCt010817 Status: RO Content-Length: 1449 On Tue, Apr 21, 2009 at 4:45 PM, Glenn Skinner wrote: >    Date: Tue, 21 Apr 2009 09:38:07 +0100 >    From: Darren J Moffat >    Subject: Re: PSARC 2009/228 ls enhancements > >    Jason King wrote: >    > --sort=WORD                                           sort by: >    > extension, none, size, time, version, status, time, atime, access, use >    > --time=WORD                                           display WORD >    > (atime, access, use, ctime, or status) for time, also used as sort key > >    Of those not implement these two seem the most interesting to me >    and it would be nice to see them implemented, but I won't hold the >    case up for that. > >    As the case is specified it gets my +1. > > I'll go a bit further than Darren and will say that it would be good > to supply the entire option set -- to completely eliminate any > quibbles about deficiencies in the (revised) Solaris version. > > But as I said before, I'm very happy to see this project and don't > propose to hold it up over this minor point.  Reaffirming my +1. If the case were modified to support all the options, would they all need to be delivered at once (I'm new to the whole ARC process, so be aware I might be asking some obvious questions)? Color is probably the most requested of the features, and I'd like to not see that held up for implementing all the others which I suspect are far less used. From gdamore@sun.com Tue Apr 21 20:59:21 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3M3xKnu013643 for ; Tue, 21 Apr 2009 20:59:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3M3x9lV008495 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 22 Apr 2009 11:59:19 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIH00301HQS8N00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 21:59:16 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIH00L9UHQSAK20@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Apr 2009 21:59:16 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3M3x8uC005638; Tue, 21 Apr 2009 20:59:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIH00I00HJXXF00@fe-sfbay-09.sun.com>; Tue, 21 Apr 2009 20:59:08 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIH00BRSHQJTM90@fe-sfbay-09.sun.com>; Tue, 21 Apr 2009 20:59:08 -0700 (PDT) Date: Tue, 21 Apr 2009 20:59:07 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: Sender: Garrett.Damore@sun.com To: Jason King Cc: Glenn Skinner , psarc-ext@sun.com Message-id: <49EE960B.1050608@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904212145.n3LLjNCb017322@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1727 Jason King wrote: > On Tue, Apr 21, 2009 at 4:45 PM, Glenn Skinner wrote: > >> Date: Tue, 21 Apr 2009 09:38:07 +0100 >> From: Darren J Moffat >> Subject: Re: PSARC 2009/228 ls enhancements >> >> Jason King wrote: >> > --sort=WORD sort by: >> > extension, none, size, time, version, status, time, atime, access, use >> > --time=WORD display WORD >> > (atime, access, use, ctime, or status) for time, also used as sort key >> >> Of those not implement these two seem the most interesting to me >> and it would be nice to see them implemented, but I won't hold the >> case up for that. >> >> As the case is specified it gets my +1. >> >> I'll go a bit further than Darren and will say that it would be good >> to supply the entire option set -- to completely eliminate any >> quibbles about deficiencies in the (revised) Solaris version. >> >> But as I said before, I'm very happy to see this project and don't >> propose to hold it up over this minor point. Reaffirming my +1. >> > > If the case were modified to support all the options, would they all > need to be delivered at once (I'm new to the whole ARC process, so be > aware I might be asking some obvious questions)? Color is probably > the most requested of the features, and I'd like to not see that held > up for implementing all the others which I suspect are far less used. > Technically phased delivery is OK. However... For now, I recommend just proceeding forward with this set. Its easy enough to run another case to just add the few remaining ones later.... -- Garrett From roland.mainz@nrubsig.org Wed Apr 29 15:46:50 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3TMkoC6010676 for ; Wed, 29 Apr 2009 15:46:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3TMki4o022367; Wed, 29 Apr 2009 15:46:49 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIV00903WLZHW00@brm-avmta-1.central.sun.com>; Wed, 29 Apr 2009 16:46:47 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIV00928WLZDH00@brm-avmta-1.central.sun.com>; Wed, 29 Apr 2009 16:46:47 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3TMhW9g023414; Wed, 29 Apr 2009 22:46:46 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay44i.sun.com with ESMTP id BT-MMP-330108; Wed, 29 Apr 2009 22:46:43 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-2089755; Wed, 29 Apr 2009 22:46:42 +0000 (Z) Received: from mail-in-06.arcor-online.net ([151.189.21.46] [151.189.21.46]) by relay4i.sun.com with ESMTP id BT-MMP-2325860; Wed, 29 Apr 2009 22:34:52 +0000 (Z) Received: from mail-in-16-z2.arcor-online.net (mail-in-16-z2.arcor-online.net [151.189.8.33]) by mx.arcor.de (Postfix) with ESMTP id 37E1439A3DD; Thu, 30 Apr 2009 00:32:46 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-16-z2.arcor-online.net (Postfix) with ESMTP id 2CA75254046; Thu, 30 Apr 2009 00:32:46 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-210-247.pools.arcor-ip.net [94.219.210.247]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id 697F41B37C4; Thu, 30 Apr 2009 00:32:45 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n3TMWhP7005577; Thu, 30 Apr 2009 00:32:44 +0200 (CEST) Date: Thu, 30 Apr 2009 00:32:43 +0200 From: Roland Mainz Subject: Re: PSARC 2009/228 ls enhancements (draft opinion) Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <49F8D58B.56CABCD0@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net 697F41B37C4 X-Antispam: No, score=-0.2/5.0, scanned in 0.336sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <49F8A1B4.3050901@sun.com> <49F8A962.CFE52392@nrubsig.org> <49F8AB42.4000909@sun.com> Status: RO Content-Length: 2762 Garrett D'Amore wrote: > Roland Mainz wrote: > > Garrett D'Amore wrote: > >> I've posted a draft opinion "filename opinion-draft.txt" (and also .ms) > >> in the case directory for review. Its attached to this message as > >> well. Thanks. > >> > > [snip] > > > >> 3. Interfaces > >> > >> The project exports the following interfaces. > >> > >> _______________________________________________ > >> | Interfaces Exported | > >> |_________________|________________|__________| > >> |Interface | Classification| Comments| > >> |_________________|________________|__________| > >> |/usr/bin/ls | Committed | | > >> |/usr/xpg4/bin/ls | Committed | | > >> |/usr/xpg6/bin/ls | Committed | | > >> |_________________|________________|__________| > > > > > > I have a small request: > > For the commands replaced by the AT&T AST commands (currently done via > > the ksh93-integration project) we _carefully_ investigated which > > options+features (including long options) are available by which > > implementation (e.g. we investigated Solaris/SystemV, GNU, BSD and AST > > implementations). > > Technically we only made options "Commited" (or added them to the AST > > codebase) which are implemented identically by two or more > > implementations and must exist for >= two years and set-up the rule that > > options+features which are only available in one implementation or exist > > since less than two years must be "Uncommited" (to avoid that the > > implementation somehow changes and therefore breaks a "Commited" > > interface). > > > > IMO it may be nice to 1) apply the same set of rules to /usr/bin/ls, > > /usr/xpg4/bin/ls and /usr/bin/xpg6/bin/ls and 2) make options which are > > somehow "disputed" in this case either "Uncommited" or "Volatile" (I can > > help with that on demand since we already know the drill from > > ksh93-integration update1+update2+ammendents+etc.). > > IMO, there is little value in a familiarity case where the options are > not themselves relatively stable. Erm... my concern is that "Commited" means "_very_ stable" and should be used very carefully. Changing "Commited" interfaces is AFAIK non-trivial and that's why I was suggesting to use "Uncommitted" for now until we have at least the "proof" that more than one implementation provides the same options with the same behaviour for at least two years. > Anyway, the case was approved with Committed. Unless the project team > wants to ask ARC to demote them, they stand as is at Committed. Ok... ;-/ ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From carlsonj@phorcys.east.sun.com Thu Apr 30 04:25:29 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3UBPSmF011243 for ; Thu, 30 Apr 2009 04:25:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3UBPOEf011908; Thu, 30 Apr 2009 19:25:25 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIW00D01VQBA800@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Apr 2009 04:25:23 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIW00L6IVQBCM70@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Apr 2009 04:25:23 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3UBPLB2033986; Thu, 30 Apr 2009 07:25:21 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n3UBOerh007249; Thu, 30 Apr 2009 07:24:40 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n3UBOe7B007246; Thu, 30 Apr 2009 07:24:40 -0400 (EDT) Date: Thu, 30 Apr 2009 07:24:40 -0400 From: James Carlson Subject: Re: PSARC 2009/228 ls enhancements (draft opinion) In-reply-to: <49F8D58B.56CABCD0@nrubsig.org> To: Roland Mainz Cc: "Garrett D'Amore" , PSARC-ext Message-id: <18937.35448.623722.877553@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49F8A1B4.3050901@sun.com> <49F8A962.CFE52392@nrubsig.org> <49F8AB42.4000909@sun.com> <49F8D58B.56CABCD0@nrubsig.org> Status: RO Content-Length: 2217 Roland Mainz writes: > Erm... my concern is that "Commited" means "_very_ stable" and should be > used very carefully. Changing "Commited" interfaces is AFAIK non-trivial > and that's why I was suggesting to use "Uncommitted" for now until we > have at least the "proof" that more than one implementation provides the > same options with the same behaviour for at least two years. Why should we care whether anyone else ever implements those options? What if they remain GNU-only extensions until the end of time? I think the point should be (a) telling users whether we intend to make any incompatible changes and (b) if so, on what sort of release boundary we would allow that sort of change to occur. In this case, it seems unlikely that there'd be some new development that would cause us to make an incompatible change to (say) the --color option. Even in the unlikely case that the GNU guys decided to break their own 'ls' implementation, we wouldn't reflexively follow suit. At most, I could imagine it being removed in the far future when nobody cares anymore about VT320-style ttys, but even that'd be a normal EOF, which we can do if the time comes. You're certainly free to pursue whatever strategy you want within your own project, so if you need to see multiple independent implementations in order for ksh93 to commit to some new feature, then do that. However, as an architectural review matter for OpenSolaris, I don't want to see new options forced to low stability levels merely because they come from what some may see as "lesser" or "foreign" sources. The author doesn't matter. What does matter is accurately representing future change, and making it possible for others to rely on features that the system has. Using artificially low stability levels breaks that, and we've had a long and sorry history of introducing actually stable things as "External" or "Volatile" merely because the author or original inventor didn't carry the right employment credentials. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Apr 30 14:03:48 2009 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3UL3klU021342 for ; Thu, 30 Apr 2009 14:03:46 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3UL3kJ6019695 for ; Thu, 30 Apr 2009 17:03:46 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n3UL34r0009578 for ; Thu, 30 Apr 2009 17:03:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n3UL34i6009575; Thu, 30 Apr 2009 17:03:04 -0400 (EDT) Resent-Message-ID: <18938.4616.629503.44195@gargle.gargle.HOWL> Resent-Date: Thu, 30 Apr 2009 17:03:04 -0400 Resent-From: James Carlson Resent-To: psarc-record@sac.sfbay.sun.com X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on phorcys.east.sun.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Original-recipient: rfc822;james.d.carlson@sun.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=MewW3hwBacLAeg6j12dDUEQ9k2EC9YmWaDkfOWz71Vc=; b=j7mxxd9QDy2k+GQzvrYkLiJff4zMjQWkBQyoxEgZYALFPleRam2F3Yz6B4U+PtkTXx fiIym6cok38uEqfOloL2e3nzZN8alps23eD8cHPGkDA5Sd8OqS+GJJ+VrJGhcWwufQUX x5KTzZsWAzq7PFuUyfRp0iLovSVmg6BRBkzhI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HovTmLVdF4K8agKLsmWcbfShBM39zoIw3Lpk+FUZeiRujeZ+KnyCUnIAdW8RFeE1gX KyCQFGZk89xxR569mUJb0w5B3HnMDy3xb+uwj2acO1aSxuG6VQ/8x7Y0waNKsY9pNCFh IMDdSuN3fCiJolt/2kJJQS9wkinjzlls2IDKM= Errors-to: opensolaris-arc-bounces@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Precedence: list X-BeenThere: opensolaris-arc@opensolaris.org Delivered-to: opensolaris-arc@opensolaris.org X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Original-To: opensolaris-arc@opensolaris.org X-Google-Sender-Auth: 4d739922739b103b X-Antispam: No, score=-1.1/5.0, scanned in 0.121sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <49F9FA15.7070707@sonic.net> X-Mailman-Version: 2.1.12 List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: List-Id: Discussion of ARC issues affecting OpenSolaris In-reply-to: <49F9FA15.7070707@sonic.net> From: Jason King To: Don Cragun Cc: opensolaris-arc@opensolaris.org Subject: 2009/228 ls enhancements Date: Thu, 30 Apr 2009 15:27:33 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id n3UL3mlV021343 Status: RO Content-Length: 5375 On Thu, Apr 30, 2009 at 2:20 PM, Don Cragun wrote: >> Date: Wed, 29 Apr 2009 16:32:38 -0400 >> From: James Carlson >> Subject: Re: PSARC 2009/228 ls enhancements (draft opinion) >> Message-ID: <18936.47462.564131.634760@gargle.gargle.HOWL> >> >> Danek Duvall writes: >>> >>> On Wed, Apr 29, 2009 at 11:51:32AM -0700, Garrett D'Amore wrote: >>> >>>> The second concern pertained to the fact that  for  some  of >>>> those same options, the presence of an argument is optional. >>>> The members present felt that while such an "optional  argu- >>>> ment"  might be ambiguous for a short flag, for long options >>>> there is no ambiguity (because of the separating  "="),  and >>>> hence the behavior is acceptable. >>> >>> Long options aren't required to be separated from their option arguments >>> with an equals sign, though they can be -- they can also be separated by >>> a >>> space: >>> >>>    /usr/gnu/bin/ls --sort none >>> >>> and >>> >>>    /usr/gnu/bin/ls --sort=none >> >> Ouch.  That's not what the original project actually defined. >> >> If that's really what's being parsed with an optional argument, then I >> would withdraw my comments.  Such a construction would need an >> explicit "the ARC knows this is wrong, but we're approving it anyway >> because of compatibility" note. > > Jim, > The reason I asked to discuss ls during yesterday's meeting is that the > materials provided in the initial mail (before the man page was added to > the case directory) contained the following: >     --color[=WHEN], --colour[=WHEN] > which shows WHEN as an optional option-argument to the --color and > --colour long options and indicates that the '=' is not required. > Since the description of the function that the case says is being used > to parse options says that the '=' can be replaced by a and the > next argument then becomes the option-argument the command line: >        ls -l --color auto > is ambiguous.  It can mean display all files in the current working > directory in color when the command is run from a tty, or it can mean > list the file 'auto' never using color.  The commands: >        ls -l --color=auto > and >        ls -l --color= auto > are not ambiguous, but these are not the only allowed forms. > > It also listed: >     --time-style=[STYLE] > which shows that the '=' is required for this long option, and > presumably means that if STYLE is the empty string it is equivalent to > --time-style=locale. > > The man page doesn't show any '=' in the descriptions of >        --block-size size >        --color when >        --colour when > and >        --time-style style > In this context, I'm not sure what any of these four long options > are supposed to do if an '=' is given on the command line, but it at > least seems to require that the option arguments are mandatory. > > The man page also does not list any of the new long options in the > SYNOPSIS section and didn't make any adjustments to the ATTRIBUTES > section in the places where it indicates that -A, -b, -e, -E, -h, -S, > -v, -V, -@, -/, and -% are not covered by the standards (thereby > indicating that these new long option are required by the POSIX and > SUS specs.  I assume all of these issues will be fixed before the > man page is published, but I would like the project team to acknowledge > that this needs to be fixed. This is probably just due to me not being a standards lawyer, and having 0 experience writing man pages. The option behavior WILL match that of getopt_long(3c) with '+' being the first character of the option string -- I think that keeps things kosher wrt POSIX and SUS, though trying to figure that out from the getopt_long(3c) manpage made my head hurt, so I may be wrong. If the wording for the long options in the manpages does not match the getopt_long(3c) behavior wrt to optional & mandatory arguments, then I'll try to submit a revision that corrects it to make the manpage reflect this. It looks like for optional arguments, with GNU ls (or more likely glibc getopt_long) --option=VALUE is required, while for mandatory arguments, --option=VALUE or --option VALUE is acceptable, thus ls --color=auto or ls --color, but not ls --color auto (in the latter case 'auto' is interpreted as a pathname to process. Since this was done without looking at the GNU ls source (only manpages, ls --help, and experimentation were used), the lack of concise documentation on GNU ls was a bit if a hinderance (for example, there probably needs to be some clarification on the --block-size=SIZE parameter, as the GNU ls manpage doesn't mention scaling constants -- implying only numbers, while GNU ls --help does indicate scaling constants are supported). I tried to run enough tests to glean behavior where it looked ambiguous, though I would be shocked it if was actually exhaustive just due to the permutations involved. I will say the current rev of the code for does pass the SUS test suites with 0 failures (and even fixes a SUS test failure that's existed in Solaris ls since at least the Opensolaris launch, if not longer), though there are a few things unrelated to this that need to be cleaned up (based on some review comments I'll address when I'm home tonight). _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org From carlsonj@phorcys.east.sun.com Thu Apr 30 14:07:09 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3UL78ZV021407 for ; Thu, 30 Apr 2009 14:07:09 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3UL77Yd012951; Thu, 30 Apr 2009 17:07:07 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n3UL6QOM009588; Thu, 30 Apr 2009 17:06:26 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n3UL6Q2q009585; Thu, 30 Apr 2009 17:06:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18938.4818.426873.665643@gargle.gargle.HOWL> Date: Thu, 30 Apr 2009 17:06:26 -0400 From: James Carlson To: Jason King Cc: Don Cragun , psarc-ext@sac.sfbay.sun.com Subject: 2009/228 ls enhancements In-Reply-To: References: <49F9FA15.7070707@sonic.net> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 996 [Repaired subject line and cc-list. Without the case number in the subject line and psarc-ext in the cc-list, your comments will not be recorded with your case.] Jason King writes: > mandatory arguments, --option=VALUE or --option VALUE is acceptable, > thus ls --color=auto or ls --color, but not ls --color auto (in the > latter case 'auto' is interpreted as a pathname to process. Thanks; that's what I expected. Don: this is now an approved case, so if you feel it needs to be reopened for discussion, I recommend talking first directly with the submitter to ask for that, and (if that fails) following the appeals process. [Yeah, I'm aware that the appeals process is completely broken for OpenSolaris. If we get there, we'll have to make up something useful.] -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Thu Apr 30 14:16:56 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3ULGtfS021566 for ; Thu, 30 Apr 2009 14:16:55 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3ULGscd017708; Thu, 30 Apr 2009 17:16:54 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n3ULGDTv009684; Thu, 30 Apr 2009 17:16:13 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n3ULGDDH009681; Thu, 30 Apr 2009 17:16:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18938.5405.138490.22477@gargle.gargle.HOWL> Date: Thu, 30 Apr 2009 17:16:13 -0400 From: James Carlson To: Jason King Cc: Don Cragun , psarc-ext@sac.sfbay.sun.com Subject: 2009/228 ls enhancements In-Reply-To: References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 525 Jason King writes: > After lots of reading, rereading, parsing, and reparsing, I believe > using getopt_long(3c) to process the arguments, with '+' being the > first character of the option string, gives the desired behavior > (without breaking any standards). Yep; I think you're on the right path. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From jason.brian.king@gmail.com Thu Apr 30 20:17:43 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n413Hhbw024372 for ; Thu, 30 Apr 2009 20:17:43 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n413HgDZ035205 for ; Thu, 30 Apr 2009 20:17:42 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n413Eht0020219 for ; Fri, 1 May 2009 03:17:42 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay11i.sun.com with ESMTP id BT-MMP-1373960 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 03:17:42 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-41422835 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 03:17:41 Z Received: from mail-gx0-f158.google.com ([209.85.217.158] [209.85.217.158]) by relay1i.sun.com with ESMTP id BT-MMP-36052044 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 03:17:41 Z Received: by gxk2 with SMTP id 2so4454639gxk.3 for ; Thu, 30 Apr 2009 20:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=T4JRbB7hyD0DP5t7NbCeihI3IPvNc0pQOwvCzmW6keo=; b=NMBRhV7P5iovWflYL1+ynUmMFTfpPqHhrAEP4qVllTi47A+Sn6qgHSu5V+ShphclsI ro3AwSECoAjNAd85x6dvIXdtfdvcrFyLDfgG+Wok1IFza2diJqfjtoLznz3myhM7Ybpb ZnVgGjCS9Mp+EVMXNZA0CbfJzY2QLZfaVgYXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EecjqroBcfmyxN1ir3/Sw7rr0EmRrmAgEbQHExL4/GXsS+SRDFhqNVe2f+fstnti7q EqxRGLRLWvN6V1x4dbYtGzHBCu1V8/sXRXK78Du5uwCNqicbTYgSkVqRdB5Y5niFqr4Z lnRSyV9ytDPKYMOg9Bo7zwv273HFzQPhsaWMk= Sender: jason.brian.king@gmail.com Received: by 10.151.43.19 with SMTP id v19mr4797701ybj.28.1241147809327; Thu, 30 Apr 2009 20:16:49 -0700 (PDT) In-Reply-To: <18938.5405.138490.22477@gargle.gargle.HOWL> References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> Date: Thu, 30 Apr 2009 22:16:49 -0500 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: a491827152148163 Message-ID: Subject: Re: 2009/228 ls enhancements From: Jason King To: James Carlson Cc: Don Cragun , psarc-ext@sac.sfbay.sun.com X-Antispam: No, score=0.0/5.0, scanned in 0.074sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1764 On Thu, Apr 30, 2009 at 4:16 PM, James Carlson wrote: > Jason King writes: >> After lots of reading, rereading, parsing, and reparsing, I believe >> using getopt_long(3c) to process the arguments, with '+' being the >> first character of the option string, gives the desired behavior >> (without breaking any standards). > > Yep; I think you're on the right path. Upon further investigation, this will not allow optional long arguments (I thought it did), so now I'm at a loss, and my head hurts from trying to decipher what is, what isn't standard conforming. So, I will simply ask, is there any facility in Opensolaris that supports: 1. Long and short options, where there might be long options that don't have corresponding short versions 2. Long arguments that can have optional parameters of the form --option=FOO, or --option but not '--option foo') 3. Long arguments that can have mandatory parameters of the form --option=FOO or --option foo 4. Doesn't break POSIX or SUS standards. If so, what is the correct invocation to achieve this, because I seem unable to figure it out. getopt_long(argc, argv, "+......", longopts, &indexptr) apparently requires all parameters to long options as mandatory. I.e. 'ls --color' does not work. My understanding is getopt_long(argc, argv, "....", longopts, &indexptr) where the first character is not '+' allows argument reordering and is therefore not posix compliant (but does allow --option[=FOO]. It looks like "-....." for the short option string might, but at this point I've given up trying to understand the getopt_long manpage as everything I think i've understood it, I find yet another case to prove me wrong, so please anyone who actually understands this, please comment. From dcragun@sonic.net Thu Apr 30 22:31:44 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n415VhKi026200 for ; Thu, 30 Apr 2009 22:31:44 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n415Vhcb003207 for ; Thu, 30 Apr 2009 22:31:43 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n415TPW5021549 for ; Fri, 1 May 2009 05:31:43 GMT Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-2248979 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 05:31:43 Z Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-498449 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 05:31:43 Z Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay4i.sun.com with ESMTP id BT-MMP-792079 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 05:31:42 Z Received: from [10.0.0.10] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n415VfD4018272; Thu, 30 Apr 2009 22:31:41 -0700 Message-ID: <49FA8941.5050604@sonic.net> Date: Thu, 30 Apr 2009 22:31:45 -0700 From: Don Cragun User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: Jason King CC: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> In-Reply-To: X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.089sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3358 Jason King wrote: > On Thu, Apr 30, 2009 at 4:16 PM, James Carlson wrote: >> Jason King writes: >>> After lots of reading, rereading, parsing, and reparsing, I believe >>> using getopt_long(3c) to process the arguments, with '+' being the >>> first character of the option string, gives the desired behavior >>> (without breaking any standards). >> Yep; I think you're on the right path. > > Upon further investigation, this will not allow optional long > arguments (I thought it did), so now I'm at a loss, and my head hurts > from trying to decipher what is, what isn't standard conforming. > > So, I will simply ask, is there any facility in Opensolaris that supports: > > 1. Long and short options, where there might be long options that > don't have corresponding short versions > 2. Long arguments that can have optional parameters of the form > --option=FOO, or --option but not '--option foo') > 3. Long arguments that can have mandatory parameters of the form > --option=FOO or --option foo > 4. Doesn't break POSIX or SUS standards. > > If so, what is the correct invocation to achieve this, because I seem > unable to figure it out. > > getopt_long(argc, argv, "+......", longopts, &indexptr) apparently > requires all parameters to long options as mandatory. I.e. 'ls > --color' does not work. My understanding is getopt_long(argc, argv, > "....", longopts, &indexptr) where the first character is not '+' > allows argument reordering and is therefore not posix compliant (but > does allow --option[=FOO]. It looks like "-....." for the short > option string might, but at this point I've given up trying to > understand the getopt_long manpage as everything I think i've > understood it, I find yet another case to prove me wrong, so please > anyone who actually understands this, please comment. Hi Jason, I helped spec out, write, and debug getopt_clip(); but as you have noted that won't work unless all long options have short option equivalents (and getopt_clip() doesn't like optional option-arguments). The leading "+" in the string pointed to by the shortopts parameter only forces the POSIX/SUS/CLIP requirement that command line parsing is not allowed to reorder arguments on the command line; it doesn't affect optional option-argument processing. My reading of the getopt_long() description is that if the element of the getopt_long() struct option array pointed to by the longopts parameter has name set to "color" and has has_arg set to optional_argument (as defined in ), getopt_long() should recognize either of the following as a valid invocation with --color: ls --color [other options]... [operands]... which is used when the optional option-argument is not present or ls --color=value [other options]... [operands]... when the optional option-argument is present. The getopt_long() function will not recognize "value" in: ls --color value as an optional option-argument because it can't be distinguished from ls --color operand where operand is a command line operand instead of the optional option-argument. I believe the PSARC members who voted to approve this case Wednesday did so with the understanding that optional option-arguments could be parsed unambiguously. Therefore, the form: ls --color optional_option_argument can't be accepted. Hope this helps, Don From jason.brian.king@gmail.com Thu Apr 30 22:47:33 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n415lXrG026356 for ; Thu, 30 Apr 2009 22:47:33 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n415lXuP010336 for ; Thu, 30 Apr 2009 22:47:33 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n415lRfl014296 for ; Fri, 1 May 2009 05:47:27 GMT Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-1379165 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 05:47:27 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-195165 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 05:47:27 Z Received: from yx-out-2324.google.com ([74.125.44.28] [74.125.44.28]) by relay1i.sun.com with ESMTP id BT-MMP-36244432 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 05:47:27 Z Received: by yx-out-2324.google.com with SMTP id 8so1221394yxm.27 for ; Thu, 30 Apr 2009 22:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=kLnmXItBy/M3/7hE7YhQvbD+clvmjE2MvdLb7DtnDHM=; b=I8gSwbsKbfCIihc+MKlJF9nelaj+pVmm4TH1jVwclz74IzebiH9+E7rSRAquw6qxI9 mJM8WReyor2E7E9aHpk25ZgP9cGfcpTLVhWuE9Vwilmb0RMpAJUPddEf0dx+4Q3+9Heh H+/K+LYMR9NluPvsF8eoqTesRTbnrPuuP6ZHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EBzrB4kYMdm4MsVh5UgW2co47K8UsF70b/zHfcWy3jeYCgNfTwHx4RmdjtXIEak7Nb t5YfrVG77pxlC2hVFzKf28Dl3wh8QS28WEoOI7IU6cOQRkfAJVXnu+Zo5Tp5WWdfYOYd SfAvGnYGPK4GsEKaDeKLRMy9+YnJEqxPMos28= Sender: jason.brian.king@gmail.com Received: by 10.151.122.10 with SMTP id z10mr5004093ybm.195.1241156838137; Thu, 30 Apr 2009 22:47:18 -0700 (PDT) In-Reply-To: <49FA8941.5050604@sonic.net> References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> Date: Fri, 1 May 2009 00:47:18 -0500 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 62c9e7db93f50c05 Message-ID: Subject: Re: 2009/228 ls enhancements From: Jason King To: Don Cragun Cc: psarc-ext@sac.sfbay.sun.com X-Antispam: No, score=-2.6/5.0, scanned in 0.113sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n415lXrG026356 Status: RO Content-Length: 4231 On Fri, May 1, 2009 at 12:31 AM, Don Cragun wrote: > Jason King wrote: >> >> On Thu, Apr 30, 2009 at 4:16 PM, James Carlson >> wrote: >>> >>> Jason King writes: >>>> >>>> After lots of reading, rereading, parsing, and reparsing, I believe >>>> using getopt_long(3c) to process the arguments, with '+' being the >>>> first character of the option string, gives the desired behavior >>>> (without breaking any standards). >>> >>> Yep; I think you're on the right path. >> >> Upon further investigation, this will not allow optional long >> arguments (I thought it did), so now I'm at a loss, and my head hurts >> from trying to decipher what is, what isn't standard conforming. >> >> So, I will simply ask, is there any facility in Opensolaris that supports: >> >> 1. Long and short options, where there might be long options that >> don't have corresponding short versions >> 2. Long arguments that can have optional parameters of the form >> --option=FOO, or --option but not '--option foo') >> 3. Long arguments that can have mandatory parameters of the form >> --option=FOO or --option foo >> 4. Doesn't break POSIX or SUS standards. >> >> If so, what is the correct invocation to achieve this, because I seem >> unable to figure it out. >> >> getopt_long(argc, argv, "+......", longopts, &indexptr) apparently >> requires all parameters to long options as mandatory.  I.e. 'ls >> --color' does not work.  My understanding is getopt_long(argc, argv, >> "....", longopts, &indexptr) where the first character is not '+' >> allows argument reordering and is therefore not posix compliant (but >> does allow --option[=FOO].  It looks like "-....." for the short >> option string might, but at this point I've given up trying to >> understand the getopt_long manpage as everything I think i've >> understood it, I find yet another case to prove me wrong, so please >> anyone who actually understands this, please comment. > > Hi Jason, > I helped spec out, write, and debug getopt_clip(); but as you have noted > that won't work unless all long options have short option equivalents > (and getopt_clip() doesn't like optional option-arguments). > > The leading "+" in the string pointed to by the shortopts parameter only > forces the POSIX/SUS/CLIP requirement that command line parsing is not > allowed to reorder arguments on the command line; it doesn't affect > optional option-argument processing. Then this sounds like a bug in getopt_long -- a leading '+' it does in fact make all long option-arguments mandatory. I thought that's what it should do, but since it doesn't it was making me doubt my comprehension abilities :) Actually reading the code it would appear that in this section: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/getopt_long.c#495 the last statement (line 498) shouldn't be there. Would you agree that is a bug (the removal FLAG_OPTIONAL_ARGS when POSIX mode is set) and not in fact an architectural issue? > My reading of the getopt_long() description is that if the element of > the getopt_long() struct option array pointed to by the longopts parameter > has name set to "color" and has has_arg set to > optional_argument (as defined in ), getopt_long() should recognize > either of the following as a valid invocation with --color: >        ls --color [other options]... [operands]... > which is used when the optional option-argument is not present > or      ls --color=value [other options]... [operands]... > when the optional option-argument is present.  The getopt_long() > function will not recognize "value" in: >        ls --color value > as an optional option-argument because it can't be distinguished from >        ls --color operand > where operand is a command line operand instead of the optional > option-argument. That would be what I would expect as well. > I believe the PSARC members who voted to approve this case Wednesday > did so with the understanding that optional option-arguments could be > parsed unambiguously.  Therefore, the form: >        ls --color optional_option_argument > can't be accepted. I agree. > Hope this helps, > Don > I believe so, thank you very much! From dcragun@sonic.net Thu Apr 30 23:10:28 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n416ASiM026893 for ; Thu, 30 Apr 2009 23:10:28 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n416AS6r021518 for ; Thu, 30 Apr 2009 23:10:28 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4164GZP017256 for ; Fri, 1 May 2009 06:10:23 GMT Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay44i.sun.com with ESMTP id BT-MMP-60314 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 06:10:23 Z Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-532981; Fri, 1 May 2009 06:10:22 Z Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay4i.sun.com with ESMTP id BT-MMP-4735019; Fri, 1 May 2009 06:10:22 Z Received: from [10.0.0.10] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n416AFHs023892; Thu, 30 Apr 2009 23:10:15 -0700 Message-ID: <49FA924A.3060404@sonic.net> Date: Thu, 30 Apr 2009 23:10:18 -0700 From: Don Cragun User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: James Carlson CC: Jason King , psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements References: <49F9FA15.7070707@sonic.net> <18938.4818.426873.665643@gargle.gargle.HOWL> In-Reply-To: <18938.4818.426873.665643@gargle.gargle.HOWL> X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.090sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2586 James Carlson wrote: > [Repaired subject line and cc-list. Without the case number in the > subject line and psarc-ext in the cc-list, your comments will not be > recorded with your case.] I apologize. I did not intend to hit send. I was rushing out the door for a doctor's appointment and intended to clean up the subject and recheck my wording before I sent the message. > > Jason King writes: >> mandatory arguments, --option=VALUE or --option VALUE is acceptable, >> thus ls --color=auto or ls --color, but not ls --color auto (in the >> latter case 'auto' is interpreted as a pathname to process. > > Thanks; that's what I expected. I'm happy with this too. It violates the CLIP spec as it is written so I thought we should have this case set the precedent. > > Don: this is now an approved case, so if you feel it needs to be > reopened for discussion, I recommend talking first directly with the > submitter to ask for that, and (if that fails) following the appeals > process. [Yeah, I'm aware that the appeals process is completely > broken for OpenSolaris. If we get there, we'll have to make up > something useful.] I see that now. As you have probably noticed, I'm getting the ARC mail in digest form. The digest that said this case had been approved didn't hit my inbox until after the PSARC meeting Wednesday. When I raised the issue during the meeting, it seemed to me that I had raised the issue of optional option-arguments and didn't see any reaction to the issue before the case disappeared from the agenda. I was just asking for clarification on what had been decided. There is an on-going problem with external attendees having trouble keeping track of what the ARC is doing. The agenda published for Wednesday's meeting said this case was going to be discussed then and didn't list at least five cases that were discussed. I know an agenda needs to be published almost a week in advance, but the list of cases to be discussed needs to be kept up-to-date on the external agenda like it is on the internal agenda. Furthermore, as I remember the internal agenda, there were links directly from the agenda to the case directories for all of the fast tracks. There are no links in the external agenda. I'm getting better at typing in the web addresses on the fly, but it is a lot slower than the direct links. It is also strange that I usually get ten or more daily opensolaris-arc digests every day and that they frequently hit my mailbox in groups of three or more. Sorry for venting; it has been a generally frustrating day... ;-{ - Don From dcragun@sonic.net Thu Apr 30 23:49:08 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n416n8Z4027139 for ; Thu, 30 Apr 2009 23:49:08 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n416n8kH051577 for ; Thu, 30 Apr 2009 23:49:08 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n416lmdU024367 for ; Fri, 1 May 2009 06:49:02 GMT Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-1382563 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 06:49:02 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-8175783 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 06:49:00 Z Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-36555867 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 06:48:59 Z Received: from [10.0.0.10] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n416mlFQ010931; Thu, 30 Apr 2009 23:48:48 -0700 Message-ID: <49FA9B53.8090307@sonic.net> Date: Thu, 30 Apr 2009 23:48:51 -0700 From: Don Cragun User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: Jason King CC: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> In-Reply-To: X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 2.133sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 5636 Jason King wrote: > On Fri, May 1, 2009 at 12:31 AM, Don Cragun wrote: >> Jason King wrote: >>> On Thu, Apr 30, 2009 at 4:16 PM, James Carlson >>> wrote: >>>> Jason King writes: >>>>> After lots of reading, rereading, parsing, and reparsing, I believe >>>>> using getopt_long(3c) to process the arguments, with '+' being the >>>>> first character of the option string, gives the desired behavior >>>>> (without breaking any standards). >>>> Yep; I think you're on the right path. >>> Upon further investigation, this will not allow optional long >>> arguments (I thought it did), so now I'm at a loss, and my head hurts >>> from trying to decipher what is, what isn't standard conforming. >>> >>> So, I will simply ask, is there any facility in Opensolaris that supports: >>> >>> 1. Long and short options, where there might be long options that >>> don't have corresponding short versions >>> 2. Long arguments that can have optional parameters of the form >>> --option=FOO, or --option but not '--option foo') >>> 3. Long arguments that can have mandatory parameters of the form >>> --option=FOO or --option foo >>> 4. Doesn't break POSIX or SUS standards. >>> >>> If so, what is the correct invocation to achieve this, because I seem >>> unable to figure it out. >>> >>> getopt_long(argc, argv, "+......", longopts, &indexptr) apparently >>> requires all parameters to long options as mandatory. I.e. 'ls >>> --color' does not work. My understanding is getopt_long(argc, argv, >>> "....", longopts, &indexptr) where the first character is not '+' >>> allows argument reordering and is therefore not posix compliant (but >>> does allow --option[=FOO]. It looks like "-....." for the short >>> option string might, but at this point I've given up trying to >>> understand the getopt_long manpage as everything I think i've >>> understood it, I find yet another case to prove me wrong, so please >>> anyone who actually understands this, please comment. >> Hi Jason, >> I helped spec out, write, and debug getopt_clip(); but as you have noted >> that won't work unless all long options have short option equivalents >> (and getopt_clip() doesn't like optional option-arguments). >> >> The leading "+" in the string pointed to by the shortopts parameter only >> forces the POSIX/SUS/CLIP requirement that command line parsing is not >> allowed to reorder arguments on the command line; it doesn't affect >> optional option-argument processing. > > Then this sounds like a bug in getopt_long -- a leading '+' it does in > fact make all long option-arguments mandatory. I thought that's what > it should do, but since it doesn't it was making me doubt my > comprehension abilities :) I know that some of the GNU developers believed (and some may still believe) that POSIXLY_CORRECT meant that no options could be accepted if they weren't in the standard, that the "Utility Syntax Guidelines" were to be treated as "requirements" instead of as "guidelines", and that POSIXLY_CORRECT was a method allowed by the standard to invoke standard behavior. All of these beliefs were incorrect. (However, the latest version of the standard allows POSIXLY_CORRECT to have this affect if the command output by invoking the command: getconf V7_ENV sets POSIXLY_CORRECT.) The POSIX and SUS standards still have a few standard utilities that take optional option-arguments. The description of those utilities always explicitly lists every case where a standard utility violates the Utility Syntax Guidelines. When writing new applications, it is up to the programmer to follow the guidelines (by not creating optional option-arguments); it was never the intent of the standards committees that getopts() or other command line processing functions should make it exceptionally hard to process optional option-arguments for those utilities that need to support them for backwards compatibility or other reasons. > > Actually reading the code it would appear that in this section: > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/getopt_long.c#495 > the last statement (line 498) shouldn't be there. Would you agree > that is a bug (the removal FLAG_OPTIONAL_ARGS when POSIX mode is set) > and not in fact an architectural issue? Yes, I agree that this is a bug in getopt_long(). > >> My reading of the getopt_long() description is that if the element of >> the getopt_long() struct option array pointed to by the longopts parameter >> has name set to "color" and has has_arg set to >> optional_argument (as defined in ), getopt_long() should recognize >> either of the following as a valid invocation with --color: >> ls --color [other options]... [operands]... >> which is used when the optional option-argument is not present >> or ls --color=value [other options]... [operands]... >> when the optional option-argument is present. The getopt_long() >> function will not recognize "value" in: >> ls --color value >> as an optional option-argument because it can't be distinguished from >> ls --color operand >> where operand is a command line operand instead of the optional >> option-argument. > > That would be what I would expect as well. > >> I believe the PSARC members who voted to approve this case Wednesday >> did so with the understanding that optional option-arguments could be >> parsed unambiguously. Therefore, the form: >> ls --color optional_option_argument >> can't be accepted. > > I agree. > >> Hope this helps, >> Don >> > > I believe so, thank you very much! You're welcome. - Don From carlsonj@phorcys.east.sun.com Fri May 1 06:08:06 2009 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41D85RU027173 for ; Fri, 1 May 2009 06:08:05 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41D84MD027221; Fri, 1 May 2009 09:08:04 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n41D7LJl010464; Fri, 1 May 2009 09:07:21 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n41D7LWm010461; Fri, 1 May 2009 09:07:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18938.62473.190770.398457@gargle.gargle.HOWL> Date: Fri, 1 May 2009 09:07:21 -0400 From: James Carlson To: Don Cragun Cc: Jason King , psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements In-Reply-To: <49FA924A.3060404@sonic.net> References: <49F9FA15.7070707@sonic.net> <18938.4818.426873.665643@gargle.gargle.HOWL> <49FA924A.3060404@sonic.net> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2375 Don Cragun writes: > I see that now. As you have probably noticed, I'm getting the ARC mail > in digest form. The digest that said this case had been approved didn't > hit my inbox until after the PSARC meeting Wednesday. When I raised the I believe you were still on the line when we derailed and voted. That was the actual approval -- derailing converts the fast-track to a full case, and a vote causes it to close. > issue during the meeting, it seemed to me that I had raised the issue of > optional option-arguments and didn't see any reaction to the issue > before the case disappeared from the agenda. I was just asking for > clarification on what had been decided. What was decided was that the CLIP infraction (regarding the requirement for equivalent short options) was insignificant compared to the GNU compatibility issue. The whole point of the project is to allow users to specify "familiar" GNU options to 'ls', and have them just work, rather than forcing people to reach for /usr/gnu/bin/ls, which (sadly) doesn't support Solaris features. Specifically, the vote was on allowing the case to go forward as originally specified and without requiring a man page warning, as the original specification did _not_ contain ambiguous constructs, because the only optional option argument was a strict "--color[=WHEN]" string, with no possibility of "--color WHEN". (In fact, I'd go so far to say that to the extent that CLIP might call the former an ambiguous construct, it's wrong. But that's a separate case.) If this case changes to include ambiguous constructs, then that'd be a material change, and we'd have to revisit. > is on the internal agenda. Furthermore, as I remember the internal > agenda, there were links directly from the agenda to the case > directories for all of the fast tracks. There are no links in the > external agenda. I'm getting better at typing in the web addresses on > the fly, but it is a lot slower than the direct links. I've agreed before that something needs to be done about this. I still do. There's obviously more infrastructure work to be done. I don't know of a schedule for it. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Fri May 1 06:10:16 2009 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41DAFoM027201 for ; Fri, 1 May 2009 06:10:15 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41DAE0H028219; Fri, 1 May 2009 09:10:14 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n41D9VF4010473; Fri, 1 May 2009 09:09:31 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n41D9VHq010470; Fri, 1 May 2009 09:09:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18938.62603.296963.425706@gargle.gargle.HOWL> Date: Fri, 1 May 2009 09:09:31 -0400 From: James Carlson To: Don Cragun Cc: Jason King , psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements In-Reply-To: <49FA8941.5050604@sonic.net> References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1450 Don Cragun writes: > My reading of the getopt_long() description is that if the element of > the getopt_long() struct option array pointed to by the longopts > parameter has name set to "color" and has has_arg set to > optional_argument (as defined in ), getopt_long() should > recognize either of the following as a valid invocation with --color: > ls --color [other options]... [operands]... > which is used when the optional option-argument is not present > or ls --color=value [other options]... [operands]... > when the optional option-argument is present. The getopt_long() > function will not recognize "value" in: > ls --color value > as an optional option-argument because it can't be distinguished from > ls --color operand > where operand is a command line operand instead of the optional > option-argument. Yes; I agree with your description. That'd better work as documented. If it doesn't, then it's a bug, and we'll have to fix it. > I believe the PSARC members who voted to approve this case Wednesday > did so with the understanding that optional option-arguments could be > parsed unambiguously. Therefore, the form: > ls --color optional_option_argument > can't be accepted. Correct. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gsf@research.att.com Fri May 1 07:02:00 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41E20k2028266 for ; Fri, 1 May 2009 07:02:00 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41E20ac033273 for ; Fri, 1 May 2009 07:02:00 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n41Dvi7H017748 for ; Fri, 1 May 2009 14:01:59 GMT Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay43i.sun.com with ESMTP id BT-MMP-2272551 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 14:01:59 Z Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-1017570 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 14:01:59 Z Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay4i.sun.com with ESMTP id BT-MMP-5226195 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 14:01:59 Z Received: from penguin.research.att.com (penguin.research.att.com [135.207.176.48]) by mail-green.research.att.com (Postfix) with ESMTP id E553F9C1A; Fri, 1 May 2009 10:01:58 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.8/8.12.10/Submit) id n41E1wG0020377; Fri, 1 May 2009 10:01:58 -0400 Date: Fri, 1 May 2009 10:01:58 -0400 From: Glenn Fowler Message-Id: <200905011401.n41E1wG0020377@penguin.research.att.com> Organization: AT&T Research X-Brightmail-Tracker: AAAAAA== X-Mailer: mailx (AT&T/BSD) 9.9 2008-11-04 References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> To: dcragun@sonic.net, jason@ansipunx.net Subject: Re: 2009/228 ls enhancements Cc: psarc-ext@sac.sfbay.sun.com X-Antispam: No, score=-2.6/5.0, scanned in 0.171sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 5460 there are no posix standards for long options so it should not be a problem for a long option with no corresponding short flag to have an optional option value, of course assuming that the name=value form would be required to disambuguate when the option value is present side note -- the ast optget() also disambiguates optional option values for long options by requiring the name=value form it also allows long options with no corresponding short flags by using negative indices that will not conflict with short flag character values a bonus is that ksh93 uses optget() to implement getopts so shell scripts are not second class citizens w.r.t. long options and since the options desc ription is one 0-terminated string instead of a C-data-struct the description can be moved freely between script<=>C-source implementations -- Glenn Fowler -- at&t Research, Florham Park NJ -- On Fri, 1 May 2009 00:47:18 -0500 Jason King wrote: > On Fri, May 1, 2009 at 12:31 AM, Don Cragun wrote: > > Jason King wrote: > >> > >> On Thu, Apr 30, 2009 at 4:16 PM, James Carlson > >> wrote: > >>> > >>> Jason King writes: > >>>> > >>>> After lots of reading, rereading, parsing, and reparsing, I believe > >>>> using getopt_long(3c) to process the arguments, with '+' being the > >>>> first character of the option string, gives the desired behavior > >>>> (without breaking any standards). > >>> > >>> Yep; I think you're on the right path. > >> > >> Upon further investigation, this will not allow optional long > >> arguments (I thought it did), so now I'm at a loss, and my head hurts > >> from trying to decipher what is, what isn't standard conforming. > >> > >> So, I will simply ask, is there any facility in Opensolaris that supports: > >> > >> 1. Long and short options, where there might be long options that > >> don't have corresponding short versions > >> 2. Long arguments that can have optional parameters of the form > >> --option=FOO, or --option but not '--option foo') > >> 3. Long arguments that can have mandatory parameters of the form > >> --option=FOO or --option foo > >> 4. Doesn't break POSIX or SUS standards. > >> > >> If so, what is the correct invocation to achieve this, because I seem > >> unable to figure it out. > >> > >> getopt_long(argc, argv, "+......", longopts, &indexptr) apparently > >> requires all parameters to long options as mandatory.  I.e. 'ls > >> --color' does not work.  My understanding is getopt_long(argc, argv, > >> "....", longopts, &indexptr) where the first character is not '+' > >> allows argument reordering and is therefore not posix compliant (but > >> does allow --option[=FOO].  It looks like "-....." for the short > >> option string might, but at this point I've given up trying to > >> understand the getopt_long manpage as everything I think i've > >> understood it, I find yet another case to prove me wrong, so please > >> anyone who actually understands this, please comment. > > > > Hi Jason, > > I helped spec out, write, and debug getopt_clip(); but as you have noted > > that won't work unless all long options have short option equivalents > > (and getopt_clip() doesn't like optional option-arguments). > > > > The leading "+" in the string pointed to by the shortopts parameter only > > forces the POSIX/SUS/CLIP requirement that command line parsing is not > > allowed to reorder arguments on the command line; it doesn't affect > > optional option-argument processing. > Then this sounds like a bug in getopt_long -- a leading '+' it does in > fact make all long option-arguments mandatory. I thought that's what > it should do, but since it doesn't it was making me doubt my > comprehension abilities :) > Actually reading the code it would appear that in this section: > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/getopt_long.c#495 > the last statement (line 498) shouldn't be there. Would you agree > that is a bug (the removal FLAG_OPTIONAL_ARGS when POSIX mode is set) > and not in fact an architectural issue? > > My reading of the getopt_long() description is that if the element of > > the getopt_long() struct option array pointed to by the longopts parameter > > has name set to "color" and has has_arg set to > > optional_argument (as defined in ), getopt_long() should recognize > > either of the following as a valid invocation with --color: > >        ls --color [other options]... [operands]... > > which is used when the optional option-argument is not present > > or      ls --color=value [other options]... [operands]... > > when the optional option-argument is present.  The getopt_long() > > function will not recognize "value" in: > >        ls --color value > > as an optional option-argument because it can't be distinguished from > >        ls --color operand > > where operand is a command line operand instead of the optional > > option-argument. > That would be what I would expect as well. > > I believe the PSARC members who voted to approve this case Wednesday > > did so with the understanding that optional option-arguments could be > > parsed unambiguously.  Therefore, the form: > >        ls --color optional_option_argument > > can't be accepted. > I agree. > > Hope this helps, > > Don > > > I believe so, thank you very much! > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From carlsonj@phorcys.east.sun.com Fri May 1 07:28:47 2009 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41ESlKE028354 for ; Fri, 1 May 2009 07:28:47 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41ESkZs001528; Fri, 1 May 2009 10:28:46 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n41ES3sW010767; Fri, 1 May 2009 10:28:03 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n41ES3EL010764; Fri, 1 May 2009 10:28:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18939.1779.393760.638815@gargle.gargle.HOWL> Date: Fri, 1 May 2009 10:28:03 -0400 From: James Carlson To: Glenn Fowler Cc: dcragun@sonic.net, jason@ansipunx.net, psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements In-Reply-To: <200905011401.n41E1wG0020377@penguin.research.att.com> References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> <200905011401.n41E1wG0020377@penguin.research.att.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1449 Glenn Fowler writes: > there are no posix standards for long options > so it should not be a problem for a long option > with no corresponding short flag to have an optional option value, > of course assuming that the name=value form would be required to > disambuguate when the option value is present POSIX isn't really the issue here for long options. As you rightly note, POSIX defines only short options (and even at that, leaves some things to the imagination). The standards we're discussing here are actually set by ARC case history. PSARC 1999/645 (CLIP), 1991/031 (getopts), and 2003/035 (getopt_long and getopt_clip) are the relevant cases. > a bonus is that ksh93 uses optget() to implement getopts > so shell scripts are not second class citizens w.r.t. long options > and since the options desc ription is one 0-terminated string > instead of a C-data-struct the description can be moved > freely between script<=>C-source implementations Since this is going in ON, I think the implementor is free to choose among the getopt_* family and the ksh93 optget() functions as he sees fit. There's no real architectural issue there, as far as I can tell, as long as the functionality described is implemented. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From dcragun@sonic.net Fri May 1 11:29:36 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n41ITarx009367 for ; Fri, 1 May 2009 11:29:36 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n41ITXcI031740 for ; Fri, 1 May 2009 11:29:33 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n41IQE74019954 for ; Fri, 1 May 2009 18:29:28 GMT Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-2295835 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 18:29:28 Z Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-1317649 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 18:29:24 Z Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay4i.sun.com with ESMTP id BT-MMP-5569803 for psarc-ext@sac.sfbay.sun.com; Fri, 1 May 2009 18:28:56 Z Received: from webmail.sonic.net (a.webmail.sonic.net [64.142.100.132]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n41ISmEY021228; Fri, 1 May 2009 11:28:48 -0700 Received: from 76.191.129.144 (SquirrelMail authenticated user dcragun) by webmail.sonic.net with HTTP; Fri, 1 May 2009 11:28:48 -0700 (PDT) Message-ID: <18832.76.191.129.144.1241202528.squirrel@webmail.sonic.net> In-Reply-To: <18938.62473.190770.398457@gargle.gargle.HOWL> References: <49F9FA15.7070707@sonic.net> <18938.4818.426873.665643@gargle.gargle.HOWL> <49FA924A.3060404@sonic.net> <18938.62473.190770.398457@gargle.gargle.HOWL> Date: Fri, 1 May 2009 11:28:48 -0700 (PDT) Subject: Re: 2009/228 ls enhancements From: "Don Cragun" To: "James Carlson" Cc: "Don Cragun" , "Jason King" , psarc-ext@sac.sfbay.sun.com User-Agent: SquirrelMail/1.4.9a X-Brightmail-Tracker: AAAAAA== X-Priority: 3 (Normal) Importance: Normal X-Antispam: No, score=-2.6/5.0, scanned in 0.100sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Status: RO Content-Length: 4278 On Fri, May 1, 2009 06:07, James Carlson wrote: > Don Cragun writes: >> I see that now. As you have probably noticed, I'm getting the ARC mail >> in digest form. The digest that said this case had been approved didn't >> hit my inbox until after the PSARC meeting Wednesday. When I raised the > > I believe you were still on the line when we derailed and voted. That > was the actual approval -- derailing converts the fast-track to a full > case, and a vote causes it to close. Hi Jim, Yes. I was saying that when the meeting started Wednesday, the case had already been marked closed approved in the case log, but the closure message had not yet made it to my inbox. You allowed a discussion on this case when I brought it up. During that discussion the case was reopened, derailed, and approved. > >> issue during the meeting, it seemed to me that I had raised the issue of >> optional option-arguments and didn't see any reaction to the issue >> before the case disappeared from the agenda. I was just asking for >> clarification on what had been decided. > > What was decided was that the CLIP infraction (regarding the > requirement for equivalent short options) was insignificant compared > to the GNU compatibility issue. The whole point of the project is to > allow users to specify "familiar" GNU options to 'ls', and have them > just work, rather than forcing people to reach for /usr/gnu/bin/ls, > which (sadly) doesn't support Solaris features. Yes, but I believe the CLIP case requires an explicit waiver from the ARC when CLIP guidelines are violated. The opinion for this case now modifies that CLIP requirement when long option optional option-arguments are the issue. > > Specifically, the vote was on allowing the case to go forward as > originally specified and without requiring a man page warning, as the > original specification did _not_ contain ambiguous constructs, because > the only optional option argument was a strict "--color[=WHEN]" > string, with no possibility of "--color WHEN". (In fact, I'd go so > far to say that to the extent that CLIP might call the former an > ambiguous construct, it's wrong. But that's a separate case.) > > If this case changes to include ambiguous constructs, then that'd be a > material change, and we'd have to revisit. I was just pointing out that the case included an ambiguous specification for how the optional option-arguments were to be presented. The case as presented in the email used '=' (not ambiguous), but the man page presented doesn't use '=' in the description of those options (ambiguous if the option-arguments are optional; unambiguous if the option-arguments are mandatory). That left me with the impression that the interface being ARCed was not clearly specified. From the e-mail discussion since then, it is now clear to me that the man page is wrong and the original case e-mail was mostly correct. From my experience with Sun's utilities tech writers, I have 95+% confidence that if the man page in the case directory is given to them as input the resulting man page will not correctly describe the intended interface. (Doug might get it right since he frequently reads ARC cases when he is updating man pages, but he doesn't usually work on utility man pages except as part of a project providing conformance to a new revision of the standards.) > >> is on the internal agenda. Furthermore, as I remember the internal >> agenda, there were links directly from the agenda to the case >> directories for all of the fast tracks. There are no links in the >> external agenda. I'm getting better at typing in the web addresses on >> the fly, but it is a lot slower than the direct links. > > I've agreed before that something needs to be done about this. I > still do. There's obviously more infrastructure work to be done. I > don't know of a schedule for it. Understood. Feel free to forward any part of this conversation if you think it might help get funding for this infrastructure work. Thanks, Don 408-978-8127 > > -- > James Carlson, Solaris Networking > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 > > From olga.kryzhanovska@gmail.com Sat May 2 16:53:26 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n42NrQ4q018156 for ; Sat, 2 May 2009 16:53:26 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n42NrP9I047627 for ; Sat, 2 May 2009 16:53:26 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n42NqG39014145 for ; Sat, 2 May 2009 23:53:20 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-1493494 for psarc-ext@sac.sfbay.sun.com; Sat, 2 May 2009 23:53:20 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-46326238 for psarc-ext@sac.sfbay.sun.com; Sat, 2 May 2009 23:53:20 Z Received: from mail-fx0-f169.google.com ([209.85.220.169] [209.85.220.169]) by relay1i.sun.com with ESMTP id BT-MMP-40287705 for psarc-ext@sac.sfbay.sun.com; Sat, 2 May 2009 23:53:20 Z Received: by fxm17 with SMTP id 17so4003605fxm.27 for ; Sat, 02 May 2009 16:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=neB+YBOEW7R9Tu8Zo1jJMDuvVRFZB0WYftAwoLBw3Wo=; b=xNu7iPZu4VTYG8dPk0tu3xFQ9PMSjZGHRKYU3VMHbQh3jr/b0Mn0TlMQsWVRNRxQKG KnHTUBbFvXCBIVY/JTO7jMAvK9/dEUOymkrkbCVB4qKwSol61hrB1F5TG2JaHG6LYtBp B6AzE+LfiAA3PpGLLgzvEB+gzOBeDEVYCYsT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l8/vSPtdlkTLUoMaKqPxUOFawa51GX+Q1S9PP+iiUVnXMF5o9lTZwkrssZ/5t5stGu q4nTaH8r/P9ul5CIs9B9952xBLmP9oI5TvGeZkQYDHi3rK1pwU2ei8lIbxhp+nqwCPRe jk8UqTNs52n0Q1GieHZtNXDZ+QGLry+81PB78= Received: by 10.223.126.1 with SMTP id a1mr1497526fas.52.1241308399332; Sat, 02 May 2009 16:53:19 -0700 (PDT) In-Reply-To: <18939.1779.393760.638815@gargle.gargle.HOWL> References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> <200905011401.n41E1wG0020377@penguin.research.att.com> <18939.1779.393760.638815@gargle.gargle.HOWL> Date: Sun, 3 May 2009 01:53:19 +0200 Message-ID: Subject: Re: 2009/228 ls enhancements From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= To: James Carlson Cc: Glenn Fowler , dcragun@sonic.net, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.062sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1125 On 5/1/09, James Carlson wrote: > Glenn Fowler writes: > > there are no posix standards for long options > > so it should not be a problem for a long option > > with no corresponding short flag to have an optional option value, > > of course assuming that the name=value form would be required to > > disambuguate when the option value is present > > > POSIX isn't really the issue here for long options. As you rightly > note, POSIX defines only short options (and even at that, leaves some > things to the imagination). > > The standards we're discussing here are actually set by ARC case > history. PSARC 1999/645 (CLIP), 1991/031 (getopts), and 2003/035 > (getopt_long and getopt_clip) are the relevant cases. Could you publish this material, please? -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From hugh@mcintyreweb.com Sat May 2 19:07:15 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4327FF1019789 for ; Sat, 2 May 2009 19:07:15 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4327EJ0051067 for ; Sat, 2 May 2009 19:07:14 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4324Ksp014580 for ; Sun, 3 May 2009 02:07:14 GMT Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay43i.sun.com with ESMTP id BT-MMP-2371536 for psarc-ext@sac.sfbay.sun.com; Sun, 3 May 2009 02:07:14 Z Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-3039705 for psarc-ext@sac.sfbay.sun.com; Sun, 3 May 2009 02:07:13 Z Received: from remote.mcintyreweb.com ([67.23.1.228] [67.23.1.228]) by relay4i.sun.com with ESMTP id BT-MMP-3679576 for psarc-ext@sac.sfbay.sun.com; Sun, 3 May 2009 02:07:13 Z Received: from twins.i.mcintyreweb.com (unknown [64.166.3.74]) by remote.mcintyreweb.com (Postfix) with ESMTPS id 135E810C2D3; Sat, 2 May 2009 19:07:12 -0700 (PDT) Message-ID: <49FCFBFC.8070801@mcintyreweb.com> Date: Sat, 02 May 2009 19:05:48 -0700 From: Hugh McIntyre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) To: =?UTF-8?B?0L7Qu9GM0LPQsCDQutGA0YvQttCw0L3QvtCy0YHQutCw0Y8=?= CC: James Carlson , dcragun@sonic.net, psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> <200905011401.n41E1wG0020377@penguin.research.att.com> <18939.1779.393760.638815@gargle.gargle.HOWL> In-Reply-To: X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.062sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Status: RO Content-Length: 558 ольга крыжановÑÐºÐ°Ñ wrote: > On 5/1/09, James Carlson wrote: >> The standards we're discussing here are actually set by ARC case >> history. PSARC 1999/645 (CLIP), 1991/031 (getopts), and 2003/035 >> (getopt_long and getopt_clip) are the relevant cases. > > Could you publish this material, please? You mean something other than the links below? http://arc.opensolaris.org/caselog/PSARC/1991/031/ http://arc.opensolaris.org/caselog/PSARC/1999/645/ http://arc.opensolaris.org/caselog/PSARC/2003/035/ Hugh. From lists@mcintyreweb.com Sat May 2 19:16:52 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n432Gquo019839 for ; Sat, 2 May 2009 19:16:52 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n432Gqmj053642 for ; Sat, 2 May 2009 19:16:52 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n432FJo1001800 for ; Sun, 3 May 2009 02:16:46 GMT Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-2372139 for psarc-ext@sac.sfbay.sun.com; Sun, 3 May 2009 02:16:46 Z Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-3046540 for psarc-ext@sac.sfbay.sun.com; Sun, 3 May 2009 02:16:46 Z Received: from remote.mcintyreweb.com ([67.23.1.228] [67.23.1.228]) by relay4i.sun.com with ESMTP id BT-MMP-3687288 for psarc-ext@sac.sfbay.sun.com; Sun, 3 May 2009 02:16:46 Z Received: from twins.i.mcintyreweb.com (unknown [64.166.3.74]) by remote.mcintyreweb.com (Postfix) with ESMTPS id 8AAD210C2D3; Sat, 2 May 2009 19:16:45 -0700 (PDT) Message-ID: <49FCFE3A.3030601@mcintyreweb.com> Date: Sat, 02 May 2009 19:15:22 -0700 From: Hugh McIntyre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) To: =?UTF-8?B?0L7Qu9GM0LPQsCDQutGA0YvQttCw0L3QvtCy0YHQutCw0Y8=?= CC: James Carlson , dcragun@sonic.net, psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/228 ls enhancements References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> <200905011401.n41E1wG0020377@penguin.research.att.com> <18939.1779.393760.638815@gargle.gargle.HOWL> In-Reply-To: X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.107sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Status: RO Content-Length: 579 [Resending due to opensolaris.org mail list bounce. Sorry for any duplicates]. ольга крыжановÑÐºÐ°Ñ wrote: >> The standards we're discussing here are actually set by ARC case >> history. PSARC 1999/645 (CLIP), 1991/031 (getopts), and 2003/035 >> (getopt_long and getopt_clip) are the relevant cases. > > Could you publish this material, please? You mean something other than the links below? http://arc.opensolaris.org/caselog/PSARC/1991/031/ http://arc.opensolaris.org/caselog/PSARC/1999/645/ http://arc.opensolaris.org/caselog/PSARC/2003/035/ Hugh. From olga.kryzhanovska@gmail.com Tue May 5 04:19:05 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n45BJ57Z000370 for ; Tue, 5 May 2009 04:19:05 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n45BJ454064566 for ; Tue, 5 May 2009 04:19:05 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n45BH3p0017657 for ; Tue, 5 May 2009 11:19:04 GMT Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-2580650 for psarc-ext@sac.sfbay.sun.com; Tue, 5 May 2009 11:19:04 Z Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-6545602 for psarc-ext@sac.sfbay.sun.com; Tue, 5 May 2009 11:18:59 Z Received: from mail-fx0-f169.google.com ([209.85.220.169] [209.85.220.169]) by relay4i.sun.com with ESMTP id BT-MMP-11937767 for psarc-ext@sac.sfbay.sun.com; Tue, 5 May 2009 11:18:59 Z Received: by fxm17 with SMTP id 17so6198759fxm.27 for ; Tue, 05 May 2009 04:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X4IVs3MYiCXmEzO2LVTraIXLa5IYtaWY6nLogPTJUgk=; b=rvNDWFpmGavMrurR8fu47G1g5qfdvNcWCOHSTgoLe+KPg+BbMo/8h/uEJ7l/L5AWed /I39XQ0sQBtMfseMQR1fmfNiczJZ5oGgpgDXgMqLFsQTTY1LuC4hgudTwRkEIfatHQG7 7iZlFTzfTFpozVZk6oWjlDsWp7DAJrkXodBhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nu6G0EP8PfjA8zf922YcuPcTAQiSavNSC4XcT+jxQ6GgqTZ4Qg8e/lFxK7eGm8XQuy QLH/T1zCjs6ETWGhOy2HGfF02DuLBXvxEVyeCL6rc3LPdLJyWkUcVfHrpO2nYzM/vCAo 0yJ8V9ER14K1USrNzS9EUxg+cDFljcYO6axkI= Received: by 10.223.113.9 with SMTP id y9mr3064963fap.61.1241522288457; Tue, 05 May 2009 04:18:08 -0700 (PDT) In-Reply-To: <49FCFE3A.3030601@mcintyreweb.com> References: <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> <200905011401.n41E1wG0020377@penguin.research.att.com> <18939.1779.393760.638815@gargle.gargle.HOWL> <49FCFE3A.3030601@mcintyreweb.com> Date: Tue, 5 May 2009 13:18:08 +0200 Message-ID: Subject: Re: 2009/228 ls enhancements From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= To: Hugh McIntyre Cc: James Carlson , dcragun@sonic.net, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 3.253sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n45BJ57Z000370 Status: RO Content-Length: 1006 On 5/3/09, Hugh McIntyre wrote: > [Resending due to opensolaris.org mail list bounce. Sorry for any > duplicates]. > > ÏÌØÇÁ ËÒÙÖÁÎÏ×ÓËÁÑ wrote: > > > > > > The standards we're discussing here are actually set by ARC case > > > history. PSARC 1999/645 (CLIP), 1991/031 (getopts), and 2003/035 > > > (getopt_long and getopt_clip) are the relevant cases. > > > > > > > Could you publish this material, please? > > > > You mean something other than the links below? > > http://arc.opensolaris.org/caselog/PSARC/1991/031/ > > http://arc.opensolaris.org/caselog/PSARC/1999/645/ > > http://arc.opensolaris.org/caselog/PSARC/2003/035/ Thank you. -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From sac-owner Wed May 6 14:21:51 2009 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02.SFBay.Sun.COM [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46LLpLX001574 for ; Wed, 6 May 2009 14:21:51 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n46LLp6X058705 for ; Wed, 6 May 2009 14:21:51 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n46LLkZ3009360 for ; Wed, 6 May 2009 14:21:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800100R2GFR00@fe-sfbay-10.sun.com> for sac-review@sac.eng.sun.com; Wed, 06 May 2009 14:21:46 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ800IBLRC97EH0@fe-sfbay-10.sun.com> for sac-review@sac.eng.sun.com; Wed, 06 May 2009 14:21:46 -0700 (PDT) Date: Wed, 06 May 2009 14:21:45 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/228 ls enhancements (opinion for review) Sender: Garrett.Damore@sun.com To: sac-review@sac.sfbay.sun.com Message-id: <4A01FF69.1040204@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2732 A copy of this opinion is also located in the case directory as opinion-draft.txt. sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: ls enhancements Submitted by: Jason King File: PSARC/2009/228/opinion.ms Date: April 29th, 2009 Committee: Garrett D'Amore, James D. Carlson, Mark Carl- son, Sebastien Roy Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project proposes to add enhancements to the ls(1) util- ity to make it more familiar to users coming from other operating systems such as Linux. Perhaps most notable among those enhancements is addition of support for colorized listings using the --color argument. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of the ON consolidation. 3. Interfaces The project exports the following interfaces. _______________________________________________ | Interfaces Exported | |_________________|________________|__________| |Interface | Classification| Comments| |_________________|________________|__________| |/usr/bin/ls | Committed | | |/usr/xpg4/bin/ls | Committed | | |/usr/xpg6/bin/ls | Committed | | |_________________|________________|__________| PSARC/2009/228 Copyright 2009 Sun Microsystems - 2 - 4. Opinion During review, two issues concerning the use of long options (--option) were raised. The first concern pertains to the fact that not all long options have a corresponding short flag. The members of the committee felt that since this is also true of Linux interface being emulated, that this was acceptable. The second concern pertained to the fact that for some of those same options, the presence of an argument is optional. The members present felt that while such an "optional argu- ment" might be ambiguous for a short flag, for long options there is no ambiguity (because of the separating "="), and hence the behavior is acceptable. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/228. 3. ls man page File: ls.txt 3. Project proposal File: 20090408_jason.king PSARC/2009/228 Copyright 2009 Sun Microsystems From roland.mainz@nrubsig.org Wed May 6 19:07:45 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4727jU8007670 for ; Wed, 6 May 2009 19:07:45 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4727iAD048918 for ; Wed, 6 May 2009 19:07:44 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4720LG8010099 for ; Thu, 7 May 2009 02:07:44 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-1720308 for psarc-ext@sac.sfbay.sun.com; Thu, 7 May 2009 02:07:44 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-54069627 for psarc-ext@sac.sfbay.sun.com; Thu, 7 May 2009 02:07:43 Z Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-810598 for psarc-ext@sac.sfbay.sun.com; Thu, 7 May 2009 02:07:43 Z Received: from mail-in-11-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mx.arcor.de (Postfix) with ESMTP id 8D0111AF284; Thu, 7 May 2009 04:07:42 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-11-z2.arcor-online.net (Postfix) with ESMTP id 73C3FD470F; Thu, 7 May 2009 04:07:42 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-212-156.pools.arcor-ip.net [94.219.212.156]) by mail-in-11.arcor-online.net (Postfix) with ESMTPS id 88661E390D; Thu, 7 May 2009 04:07:41 +0200 (CEST) X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-11.arcor-online.net 88661E390D Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n4727cK4002186; Thu, 7 May 2009 04:07:39 +0200 (CEST) Sender: gisburn@jupiterb48.nrubsig.org Message-ID: <4A024269.AF57A6BA@nrubsig.org> Date: Thu, 07 May 2009 04:07:37 +0200 From: Roland Mainz X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) X-Accept-Language: en To: James Carlson CC: Glenn Fowler , dcragun@sonic.net, psarc-ext@sac.sfbay.sun.com Subject: Long options and |libast::optget()| ... / was: Re: 2009/228 ls enhancements References: <49F9FA15.7070707@sonic.net> <18938.4195.626177.904610@gargle.gargle.HOWL> <18938.5405.138490.22477@gargle.gargle.HOWL> <49FA8941.5050604@sonic.net> <200905011401.n41E1wG0020377@penguin.research.att.com> <18939.1779.393760.638815@gargle.gargle.HOWL> X-Antispam: No, score=0.0/5.0, scanned in 0.170sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 831 James Carlson wrote: > Glenn Fowler writes: [snip] > > a bonus is that ksh93 uses optget() to implement getopts > > so shell scripts are not second class citizens w.r.t. long options > > and since the options desc ription is one 0-terminated string > > instead of a C-data-struct the description can be moved > > freely between script<=>C-source implementations > > Since this is going in ON, I think the implementor is free to choose > among the getopt_* family and the ksh93 optget() functions as he sees > fit. Erm... note that this is not ksh93 Glenn was thinking about - it's |libast::optget()| which has this additional functionality... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From jason.brian.king@gmail.com Sun May 17 12:17:30 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4HJHTJe022419 for ; Sun, 17 May 2009 12:17:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4HJHReV012111 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 18 May 2009 03:17:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJS00H03YX3AS00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 17 May 2009 12:17:27 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJS00402YX2J650@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 17 May 2009 12:17:26 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4HJAcqx002371 for ; Sun, 17 May 2009 19:17:26 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-2537999 for psarc-ext@sun.com; Sun, 17 May 2009 19:17:23 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-381887 for psarc-ext@sun.com; Sun, 17 May 2009 19:17:23 +0000 (Z) Received: from mail-bw0-f176.google.com ([209.85.218.176] [209.85.218.176]) by relay1i.sun.com with ESMTP id BT-MMP-23375867 for psarc-ext@sun.com; Sun, 17 May 2009 19:17:23 +0000 (Z) Received: by mail-bw0-f176.google.com with SMTP id 24so2972318bwz.8 for ; Sun, 17 May 2009 12:17:18 -0700 (PDT) Received: by 10.239.148.12 with SMTP id d12mr396422hbb.152.1242587837841; Sun, 17 May 2009 12:17:17 -0700 (PDT) Date: Sun, 17 May 2009 14:17:17 -0500 From: Jason King Subject: 2009/228 ls enhancements Sender: jason.brian.king@gmail.com To: PSARC-ext Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=l5edmpclfwyI4XASwGhqq29g3KS87AwSTwOcOqupgaU=; b=ToyosGAu48mg5w5yLLSsIBiBzu8zPAcYPBVt1YYY0EyLmsxSka4oz4nEVJ4ELP7Duv ix0YDMYWPaSs4oPSu8sO+nJmCGQ2nGhD4QJ4mzuGzZGq99dsoEAzqVMQqRTsCvZLM8ev 39lA1KfM6VVaxH5jeRB2qHfhUFhSeXh8jKAuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=krirESU4jBFLg4g3vUV/EuOgnQkAe4mmNKrVShZqZrIXMc2sGoEKBHEWpyBuA2tdiZ pDvFC6frXQHcwV9b7e1I1hno9lvozwMer3Q0+H68sq5I01crmq20fBQDuEScHimvn/Pa KO0gS+zaT25JzQiQfs3YG7H92ufLigLP2LYaU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: b16661e330e065fe X-Antispam: No, score=0.0/5.0, scanned in 0.053sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Status: RO Content-Length: 1041 There are two corrections to the case materials I need to note, I don't believe it effects the vote or need a separate case for discussion. If anyone disagrees, please speak up now. 1. -U flag This was accidentally omitted from the case template, but was included in the mail discussions (where I sort the flags by new, aliases, etc.). It is a new flag. The description is: -U Do not sort the output. Output is in directory order. 2. --block-size. A code reviewer noticed that the suffixes supported aren't correctly reflected in the case materials. The corrected information (which matches GNU ls behavior) is: --block-size=NN. Use NN sized blocks. NN can be suffixed with [kKmMgGtTpPeEzZyY]B? (in regex format -- and yes, GNU ls really can use yottabyte sized blocks if you want). The optional 'B' (only uppercase) signifies powers of 10 instead of 2 (e.g. KB is 1000, while K is 1024). This is not the same as the -h option in du(1m) or df(1m), nor is i compatible with standard SI notations, but is compatible with GNU ls. From jason.brian.king@gmail.com Mon May 18 19:23:11 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4J2N7BY017146 for ; Mon, 18 May 2009 19:23:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4J2MuOt003504; Tue, 19 May 2009 03:23:03 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJV00201DAE4W00@nwk-avmta-2.sfbay.sun.com>; Mon, 18 May 2009 19:23:02 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJV001NSDA93I50@nwk-avmta-2.sfbay.sun.com>; Mon, 18 May 2009 19:23:01 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4J2IbLh001077; Tue, 19 May 2009 02:22:57 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay41i.sun.com with ESMTP id BT-MMP-4081635; Tue, 19 May 2009 02:22:57 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-18656702; Tue, 19 May 2009 02:22:54 +0000 (Z) Received: from mail-fx0-f213.google.com ([209.85.220.213] [209.85.220.213]) by relay4i.sun.com with ESMTP id BT-MMP-18030451; Tue, 19 May 2009 02:22:54 +0000 (Z) Received: by fxm9 with SMTP id 9so3870303fxm.8 for ; Mon, 18 May 2009 19:21:53 -0700 (PDT) Received: by 10.239.164.9 with SMTP id r9mr345254hbd.38.1242699713263; Mon, 18 May 2009 19:21:53 -0700 (PDT) Date: Mon, 18 May 2009 21:21:53 -0500 From: Jason King Subject: 2009/228 ls enhancements Sender: jason.brian.king@gmail.com To: PSARC-ext Cc: "Garrett D'Amore" , John Sonnenschein Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_LIrsj8xR+t6iPxyDZmHNNQ)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/N2MEo8Q/TZJGs4ij6yzf/fVb812GH5QDiItE84fvew=; b=DYsRG5wjLtihX3i4rsiQr1rxKRbVqpeGVVOqdctU0MMKsful7MRGtxXL1VRgkroc9K DonwiuOTqYXJXg7ogFUClX0ZHOEuKwhtwShiL6GH4R2tpbcy6xnOkTres9ixwoFMqJ99 BGnQVoc72SioJMDcL7FZzOCNRJBitL3gLsdBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=pLgu6kmV3y6X2Xq6mIoCYQ+i5PgOVblJs3BhbVPRzZJunDfW8NkA7PtOMJV+fK/x2C dUHJmnPebJolDeAdJYfyzT8ZvcBU979Bf3dSpk6JZqh0BgjhR4TSSFPgHmfOIofjyhuX iSKsUNapJ453D3gCyoT22qElNjr09+PCc9dN0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: c7457895976d8f98 X-Antispam: No, score=-0.2/5.0, scanned in 0.443sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Status: RO Content-Length: 55811 --Boundary_(ID_LIrsj8xR+t6iPxyDZmHNNQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT To accompany my earlier message, I've attached the updated man page changes for the case materials. These do not reflect any change in behavior or architecture, merely making the initial manpage changes submitted with the case agree with the results of the case discussion. A brief summary of the changes from the original ls.txt: 1. --color invocation is changed to show correct usage of --color[=WHEN]. 2. Values for --block-size are elaborated (based on pervious message). 3. LS_COLOR is fixed to the correct LS_COLORS. 4. LS_COLORS and TERM added to the environment variable section. LS_COLORS use was already detailed in the color output section, just not listed under environment variables. TERM was an implicit dependency due to the use of terminfo, it was added to make the dependency explicit. --Boundary_(ID_LIrsj8xR+t6iPxyDZmHNNQ) Content-type: text/plain; charset=US-ASCII; name=ls.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ls.txt X-Attachment-Id: f_fuvypxie0 User Commands ls(1) NAME ls - list contents of directory SYNOPSIS | /usr/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... | /usr/xpg4/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... | /usr/xpg6/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... DESCRIPTION For each file that is a directory, ls lists the contents of the directory. For each file that is an ordinary file, ls repeats its name and any other information requested. The output is sorted alphabetically by default. When no argument is given, the current directory (.) is listed. When several arguments are given, the arguments are first sorted appropriately, but file arguments appear before directories and their contents. There are three major listing formats. The default format for output directed to a terminal is multi-column with entries sorted down the columns. The -1 option allows single column output and -m enables stream output format. In order to determine output formats for the -C, -x, and -m options, ls uses an environment variable, COLUMNS, to determine the number of character positions available on one output line. If this variable is not set, the terminfo(4) database is used to determine the number of columns, based on the environment variable, TERM. If this information cannot be | obtained, 80 columns are assumed. If the -w option is used, | the argument will override any other column width. The mode printed when the -e, -E, -g, -l, -n, -o, -v, -V, or -@ option is in effect consists of eleven characters. The first character can be one of the following: d The entry is a directory. D The entry is a door. l The entry is a symbolic link. SunOS 5.11 Last change: 25 Mar 2008 1 User Commands ls(1) b The entry is a block special file. c The entry is a character special file. p The entry is a FIFO (or "named pipe") special file. P The entry is an event port. s The entry is an AF_UNIX address family socket. - The entry is an ordinary file. The next 9 characters are interpreted as three sets of three bits each. The first set refers to the owner's permissions; the next to permissions of others in the user-group of the file; and the last to all others. Within each set, the three characters indicate permission to read, to write, and to execute the file as a program, respectively. For a direc- tory, execute permission is interpreted to mean permission to search the directory for a specified file. The character after permissions is an ACL or extended attributes indica- tor. This character is an @ if extended attributes are asso- ciated with the file and the -@ option is in effect. Other- wise, this character is a plus sign (+) character if a non- trivial ACL is associated with the file or a space character if not. If -/ and/or -% are in effect, then the extended system attributes are printed when filesystem supports extended system attributes. The display looks as follows: $ls -/ c file -rw-r--r-- 1 root root 0 May 10 14:17 file {AHRSadim-u} $ls -/ v file -rw-r--r-- 1 root root 0 May 10 14:17 file {archive,hidden,readonly,system,appendonly\ nodump,immutable, av_modified,\ noav_quarantined,nounlink} $ls -l -% all file -rw-r--r-- 1 root root 0 May 10 14:17 file timestamp: atime Jun 25 12:56:44 2007 SunOS 5.11 Last change: 25 Mar 2008 2 User Commands ls(1) timestamp: ctime May 10 14:20:23 2007 timestamp: mtime May 10 14:17:56 2007 timestamp: crtime May 10 14:17:56 2007 See the option descriptions of the -/ and -% option for details. ls -l (the long list) prints its output as follows for the POSIX locale: -rwxrwxrwx+ 1 smith dev 10876 May 16 9:42 part2 Reading from right to left, you see that the current direc- tory holds one file, named part2. Next, the last time that file's contents were modified was 9:42 A.M. on May 16. The file contains 10,876 characters, or bytes. The owner of the file, or the user, belongs to the group dev (perhaps indi- cating ``development''), and his or her login name is smith. The number, in this case 1, indicates the number of links to file part2 (see cp(1)). The plus sign indicates that there is an ACL associated with the file. If the -@ option has been specified, the presence of extended attributes super- sede the presence of an ACL and the plus sign is replaced with an 'at' sign (@). Finally, the dash and letters tell you that user, group, and others have permissions to read, write, and execute part2. The execute (x) symbol occupies the third position of the three-character sequence. A - in the third position would have indicated a denial of execution permissions. The permissions are indicated as follows: r The file is readable. w The file is writable. x The file is executable. SunOS 5.11 Last change: 25 Mar 2008 3 User Commands ls(1) - The indicated permission is not granted. s The set-user-ID or set-group-ID bit is on, and the corresponding user or group execution bit is also on. S Undefined bit-state (the set-user-ID or set-group-id bit is on and the user or group execution bit is off). For group permissions, this applies only to non-regular files. t The 1000 (octal) bit, or sticky bit, is on (see chmod(1)), and execution is on. T The 1000 bit is turned on, and execution is off (undefined bit-state). /usr/bin/ls l Mandatory locking occurs during access (on a regular file, the set-group-ID bit is on and the group execu- tion bit is off). /usr/xpg4/bin/ls and /usr/xpg6/bin/ls L Mandatory locking occurs during access (on a regular file, the set-group-ID bit is on and the group execu- tion bit is off). For user and group permissions, the third position is some- times occupied by a character other than x or -. s or S also can occupy this position, referring to the state of the set-ID bit, whether it be the user's or the group's. The ability to assume the same ID as the user during execution is, for example, used during login when you begin as root but need to assume the identity of the user you login as. In the case of the sequence of group permissions, l can occupy the third position. l refers to mandatory file and record locking. This permission describes a file's ability to allow other files to lock its reading or writing permis- sions during access. SunOS 5.11 Last change: 25 Mar 2008 4 User Commands ls(1) For others permissions, the third position can be occupied by t or T. These refer to the state of the sticky bit and execution permissions. OPTIONS The following options are supported: /usr/bin/ls, /usr/xpg4/bin/ls, and /usr/xpg6/bin/ls The following options are supported for all three versions: | --all -a Lists all entries, including those that begin with a dot (.), which are normally not listed. | --almost-all -A Lists all entries, including those that begin with a dot (.), with the exception of the working directory (.) and the parent directory (..). | --escape -b Forces printing of non-printable characters to be in the octal \ddd notation. | --ignore-backups | -B Do not display any files ending with a tilde (~). -c Uses time of last modification of the i-node (file created, mode changed, and so forth) for sorting (-t) or printing (-l or -n). -C Multi-column output with entries sorted down the columns. This is the default output format. -d If an argument is a directory, lists only its name (not its contents). Often used with -l to get the status of a directory. -e The same as -l, except displays time to the second, and with one format for all files regard- less of age: mmm dd hh:mm:ss yyyy. -E The same as -l, except displays time to the nanosecond and with one format for all files regardless of age: yyyy-mm-dd hh:mm:ss.nnnnnnnnn (ISO 8601:2000 format). In addition, this option displays the offset from UTC in ISO 8601:2000 standard format (+hhmm or -hhmm) or no characters if the offset is indeter- minable. The offset reflects the appropriate standard or alternate offset in force at the SunOS 5.11 Last change: 25 Mar 2008 5 User Commands ls(1) file's displayed date and time, under the current timezone. -f Forces each argument to be interpreted as a directory and list the name found in each slot. This option turns off -l, -t, -s, -S, and -r, and turns on -a. The order is the order in which entries appear in the directory. | --classify | -F Append a symbol after certain types of files to | indicate the file type. The following symbols | are used: | / Directory | > Door file | | Named pipe (FIFO) | @ Symbolic link | = Socket | * Executable | | -g The same as -l, except that the owner is not printed. | --human-readable -h All sizes are scaled to a human readable format, for example, 14K, 234M, 2.7G, or 3.0T. Scaling is done by repetitively dividing by 1024. | --dereference-command-line -H If an argument is a symbolic link that references a directory, this option evaluates the file information and file type of the directory that the link references, rather than those of the link itself. However, the name of the link is displayed, rather than the referenced directory. | --inode -i For each file, prints the i-node number in the first column of the report. | -k All sizes are printed in kbytes. -l Lists in long format, giving mode, ACL indica- tion, number of links, owner, group, size in bytes, and time of last modification for each file (see above). If the file is a special file, the size field instead contains the major and minor device numbers. If the time of last modifi- cation is greater than six months ago, it is shown in the format `month date year' for the POSIX locale. When the LC_TIME locale category is not set to the POSIX locale, a different format of the time field can be used. Files modified within six months show `month date time'. If the file is a symbolic link, the filename is printed followed by "->" and the path name of the refer- enced file. | --dereference -L If an argument is a symbolic link, this option evaluates the file information and file type of the file or directory that the link references, SunOS 5.11 Last change: 25 Mar 2008 6 User Commands ls(1) rather than those of the link itself. However, the name of the link is displayed, rather than the referenced file or directory. -m Streams output format. Files are listed across the page, separated by commas. | --numeric-uid-gid -n The same as -l, except that the owner's UID and group's GID numbers are printed, rather than the associated character strings. | --no-group -o The same as -l, except that the group is not printed. -p Puts a slash (/) after each filename if the file is a directory. | --hide-control-chars -q Forces printing of non-printable characters in file names as the character question mark (?). | --reverse -r Reverses the order of sort to get reverse alpha- betic, oldest first, or smallest file size first as appropriate. | --recursive -R Recursively lists subdirectories encountered. | --size -s Indicate the total number of file system blocks consumed by each file displayed. -S Sort by file size (in decreasing order) and for files with the same size by file name (in increasing alphabetic order) instead of just by name. -t Sorts by time stamp (latest first) instead of by name. The default is the last modification time. See -c, -u and -%. -u Uses time of last access instead of last modifi- cation for sorting (with the -t option) or print- ing (with the -l option). SunOS 5.11 Last change: 25 Mar 2008 7 User Commands ls(1) | -U Output is unsorted. This overrides the -t and | -s setting. -v The same as -l, except that verbose ACL informa- tion is displayed as well as the -l output. ACL information is displayed even if the file or directory doesn't have an ACL. -V The same as -l, except that compact ACL informa- tion is displayed after the -l output. The -V option is only applicable to file systems that support NFSv4 ACLs, such as the Solaris ZFS file system. The format of the displayed ACL is as follows: entry_type : permissions : inheritance_flags : access_type entry_type is displayed as one of the following: user:username Additional user access for username. group:groupname Additional group access for group groupname. owner@ File owner. group@ File group owner. everyone@ Everyone access, including file owner and file group owner. This is not equivalent to the POSIX other class. The following permissions, supported by the NFSv4 ACL model, are displayed by using the -v or -V options: read_data (r) Permission to read the data of a file. list_directory (r) Permission to list the contents of a directory. SunOS 5.11 Last change: 25 Mar 2008 8 User Commands ls(1) write_data (w) Permission to modify a file's data. anywhere in the file's offset range. add_file (w) Permission to add a new file to a directory. append_data (p) The ability to modify a file's data, but only starting at EOF. add_subdirectory (p) Permission to create a subdirectory to a direc- tory. read_xattr (R) Ability to read the extended attributes of a file. write_xattr (W) Ability to create extended attributes or write to the extended attribute directory. execute (x) Permission to execute a file. read_attributes (a) The ability to read basic attributes (non-ACLs) of a file. write_attributes (A) Permission to change the times associated with a file or directory to an arbitrary value. delete (d) Permission to delete a file. delete_child (D) Permission to delete a file within a directory. SunOS 5.11 Last change: 25 Mar 2008 9 User Commands ls(1) read_acl (r) Permission to read the ACL of a file. write_acl (C) Permission to write the ACL of a file. write_owner (o) Permission to change the owner of a file. synchronize (s) Permission to access file locally at server with synchronize reads and writes. - No permission granted The following inheritance flags, supported by the NFSv4 ACL model, are displayed by using the -v or -V options: file_inherit (f) Inherit to all newly created files. dir_inherit (d) Inherit to all newly created directories. inherit_only (i) When placed on a direc- tory, do not apply to the directory, only to newly created files and directories. This flag requires that either file_inherit and or dir_inherit is also specified. no_propagate (n) Indicates that ACL entries should be inher- ited to objects in a directory, but inheri- tance should stop after descending one level. This flag is dependent upon either file_inherit and or dir_inherit also SunOS 5.11 Last change: 25 Mar 2008 10 User Commands ls(1) being specified. successful_access (S) Indicates if an alarm or audit record should be initiated upon success- ful accesses. Used with audit/alarm ACE types. failed_access (F) Indicates if an alarm or audit record should be initiated when access fails. Used with audit/alarm ACE types. inherited (I) ACE was inherited. - No permission granted. access_type is displayed as one of the following types: alarm Permission field that specifies permis- sions that should trigger an alarm. allow Permission field that specifies allow permissions. audit Permission field that specifies permis- sions that should be audited. deny Permission field that specifies deny permissions. For example: $ ls -dV /sandbox/dir.1 drwxr-xr-x+ 2 root root 2 Jan 17 15:09 dir.1 user:marks:r-------------:fd-----:allow owner@:--------------:-------:deny owner@:rwxp---A-W-Co-:-------:allow group@:-w-p----------:-------:deny group@:r-x-----------:-------:allow everyone@:-w-p---A-W-Co-:-------:deny everyone@:r-x---a-R-c--s:-------:allow $ SunOS 5.11 Last change: 25 Mar 2008 11 User Commands ls(1) ||||||||||||||||:||||||+ inherited access ||||||||||||||:||||||+ failed access ||||||||||||||:|||||+--success access ||||||||||||||:||||+-- no propagate ||||||||||||||:|||+--- inherit only ||||||||||||||:||+---- directory inherit ||||||||||||||:|+----- file inherit |||||||||||||| ||||||||||||||+ sync |||||||||||||+- change owner ||||||||||||+-- write ACL |||||||||||+--- read ACL ||||||||||+---- write extended attributes |||||||||+----- read extended attributes ||||||||+------ write attributes |||||||+------- read attributes ||||||+-------- delete child |||||+--------- delete ||||+---------- append |||+----------- execute ||+------------ write data |+------------- read data | --width cols | -w cols Multi-column output where the column width is | forced to cols. -x Multi-column output with entries sorted across rather than down the page. -1 Prints one entry per line of output. -@ The same as -l, except that extended attribute information overrides ACL information. An @ is displayed after the file permission bits for files that have extended attributes. -c | -v The same as -l, and in addition displays the extended system attributes associated with the file when extended system attributes are fully supported by the underlying file system. The option -/ supports two option arguments c (com- pact mode) and v (verbose mode). appendonly Allows a file to be modified only at offset EOF. Attempts to modify a file at a location other than EOF fails with EPERM. SunOS 5.11 Last change: 25 Mar 2008 12 User Commands ls(1) archive Indicates if a file has been modified since it was last backed up. Whenever the modifi- cation time (mtime) of a file is changed the archive attri- bute is set. av_modified ZFS sets the anti-virus attri- bute which whenever a file's content or size changes or when the file is renamed. av_quarantined Anti-virus software sets to mark a file as quarantined. crtime Timestamp when a file is created. hidden Marks a file as hidden. immutable Prevents the content of a file from being modified. Also prevents all metadata changes, except for access time updates. When placed on a directory, prevents the deletion and crea- tion of files in the direc- tories. Attempts to modify the content of a file or directory marked as immutable fail with EPERM. Attempts to modify any attributes (with the exception of access time and, with the proper privileges, the immut- able) of a file marked as immutable fails with EPERM. nodump Solaris systems have no special semantics for this attribute. nounlink Prevents a file from being deleted. On a directory, the attribute also prevents any changes to the contents of the directory. That is, no files SunOS 5.11 Last change: 25 Mar 2008 13 User Commands ls(1) within the directory can be removed or renamed. The errno EPERM is returned when attempt- ing to unlink or rename files and directories that are marked as nounlink. readonly Marks a file as readonly. Once a file is marked as readonly the content data of the file cannot be modified. Other meta- data for the file can still be modified. system Solaris systems have no special semantics for this attribute. The display characters used in compact mode (-/ c) are as follows: Attribute Name Display archive A hidden H readonly R system S appendonly a nodump d immutable i av_modified m av_quarantined q nounlink u The display in verbose mode (/ v) uses full attribute names when it is set and the name prefixed by 'no' when it is not set. The attribute name crtime and all other timestamps are han- dled by the option -% with the respective timestamp option arguments and also with all option argument. The display positions are as follows: The display in verbose mode (-/ v) uses full attribute names when it is set and the name pre- fixed by no when it is not set. The attribute name crtime and all other timestamps are handled by the option -% with SunOS 5.11 Last change: 25 Mar 2008 14 User Commands ls(1) the respective timestamp option arguments and also with all option argument. The display positions are as follows: {||||||||||} |||||||||+- u (nounlink) ||||||||+-- q (av_quarantined) |||||||+--- m (av_modified) ||||||+---- i (immutable) |||||+----- d (nodump) ||||+------ a (appendonly) |||+------- S (system) ||+-------- R (readonly) |+--------- H (hidden) +---------- A (archive) -% atime | crtime | ctime | mtime | all atime Equivalent to -u. crtime Uses the creation time of the file for sorting or printing. ctime Equivalent to -c. mtime Uses the last modification time of the file con- tents for sorting or printing. If extended system attributes are not supported or if the user does not have read permission on the file or if the crtime extended attribute is not set, crtime is treated as a synonym for mtime. When option argument -all is specified, all available times- tamps are printed which includes -atime, -ctime, -mtime and on the extended system attribute supporting file systems, -crtime (create time). The option -% all does not effect which timestamp is displayed in long format and does not affect sorting. SunOS 5.11 Last change: 25 Mar 2008 15 User Commands ls(1) | --block-size size | Display sizes in multiples of size. Size can be scaled by suffixing | one of 'YyZzEePpTtGgMmKk'. Additionally, a 'B' can be placed at the | end to indicate powers of 10 instead of 2 (e.g. '10mB' means blocks of | 10000000 bytes while '10m' would mean blocks of 10*2^20 -- | 10485760 -- bytes). This is mutually exclusive with the -h option. | | --color[=when] | --colour[=when] | Display filenames using color on color-capable terminals. | When is an optional argument that determines when color | output should be displayed. Possible values are: | always, yes, or force: Always use color | auto, tty, if-tty: Use color if a terminal is present | no, never, none: Never use color. This is the default. | See COLOR OUTPUT for information on how to control the colors | used in output. | | --file-type | Display a suffix after a file depending on it's type, similar | to the -F option, except * is not appended to executable files. | | --si | Display human scaled sizes similar to the -h option, except | powers of 10 instead of powers of 2 are used. | | --time-style style | Display times using the specified style. This does not effect | the times displayed for extended attributes (-%). | Possible values for style are: | full-iso: Equivalent to -E | long-iso: Display in YYYY-MM-DD HH:MM for all files | iso: Display older files using YYYY-MM-DD and newer files | with MM-DD HH:MM | locale: Use the default locale format for old and new files. | This is the default. | +FORMAT: Use a custom format. Values are the same as described | in strftime(3c). If a newline appears in the string, | the first line is used for older files and the | second line is used for newer files, otherwise the | given format is used for all files. /usr/bin/ls -F Marks directories with a trailing slash (/), doors with a trailing greater-than sign (>), executable files with a trailing asterisk (*), FIFOs with a trailing vertical bar (|), symbolic links with a trailing "at" sign (@), and AF_UNIX address family sockets with a trailing equals sign (=). Follows sym- links named as operands. Specifying more than one of the options in the following mutually exclusive pairs is not considered an error: -C and -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell). The -l option overrides the other option specified in each pair. Specifying more than one of the options in the following mutually exclusive pairs is not considered an error: -C and -1 (one), -H and -L, -c and -u, and -e and -E, and -t and -S. The last option specifying a specific timestamp (-c, -u, -% atime , -% crtime, -% ctime, and -% mtime) determines the timestamps used for sorting or in long format listings. /usr/xpg4/bin/ls -F Marks directories with a trailing slash (/), doors with a trailing greater-than sign (>), executable files with a trailing asterisk (*), FIFOs with a trailing vertical bar (|), symbolic links with a trailing "at" sign (@), and AF_UNIX address family sockets with a trailing equals sign (=). Follows sym- links named as operands. Specifying more than one of the options in the following mutually exclusive pairs is not considered an error: -C and -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell), -C and -1 (one), -H and -L, -c and -u, and -e and -E, and -t and -S. The last option specifying a specific timestamp (-c, -u, -% atime , -% crtime, -% ctime, and -% mtime) determines the timestamps used for sorting or in long format listings. /usr/xpg6/bin/ls -F Marks directories with a trailing slash (/), doors with a trailing greater-than sign (>), executable files with a trailing asterisk (*), FIFOs with a trailing vertical bar (|), symbolic links with a trailing "at" sign (@), and AF_UNIX address family sockets with a trailing equals sign (=). Does not fol- low symlinks named as operands unless the -H or -L SunOS 5.11 Last change: 25 Mar 2008 16 User Commands ls(1) option is specified. Specifying more than one of the options in the following mutually exclusive pairs is not considered an error: -C and -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell), -C and -1 (one), -H and -L, -c and -u, and -e and -E, -t and -S. The last option specifying a specific timestamp (-c, -u, -% atime , -% crtime, -% ctime, and -% mtime) determines the timestamps used for sorting or in long format listings. | COLOR OUTPUT | If color output is enabled, the environment variable LS_COLORS | is checked. If it exists, it's contents are used to control | the colors used to display filenames. If it is not set, a | default list of colors is used. | | The format of LS_COLORS is a colon separated list of attribute | specifications. Each attribute specification is of the format: | filespec=attr[;attr..] | filespec is either of the form '*.SUFFIX' (ex. '*.jar'or | '*.Z' or one of the following filetypes (in least to most | specific order): | no Normal file | fi Regular file | di Directory | ln Symbolic link | pi FIFO or named pipe | so Socket | do Door file | bd Block device | cd Character device | ex Execute bit (either user, group, or other) set | po Event port | st Sticky bit set | or Orphaned symlink | sg Setgid binary | su Setuid binary | ow World writable | tw Sticky bit and world writable | | attr is a semicolon delimited list of color and display | attributes which are combined to determine the final | output color. Possible attribute values are: | Any combination of the following can be chosen: | 00 All attributes off (default terminal color) | this cancels any preceeding effects. | 01 Display text in bold | 04 Display text with an underscore | 05 Display text as blinking | 07 Display text with foreground and background | colors reversed | 08 Display using concealed text. | | One of the following can be chosen. If multiple | values are given, the last value is used. | 30 Set foreground to black | 31 Set foreground to red | 32 Set foreground to green | 33 Set foreground to yellow | 34 Set foreground to blue | 35 Set foreground to magenta (purple) | 36 Set foreground to cyan | 37 Set foreground to white | 39 Set foreground to default terminal color | | One of the following can be chosen. If multiple | values are given, the last value is used. | 40 Set background to black | 41 Set background to red | 42 Set background to green | 43 Set background to yellow | 44 Set background to blue | 45 Set background to magenta (purple) | 46 Set background to cyan | 47 Set background to white | 49 Set background to default terminal color | | NOTE: On some terminals, setting the bold attribute | causes the foreground colors to instead be | 'high-intensity' (i.e. brighter). In such cases | the low-intensity yellow is often displayed as | a brown or orange color. | | At least one attribute must be listed for a file | specification. | | The appropriate color codes are chosen by selecting the most | specific match, starting with the file suffixes and | proceeding with the filetypes until a match is found. The | no (normal file) type will match any file. | OPERANDS The following operand is supported: file A path name of a file to be written. If the file specified is not found, a diagnostic message is out- put on standard error. USAGE See largefile(5) for the description of the behavior of ls when encountering files greater than or equal to 2 Gbyte ( 2^31 bytes). EXAMPLES Example 1 Viewing File Permissions The following example shows how to display detailed informa- tion about a file. % ls -l file.1 -rw-r--r-- 1 gozer staff 206663 Mar 14 10:15 file.1 The permissions string above (-rw-r--r--) describes that the file owner has read and write permissions, the owning group has read permissions, and others have read permissions. The following example shows how to display detailed informa- tion about a directory. % ls -ld test.dir drwxr-xr-x 2 gozer staff 2 Mar 14 10:17 test.dir SunOS 5.11 Last change: 25 Mar 2008 17 User Commands ls(1) The permissions string above (drwxr-xr-x) describes that the directory owner has read, write, and search permissions, the owning group has read and search permissions, and others have read and search permissions. Another example of listing file permissions is as follows: % ls -l file.2 -rw-rwl--- 1 gozer staff 206663 Mar 14 10:47 file.2 The permissions string above (-rw-rwl---) describes that the file owner has read and write permissions, the owning group has read and write permissions, and the file can be locked during access. Example 2 Displaying ACL Information on Files and Direc- tories The following example shows how to display verbose ACL information on a ZFS file. % ls -v file.1 -rw-r--r-- 1 marks staff 206663 Mar 14 10:15 file.1 0:owner@:execute:deny 1:owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2:group@:write_data/append_data/execute:deny 3:group@:read_data:allow 4:everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow The following example shows how to display compact ACL information on a ZFS directory. % ls -dV test.dir drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir owner@:--------------:------:deny SunOS 5.11 Last change: 25 Mar 2008 18 User Commands ls(1) owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow The following example illustrates the ls -v behavior when listing ACL information on a UFS file. $ ls -v file.3 -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 0:user::rw- 1:group::r-- #effective:r-- 2:mask:r-- 3:other:r-- Example 3 Printing the Names of All Files The following example prints the names of all files in the current directory, including those that begin with a dot (.), which normally do not print: example% ls -a Example 4 Providing File Information The following example provides file information: example% ls -aisn This command provides information on all files, including those that begin with a dot (a), the i-number, the memory address of the i-node associated with the file-printed in the left-hand column (i); the size (in blocks) of the files, printed in the column to the right of the i-numbers (s); finally, the report is displayed in the numeric version of the long list, printing the UID (instead of user name) and SunOS 5.11 Last change: 25 Mar 2008 19 User Commands ls(1) GID (instead of group name) numbers associated with the files. When the sizes of the files in a directory are listed, a total count of blocks, including indirect blocks, is printed. Example 5 Providing Extended System Attributes Information example% ls -/ c file (extended system attribute in compact mode) -rw-r--r-- 1 root root 0 May 10 14:17 file {AHRSadim-u} In this example, av_quarantined is not set. example% ls -/ v file (extended system attribute in verbose mode) -rw-r--r-- 1 root root 0 May 10 14:17 file {archive,hidden,readonly,system,appendonly\ nodump,immutable,av_modified,\ noav_quarantined,nounlink} example% ls -/ v file (no extended system attribute) -rw-r--r-- 1 root staff 0 May 16 14:48 file {} example% ls -/ c file (extended system attribute supported file system) -rw-r--r-- 1 root staff 3 Jun 4 22:04 file {A------m--} archive and av_modified attributes are set by default on an extended system attribute supported file. example% ls -/ c -%crtime file -rw-r--r-- root root 0 May 10 14:17 file {AHRSadim-u} SunOS 5.11 Last change: 25 Mar 2008 20 User Commands ls(1) This example displays the timestamp as the creation time: example% ls -l -%all file -rw-r--r-- 1 root root 0 May 10 14:17 file timestamp: atime Jun 14 08:47:37 2007 timestamp: ctime May 10 14:20:23 2007 timestamp: mtime May 10 14:17:56 2007 timestamp: crtime May 10 14:17:56 2007 example% ls -%crtime -tl file* -rw-r--r-- 1 foo staff 3 Jun 4 22:04 file1 -rw-r--r-- 1 root root 0 May 10 14:17 file -rw-r--r-- 1 foo staff 0 May 9 13:49 file.1 In this example the files are sorted by creation time. ENVIRONMENT VARIABLES See environ(5) for descriptions of the following environment variables that affect the execution of ls: LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_TIME, LC_MESSAGES, NLSPATH, and TZ. COLUMNS Determines the user's preferred column position width for writing multiple text-column output. If this variable contains a string representing a decimal integer, the ls utility calculates how many path name text columns to write (see -C) based on the width provided. If COLUMNS is not set or is invalid, 80 is used. The column width chosen to write the names of files in any given directory is constant. File names are not be truncated to fit into the multiple text-column output. | LS_COLORS Determines the coloring scheme used when | displaying color output. If not set and color | output is specified, a default scheme is used. If | TERM is not set, no color output will be used. | | TERM Determine the terminal type. If this variable is | unset or NULL, no color output will be generated | regardless of the value of the --color option. EXIT STATUS 0 All information was written successfully. >0 An error occurred. FILES /etc/group group IDs for ls -l and ls -g SunOS 5.11 Last change: 25 Mar 2008 21 User Commands ls(1) /etc/passwd user IDs for ls -l and ls -o /usr/share/lib/terminfo/?/* terminal information database ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: /usr/bin/ls ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | CSI | Enabled | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | Standard | See below. | |_____________________________|_____________________________| For all options except -A, -b, -e, -E, -h, -S, -v, -V, -@, -/ and -%, see standards(5). /usr/xpg4/bin/ls SunOS 5.11 Last change: 25 Mar 2008 22 User Commands ls(1) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWxcu4 | |_____________________________|_____________________________| | CSI | Enabled | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | Standard | See below. | |_____________________________|_____________________________| For all options except -A, -b, -e, -E, -h, -S, -v, -V, -@, -/ and -%, see standards(5). /usr/xpg6/bin/ls ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWxcu6 | |_____________________________|_____________________________| | CSI | Enabled | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | Standard | See below. | |_____________________________|_____________________________| For all options except -A, -b, -e, -E, -h, -S, -v, -V, -@, -/ and -%, see standards(5). SEE ALSO chmod(1), cp(1), setfacl(1), fgetattr(3C), terminfo(4), acl(5), attributes(5), environ(5), fsattr(5), largefile(5), standards(5) NOTES Unprintable characters in file names can confuse the colum- nar output options. The total block count is incorrect if there are hard links among the files. The sort order of ls output is affected by the locale and can be overridden by the LC_COLLATE environment variable. For example, if LC_COLLATE equals C, dot files appear first, SunOS 5.11 Last change: 25 Mar 2008 23 User Commands ls(1) followed by names beginning with upper-case letters, then followed by names beginning with lower-case letters. But if LC_COLLATE equals en_US.ISO8859-1, then leading dots as well as case are ignored in determining the sort order. SunOS 5.11 Last change: 25 Mar 2008 24 --Boundary_(ID_LIrsj8xR+t6iPxyDZmHNNQ)-- From dcragun@sonic.net Tue May 19 11:28:29 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4JISSUP021981 for ; Tue, 19 May 2009 11:28:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4JISRnH062045 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 19 May 2009 12:28:28 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJW00E01LZEE200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 19 May 2009 11:28:26 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJW00DYHLZDGK10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 19 May 2009 11:28:25 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4JIJwoa024309 for ; Tue, 19 May 2009 18:28:25 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-2730544 for PSARC-ext@sun.com; Tue, 19 May 2009 18:28:25 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-47671799 for PSARC-ext@sun.com; Tue, 19 May 2009 18:28:24 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-2419676 for PSARC-ext@sun.com; Tue, 19 May 2009 18:28:24 +0000 (Z) Received: from webmail.sonic.net (b.webmail.sonic.net [64.142.100.148]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n4JISNn7000978; Tue, 19 May 2009 11:28:23 -0700 Received: from 76.191.129.144 (SquirrelMail authenticated user dcragun) by webmail.sonic.net with HTTP; Tue, 19 May 2009 11:28:23 -0700 (PDT) Date: Tue, 19 May 2009 11:28:23 -0700 (PDT) From: Don Cragun Subject: Re: 2009/228 ls enhancements To: jason@ansipunx.net Cc: PSARC-ext@sun.com Message-id: <21538.76.191.129.144.1242757703.squirrel@webmail.sonic.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.144sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ User-Agent: SquirrelMail/1.4.9a Status: RO Content-Length: 11412 Hi Jason, Please find comments in-line below... Cheers, Don On Mon, 18 May 2009 21:21:53 -0500 Jason King wrote: > To accompany my earlier message, I've attached the updated man page > changes for the case materials. These do not reflect any change in > behavior or architecture, merely making the initial manpage changes > submitted with the case agree with the results of the case discussion. Thanks for sending the update. There are still a few more changes that need to be made. > > A brief summary of the changes from the original ls.txt: > > 1. --color invocation is changed to show correct usage of --color[=WHEN]. > 2. Values for --block-size are elaborated (based on pervious message). > 3. LS_COLOR is fixed to the correct LS_COLORS. > 4. LS_COLORS and TERM added to the environment variable section. > LS_COLORS use was already detailed in the color output section, just > not listed under environment variables. TERM was an implicit > dependency due to the use of terminfo, it was added to make the > dependency explicit. > -------------- next part -------------- > > > User Commands ls(1) > > > > NAME > ls - list contents of directory > > SYNOPSIS > | /usr/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] > [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... You have added the new short options, but these SYNOPSIS lines give no indication that new long options have been added that don't have short option equivalents. I think the last line above needs to be changed to: | [-/ c | v] [-% atime | crtime | ctime | mtime | all] | [--block-size size] [--color[=when]] [--file-type] [--si] | [--time-style style] [file]... > > > | /usr/xpg4/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] > [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... The same change needs to be applied to the line above. > > > | /usr/xpg6/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] > [-/ c | v] [-% atime | crtime | ctime | mtime | all] [file]... The same change needs to be applied to the line above. > > > DESCRIPTION ... ... ... > > OPTIONS ... ... ... > | -U Output is unsorted. This overrides the -t and > | -s setting. > I assume you mean -S rather than -s (-s doesn't affect sorting). Do you really mean that -U overrides the other options, or does the last -S, -t, or -U option on the command line determine the behavior. (Either way is OK, I just want to be sure that the man page correctly documents the behavior.) For some options, the behavior of mutually exclusive options depends on which version of ls you invoke.) This last sentence probably also needs to be moved to the discussion on mutually exclusive options below... ... ... ... > | --file-type > | Display a suffix after a file depending on it's type, similar > | to the -F option, except * is not appended to executable files. See notes below about mutually exclusive options. > | > | --si > | Display human scaled sizes similar to the -h option, except > | powers of 10 instead of powers of 2 are used. See notes below about mutually exclusive options. > | > | --time-style style > | Display times using the specified style. This does not effect > | the times displayed for extended attributes (-%). > | Possible values for style are: > | full-iso: Equivalent to -E > | long-iso: Display in YYYY-MM-DD HH:MM for all files > | iso: Display older files using YYYY-MM-DD and newer files > | with MM-DD HH:MM > | locale: Use the default locale format for old and new files. > | This is the default. > | +FORMAT: Use a custom format. Values are the same as described > | in strftime(3c). If a newline appears in the string, > | the first line is used for older files and the > | second line is used for newer files, otherwise the > | given format is used for all files. > > > /usr/bin/ls > -F Marks directories with a trailing slash (/), doors > with a trailing greater-than sign (>), executable > files with a trailing asterisk (*), FIFOs with a > trailing vertical bar (|), symbolic links with a > trailing "at" sign (@), and AF_UNIX address family > sockets with a trailing equals sign (=). Follows sym- > links named as operands. > Note that -F always follows symlinks for /usr/bin/ls and /usr/xpg4/bin/ls, but /usr/xpg6/bin/ls does not follow symlinks unless -H or -L is also present. What does --file-type do? A new paragraph should be added here to talk about the interactions between -S, -t, and -U. What happens if both --file-type and -F are given on the command line? Does the last one specified win, or does one override the other? What happens if both --si and -h are given on the command line? Does the last one specified win, or does one override the other? The above four issues need to be addressed here and in the following sections describing how mutually exclusive options are handled by /usr/xpg4/bin/ls and by /usr/xpg6/bin/ls. > > > Specifying more than one of the options in the following > mutually exclusive pairs is not considered an error: -C and > -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell). > The -l option overrides the other option specified in each > pair. > > > Specifying more than one of the options in the following > mutually exclusive pairs is not considered an error: -C and > -1 (one), -H and -L, -c and -u, and -e and -E, and -t and > -S. The last option specifying a specific timestamp (-c, -u, > -% atime , -% crtime, -% ctime, and -% mtime) determines the > timestamps used for sorting or in long format listings. > > /usr/xpg4/bin/ls > -F Marks directories with a trailing slash (/), doors > with a trailing greater-than sign (>), executable > files with a trailing asterisk (*), FIFOs with a > trailing vertical bar (|), symbolic links with a > trailing "at" sign (@), and AF_UNIX address family > sockets with a trailing equals sign (=). Follows sym- > links named as operands. > > > > Specifying more than one of the options in the following > mutually exclusive pairs is not considered an error: -C and > -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell), > -C and -1 (one), -H and -L, -c and -u, and -e and -E, and -t > and -S. The last option specifying a specific timestamp (-c, > -u, -% atime , -% crtime, -% ctime, and -% mtime) determines > the timestamps used for sorting or in long format listings. > > /usr/xpg6/bin/ls > -F Marks directories with a trailing slash (/), doors > with a trailing greater-than sign (>), executable > files with a trailing asterisk (*), FIFOs with a > trailing vertical bar (|), symbolic links with a > trailing "at" sign (@), and AF_UNIX address family > sockets with a trailing equals sign (=). Does not fol- > low symlinks named as operands unless the -H or -L > option is specified. > > > > Specifying more than one of the options in the following > mutually exclusive pairs is not considered an error: -C and > -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell), > -C and -1 (one), -H and -L, -c and -u, and -e and -E, -t and > -S. The last option specifying a specific timestamp (-c, -u, > -% atime , -% crtime, -% ctime, and -% mtime) determines the > timestamps used for sorting or in long format listings. > > | COLOR OUTPUT ... ... ... > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > /usr/bin/ls > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Availability | SUNWcsu | > |_____________________________|_____________________________| > | CSI | Enabled | > |_____________________________|_____________________________| > | Interface Stability | Committed | > |_____________________________|_____________________________| > | Standard | See below. | > |_____________________________|_____________________________| > > > > For all options except -A, -b, -e, -E, -h, -S, -v, -V, -@, > -/ and -%, see standards(5). The new non-standard options need to be added to the above list: | For all options except -A, -b, -e, -E, -h, -S, -U, -v, -V, -@, | -/, -%, and all of the long options, see standards(5). > > /usr/xpg4/bin/ls > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Availability | SUNWxcu4 | > |_____________________________|_____________________________| > | CSI | Enabled | > |_____________________________|_____________________________| > | Interface Stability | Committed | > |_____________________________|_____________________________| > | Standard | See below. | > |_____________________________|_____________________________| > > > > For all options except -A, -b, -e, -E, -h, -S, -v, -V, -@, > -/ and -%, see standards(5). The new non-standard options need to be added to the above list: | For all options except -A, -b, -e, -E, -h, -S, -U, -v, -V, -@, | -/, -%, and all of the long options, see standards(5). > > /usr/xpg6/bin/ls > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Availability | SUNWxcu6 | > |_____________________________|_____________________________| > | CSI | Enabled | > |_____________________________|_____________________________| > | Interface Stability | Committed | > |_____________________________|_____________________________| > | Standard | See below. | > |_____________________________|_____________________________| > > > > For all options except -A, -b, -e, -E, -h, -S, -v, -V, -@, > -/ and -%, see standards(5). The new non-standard options need to be added to the above list: | For all options except -A, -b, -e, -E, -h, -S, -U, -v, -V, -@, | -/, -%, and all of the long options, see standards(5). > ... ... ... From jason.brian.king@gmail.com Tue May 19 17:18:28 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4K0IR53027004 for ; Tue, 19 May 2009 17:18:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4K0IEKp021485; Wed, 20 May 2009 01:18:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJX0010326MSZ00@brm-avmta-1.central.sun.com>; Tue, 19 May 2009 18:18:22 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJX00JHE26MRG20@brm-avmta-1.central.sun.com>; Tue, 19 May 2009 18:18:22 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4K0DDO1016154; Wed, 20 May 2009 00:18:21 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-139821; Wed, 20 May 2009 00:18:21 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-24591541; Wed, 20 May 2009 00:18:19 +0000 (Z) Received: from mail-fx0-f165.google.com ([209.85.220.165] [209.85.220.165]) by relay1i.sun.com with ESMTP id BT-MMP-5259621; Wed, 20 May 2009 00:18:18 +0000 (Z) Received: by mail-fx0-f165.google.com with SMTP id 9so139673fxm.8 for ; Tue, 19 May 2009 17:18:17 -0700 (PDT) Received: by 10.239.164.73 with SMTP id s9mr52560hbd.59.1242778697471; Tue, 19 May 2009 17:18:17 -0700 (PDT) Date: Tue, 19 May 2009 19:18:17 -0500 From: Jason King Subject: 2009/228 ls enhancements Sender: jason.brian.king@gmail.com To: PSARC-ext Cc: John Sonnenschein , "Garrett D'Amore" , patricia.levinson@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_nzxseMUJeLIyDPI5WxhsNg)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=usWLbiDqZiblvpZeTeAvRLZtMca2IL/iTQgaFVBTQ7o=; b=AXkhot9LBMP9bjRS1A35qzOp8tcCimY46yS3P1IOqTqI2EUrI0qs9Twde/lNGTazqY VtvSuNeVsgR/nv7u1xGlcYoFz9bfpfhxHcWpQicYd/L9Wv83IFOyGZjznC9++9KyOm9V VA3mddjLnJHYnBA3gVMBQgxUzVa/nrq2Api40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=SjqWHAbcS3bqcqetR2Eozzl8ttOAa4W+JRW1WBKHdJUv9HHma3hE7DQdQer7bTbdun KTDPdc4rupD1c+7MmGLdc52hdclU2fUipVmkuRhAX8wAvdpYg/MystisgYjLuyb/xIxr bQhUI2jTna2QFcqPSYntSYjZ/5Z6jvq+TiQFw= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 8e1b17995cc8455e X-Antispam: No, score=-0.2/5.0, scanned in 0.437sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Status: RO Content-Length: 57887 --Boundary_(ID_nzxseMUJeLIyDPI5WxhsNg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT This should be the final update of the manpage changes (*crossing fingers*), reflecting the points that Don Cragun brought up. I don't believe they don't effect the vote (as they're just disambiguating the interaction of options), but as always speak up if you feel otherwise. Summary: 1. Added long options with no short equivalents to synopsis 2. Clarified behavior of --file-type with ls, xpg4 ls, and xpg6 ls wrt -H or -L options (matches -F behavior minus marking of executables for each). 3. Clarified interaction of -S, -t, and -U options (last one wins). 4. Clarified interaction of -h and --si options (last one wins). 5. Added new flags to list of non-standard options in attributes section. --Boundary_(ID_nzxseMUJeLIyDPI5WxhsNg) Content-type: text/plain; charset=US-ASCII; name=ls.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ls.txt X-Attachment-Id: f_fuxa2j4k0 User Commands ls(1) NAME ls - list contents of directory SYNOPSIS | /usr/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] | [-/ c | v] [-% atime | crtime | ctime | mtime | all] | [--block-size size] [--color[=when]] [--file-type] [--si] | [--time-style style] [file]... | /usr/xpg4/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] | [-/ c | v] [-% atime | crtime | ctime | mtime | all] | [--block-size size] [--color[=when]] [--file-type] [--si] | [--time-style style] [file]... | /usr/xpg6/bin/ls [-aAbcCdeEfFghHiklLmnopqrRsStuUwvVx1@] | [-/ c | v] [-% atime | crtime | ctime | mtime | all] | [--block-size size] [--color[=when]] [--file-type] [--si] | [--time-style style] [file]... DESCRIPTION For each file that is a directory, ls lists the contents of the directory. For each file that is an ordinary file, ls repeats its name and any other information requested. The output is sorted alphabetically by default. When no argument is given, the current directory (.) is listed. When several arguments are given, the arguments are first sorted appropriately, but file arguments appear before directories and their contents. There are three major listing formats. The default format for output directed to a terminal is multi-column with entries sorted down the columns. The -1 option allows single column output and -m enables stream output format. In order to determine output formats for the -C, -x, and -m options, ls uses an environment variable, COLUMNS, to determine the number of character positions available on one output line. If this variable is not set, the terminfo(4) database is used to determine the number of columns, based on the environment variable, TERM. If this information cannot be | obtained, 80 columns are assumed. If the -w option is used, | the argument will override any other column width. The mode printed when the -e, -E, -g, -l, -n, -o, -v, -V, or -@ option is in effect consists of eleven characters. The first character can be one of the following: d The entry is a directory. D The entry is a door. l The entry is a symbolic link. SunOS 5.11 Last change: 25 Mar 2008 1 User Commands ls(1) b The entry is a block special file. c The entry is a character special file. p The entry is a FIFO (or "named pipe") special file. P The entry is an event port. s The entry is an AF_UNIX address family socket. - The entry is an ordinary file. The next 9 characters are interpreted as three sets of three bits each. The first set refers to the owner's permissions; the next to permissions of others in the user-group of the file; and the last to all others. Within each set, the three characters indicate permission to read, to write, and to execute the file as a program, respectively. For a direc- tory, execute permission is interpreted to mean permission to search the directory for a specified file. The character after permissions is an ACL or extended attributes indica- tor. This character is an @ if extended attributes are asso- ciated with the file and the -@ option is in effect. Other- wise, this character is a plus sign (+) character if a non- trivial ACL is associated with the file or a space character if not. If -/ and/or -% are in effect, then the extended system attributes are printed when filesystem supports extended system attributes. The display looks as follows: $ls -/ c file -rw-r--r-- 1 root root 0 May 10 14:17 file {AHRSadim-u} $ls -/ v file -rw-r--r-- 1 root root 0 May 10 14:17 file {archive,hidden,readonly,system,appendonly\ nodump,immutable, av_modified,\ noav_quarantined,nounlink} $ls -l -% all file -rw-r--r-- 1 root root 0 May 10 14:17 file timestamp: atime Jun 25 12:56:44 2007 SunOS 5.11 Last change: 25 Mar 2008 2 User Commands ls(1) timestamp: ctime May 10 14:20:23 2007 timestamp: mtime May 10 14:17:56 2007 timestamp: crtime May 10 14:17:56 2007 See the option descriptions of the -/ and -% option for details. ls -l (the long list) prints its output as follows for the POSIX locale: -rwxrwxrwx+ 1 smith dev 10876 May 16 9:42 part2 Reading from right to left, you see that the current direc- tory holds one file, named part2. Next, the last time that file's contents were modified was 9:42 A.M. on May 16. The file contains 10,876 characters, or bytes. The owner of the file, or the user, belongs to the group dev (perhaps indi- cating ``development''), and his or her login name is smith. The number, in this case 1, indicates the number of links to file part2 (see cp(1)). The plus sign indicates that there is an ACL associated with the file. If the -@ option has been specified, the presence of extended attributes super- sede the presence of an ACL and the plus sign is replaced with an 'at' sign (@). Finally, the dash and letters tell you that user, group, and others have permissions to read, write, and execute part2. The execute (x) symbol occupies the third position of the three-character sequence. A - in the third position would have indicated a denial of execution permissions. The permissions are indicated as follows: r The file is readable. w The file is writable. x The file is executable. SunOS 5.11 Last change: 25 Mar 2008 3 User Commands ls(1) - The indicated permission is not granted. s The set-user-ID or set-group-ID bit is on, and the corresponding user or group execution bit is also on. S Undefined bit-state (the set-user-ID or set-group-id bit is on and the user or group execution bit is off). For group permissions, this applies only to non-regular files. t The 1000 (octal) bit, or sticky bit, is on (see chmod(1)), and execution is on. T The 1000 bit is turned on, and execution is off (undefined bit-state). /usr/bin/ls l Mandatory locking occurs during access (on a regular file, the set-group-ID bit is on and the group execu- tion bit is off). /usr/xpg4/bin/ls and /usr/xpg6/bin/ls L Mandatory locking occurs during access (on a regular file, the set-group-ID bit is on and the group execu- tion bit is off). For user and group permissions, the third position is some- times occupied by a character other than x or -. s or S also can occupy this position, referring to the state of the set-ID bit, whether it be the user's or the group's. The ability to assume the same ID as the user during execution is, for example, used during login when you begin as root but need to assume the identity of the user you login as. In the case of the sequence of group permissions, l can occupy the third position. l refers to mandatory file and record locking. This permission describes a file's ability to allow other files to lock its reading or writing permis- sions during access. SunOS 5.11 Last change: 25 Mar 2008 4 User Commands ls(1) For others permissions, the third position can be occupied by t or T. These refer to the state of the sticky bit and execution permissions. OPTIONS The following options are supported: /usr/bin/ls, /usr/xpg4/bin/ls, and /usr/xpg6/bin/ls The following options are supported for all three versions: | --all -a Lists all entries, including those that begin with a dot (.), which are normally not listed. | --almost-all -A Lists all entries, including those that begin with a dot (.), with the exception of the working directory (.) and the parent directory (..). | --escape -b Forces printing of non-printable characters to be in the octal \ddd notation. | --ignore-backups | -B Do not display any files ending with a tilde (~). -c Uses time of last modification of the i-node (file created, mode changed, and so forth) for sorting (-t) or printing (-l or -n). -C Multi-column output with entries sorted down the columns. This is the default output format. -d If an argument is a directory, lists only its name (not its contents). Often used with -l to get the status of a directory. -e The same as -l, except displays time to the second, and with one format for all files regard- less of age: mmm dd hh:mm:ss yyyy. -E The same as -l, except displays time to the nanosecond and with one format for all files regardless of age: yyyy-mm-dd hh:mm:ss.nnnnnnnnn (ISO 8601:2000 format). In addition, this option displays the offset from UTC in ISO 8601:2000 standard format (+hhmm or -hhmm) or no characters if the offset is indeter- minable. The offset reflects the appropriate standard or alternate offset in force at the SunOS 5.11 Last change: 25 Mar 2008 5 User Commands ls(1) file's displayed date and time, under the current timezone. -f Forces each argument to be interpreted as a directory and list the name found in each slot. This option turns off -l, -t, -s, -S, and -r, and turns on -a. The order is the order in which entries appear in the directory. | --classify | -F Append a symbol after certain types of files to | indicate the file type. The following symbols | are used: | / Directory | > Door file | | Named pipe (FIFO) | @ Symbolic link | = Socket | * Executable | | -g The same as -l, except that the owner is not printed. | --human-readable -h All sizes are scaled to a human readable format, for example, 14K, 234M, 2.7G, or 3.0T. Scaling is | done by repetitively dividing by 1024. The last | --si or -h option determines the the divisor used. | --dereference-command-line -H If an argument is a symbolic link that references a directory, this option evaluates the file information and file type of the directory that the link references, rather than those of the link itself. However, the name of the link is displayed, rather than the referenced directory. | --inode -i For each file, prints the i-node number in the first column of the report. | -k All sizes are printed in kbytes. Equivalent to | --block-size=1024. -l Lists in long format, giving mode, ACL indica- tion, number of links, owner, group, size in bytes, and time of last modification for each file (see above). If the file is a special file, the size field instead contains the major and minor device numbers. If the time of last modifi- cation is greater than six months ago, it is shown in the format `month date year' for the POSIX locale. When the LC_TIME locale category is not set to the POSIX locale, a different format of the time field can be used. Files modified within six months show `month date time'. If the file is a symbolic link, the filename is printed followed by "->" and the path name of the refer- enced file. | --dereference -L If an argument is a symbolic link, this option evaluates the file information and file type of the file or directory that the link references, SunOS 5.11 Last change: 25 Mar 2008 6 User Commands ls(1) rather than those of the link itself. However, the name of the link is displayed, rather than the referenced file or directory. -m Streams output format. Files are listed across the page, separated by commas. | --numeric-uid-gid -n The same as -l, except that the owner's UID and group's GID numbers are printed, rather than the associated character strings. | --no-group -o The same as -l, except that the group is not printed. -p Puts a slash (/) after each filename if the file is a directory. | --hide-control-chars -q Forces printing of non-printable characters in file names as the character question mark (?). | --reverse -r Reverses the order of sort to get reverse alpha- betic, oldest first, or smallest file size first as appropriate. | --recursive -R Recursively lists subdirectories encountered. | --size -s Indicate the total number of file system blocks consumed by each file displayed. -S Sort by file size (in decreasing order) and for files with the same size by file name (in increasing alphabetic order) instead of just by name. -t Sorts by time stamp (latest first) instead of by name. The default is the last modification time. See -c, -u and -%. -u Uses time of last access instead of last modifi- cation for sorting (with the -t option) or print- ing (with the -l option). SunOS 5.11 Last change: 25 Mar 2008 7 User Commands ls(1) | -U Output is unsorted. -v The same as -l, except that verbose ACL informa- tion is displayed as well as the -l output. ACL information is displayed even if the file or directory doesn't have an ACL. -V The same as -l, except that compact ACL informa- tion is displayed after the -l output. The -V option is only applicable to file systems that support NFSv4 ACLs, such as the Solaris ZFS file system. The format of the displayed ACL is as follows: entry_type : permissions : inheritance_flags : access_type entry_type is displayed as one of the following: user:username Additional user access for username. group:groupname Additional group access for group groupname. owner@ File owner. group@ File group owner. everyone@ Everyone access, including file owner and file group owner. This is not equivalent to the POSIX other class. The following permissions, supported by the NFSv4 ACL model, are displayed by using the -v or -V options: read_data (r) Permission to read the data of a file. list_directory (r) Permission to list the contents of a directory. SunOS 5.11 Last change: 25 Mar 2008 8 User Commands ls(1) write_data (w) Permission to modify a file's data. anywhere in the file's offset range. add_file (w) Permission to add a new file to a directory. append_data (p) The ability to modify a file's data, but only starting at EOF. add_subdirectory (p) Permission to create a subdirectory to a direc- tory. read_xattr (R) Ability to read the extended attributes of a file. write_xattr (W) Ability to create extended attributes or write to the extended attribute directory. execute (x) Permission to execute a file. read_attributes (a) The ability to read basic attributes (non-ACLs) of a file. write_attributes (A) Permission to change the times associated with a file or directory to an arbitrary value. delete (d) Permission to delete a file. delete_child (D) Permission to delete a file within a directory. SunOS 5.11 Last change: 25 Mar 2008 9 User Commands ls(1) read_acl (r) Permission to read the ACL of a file. write_acl (C) Permission to write the ACL of a file. write_owner (o) Permission to change the owner of a file. synchronize (s) Permission to access file locally at server with synchronize reads and writes. - No permission granted The following inheritance flags, supported by the NFSv4 ACL model, are displayed by using the -v or -V options: file_inherit (f) Inherit to all newly created files. dir_inherit (d) Inherit to all newly created directories. inherit_only (i) When placed on a direc- tory, do not apply to the directory, only to newly created files and directories. This flag requires that either file_inherit and or dir_inherit is also specified. no_propagate (n) Indicates that ACL entries should be inher- ited to objects in a directory, but inheri- tance should stop after descending one level. This flag is dependent upon either file_inherit and or dir_inherit also SunOS 5.11 Last change: 25 Mar 2008 10 User Commands ls(1) being specified. successful_access (S) Indicates if an alarm or audit record should be initiated upon success- ful accesses. Used with audit/alarm ACE types. failed_access (F) Indicates if an alarm or audit record should be initiated when access fails. Used with audit/alarm ACE types. inherited (I) ACE was inherited. - No permission granted. access_type is displayed as one of the following types: alarm Permission field that specifies permis- sions that should trigger an alarm. allow Permission field that specifies allow permissions. audit Permission field that specifies permis- sions that should be audited. deny Permission field that specifies deny permissions. For example: $ ls -dV /sandbox/dir.1 drwxr-xr-x+ 2 root root 2 Jan 17 15:09 dir.1 user:marks:r-------------:fd-----:allow owner@:--------------:-------:deny owner@:rwxp---A-W-Co-:-------:allow group@:-w-p----------:-------:deny group@:r-x-----------:-------:allow everyone@:-w-p---A-W-Co-:-------:deny everyone@:r-x---a-R-c--s:-------:allow $ SunOS 5.11 Last change: 25 Mar 2008 11 User Commands ls(1) ||||||||||||||||:||||||+ inherited access ||||||||||||||:||||||+ failed access ||||||||||||||:|||||+--success access ||||||||||||||:||||+-- no propagate ||||||||||||||:|||+--- inherit only ||||||||||||||:||+---- directory inherit ||||||||||||||:|+----- file inherit |||||||||||||| ||||||||||||||+ sync |||||||||||||+- change owner ||||||||||||+-- write ACL |||||||||||+--- read ACL ||||||||||+---- write extended attributes |||||||||+----- read extended attributes ||||||||+------ write attributes |||||||+------- read attributes ||||||+-------- delete child |||||+--------- delete ||||+---------- append |||+----------- execute ||+------------ write data |+------------- read data | --width cols | -w cols Multi-column output where the column width is | forced to cols. -x Multi-column output with entries sorted across rather than down the page. -1 Prints one entry per line of output. -@ The same as -l, except that extended attribute information overrides ACL information. An @ is displayed after the file permission bits for files that have extended attributes. -c | -v The same as -l, and in addition displays the extended system attributes associated with the file when extended system attributes are fully supported by the underlying file system. The option -/ supports two option arguments c (com- pact mode) and v (verbose mode). appendonly Allows a file to be modified only at offset EOF. Attempts to modify a file at a location other than EOF fails with EPERM. SunOS 5.11 Last change: 25 Mar 2008 12 User Commands ls(1) archive Indicates if a file has been modified since it was last backed up. Whenever the modifi- cation time (mtime) of a file is changed the archive attri- bute is set. av_modified ZFS sets the anti-virus attri- bute which whenever a file's content or size changes or when the file is renamed. av_quarantined Anti-virus software sets to mark a file as quarantined. crtime Timestamp when a file is created. hidden Marks a file as hidden. immutable Prevents the content of a file from being modified. Also prevents all metadata changes, except for access time updates. When placed on a directory, prevents the deletion and crea- tion of files in the direc- tories. Attempts to modify the content of a file or directory marked as immutable fail with EPERM. Attempts to modify any attributes (with the exception of access time and, with the proper privileges, the immut- able) of a file marked as immutable fails with EPERM. nodump Solaris systems have no special semantics for this attribute. nounlink Prevents a file from being deleted. On a directory, the attribute also prevents any changes to the contents of the directory. That is, no files SunOS 5.11 Last change: 25 Mar 2008 13 User Commands ls(1) within the directory can be removed or renamed. The errno EPERM is returned when attempt- ing to unlink or rename files and directories that are marked as nounlink. readonly Marks a file as readonly. Once a file is marked as readonly the content data of the file cannot be modified. Other meta- data for the file can still be modified. system Solaris systems have no special semantics for this attribute. The display characters used in compact mode (-/ c) are as follows: Attribute Name Display archive A hidden H readonly R system S appendonly a nodump d immutable i av_modified m av_quarantined q nounlink u The display in verbose mode (/ v) uses full attribute names when it is set and the name prefixed by 'no' when it is not set. The attribute name crtime and all other timestamps are han- dled by the option -% with the respective timestamp option arguments and also with all option argument. The display positions are as follows: The display in verbose mode (-/ v) uses full attribute names when it is set and the name pre- fixed by no when it is not set. The attribute name crtime and all other timestamps are handled by the option -% with SunOS 5.11 Last change: 25 Mar 2008 14 User Commands ls(1) the respective timestamp option arguments and also with all option argument. The display positions are as follows: {||||||||||} |||||||||+- u (nounlink) ||||||||+-- q (av_quarantined) |||||||+--- m (av_modified) ||||||+---- i (immutable) |||||+----- d (nodump) ||||+------ a (appendonly) |||+------- S (system) ||+-------- R (readonly) |+--------- H (hidden) +---------- A (archive) -% atime | crtime | ctime | mtime | all atime Equivalent to -u. crtime Uses the creation time of the file for sorting or printing. ctime Equivalent to -c. mtime Uses the last modification time of the file con- tents for sorting or printing. If extended system attributes are not supported or if the user does not have read permission on the file or if the crtime extended attribute is not set, crtime is treated as a synonym for mtime. When option argument -all is specified, all available times- tamps are printed which includes -atime, -ctime, -mtime and on the extended system attribute supporting file systems, -crtime (create time). The option -% all does not effect which timestamp is displayed in long format and does not affect sorting. SunOS 5.11 Last change: 25 Mar 2008 15 User Commands ls(1) | --block-size size | Display sizes in multiples of size. Size can be scaled by suffixing | one of 'YyZzEePpTtGgMmKk'. Additionally, a 'B' can be placed at the | end to indicate powers of 10 instead of 2 (e.g. '10mB' means blocks of | 10000000 bytes while '10m' would mean blocks of 10*2^20 -- | 10485760 -- bytes). This is mutually exclusive with the -h option. | | --color[=when] | --colour[=when] | Display filenames using color on color-capable terminals. | When is an optional argument that determines when color | output should be displayed. Possible values are: | always, yes, or force: Always use color | auto, tty, if-tty: Use color if a terminal is present | no, never, none: Never use color. This is the default. | See COLOR OUTPUT for information on how to control the colors | used in output. | | --file-type | Display a suffix after a file depending on it's type, similar | to the -F option, except * is not appended to executable files. | | --si | Display human scaled sizes similar to the -h option, except | values are repeatedly divided by 1000 instead of 1024. The | last option --si or -h determines the divisor used. | | --time-style style | Display times using the specified style. This does not effect | the times displayed for extended attributes (-%). | Possible values for style are: | full-iso: Equivalent to -E | long-iso: Display in YYYY-MM-DD HH:MM for all files | iso: Display older files using YYYY-MM-DD and newer files | with MM-DD HH:MM | locale: Use the default locale format for old and new files. | This is the default. | +FORMAT: Use a custom format. Values are the same as described | in strftime(3c). If a newline appears in the string, | the first line is used for older files and the | second line is used for newer files, otherwise the | given format is used for all files. /usr/bin/ls -F Marks directories with a trailing slash (/), doors with a trailing greater-than sign (>), executable files with a trailing asterisk (*), FIFOs with a trailing vertical bar (|), symbolic links with a trailing "at" sign (@), and AF_UNIX address family sockets with a trailing equals sign (=). Follows sym- links named as operands. | --file-type | Marks entries as with -F with the exception of executable | files. Executable files are not marked. Follows sym- | links named as operands. Specifying more than one of the options in the following mutually exclusive pairs is not considered an error: -C and -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell). The -l option overrides the other option specified in each pair. Specifying more than one of the options in the following | mutually exclusive groups is not considered an error: -C and | -1 (one), -H and -L, -c and -u, -e and -E, and -t and -U and -S. The last option specifying a specific timestamp (-c, -u, -% atime , -% crtime, -% ctime, and -% mtime) determines the | timestamps used for sorting or in long format listings. The | last option -t, -S, or -U determines the sorting behavior. /usr/xpg4/bin/ls -F Marks directories with a trailing slash (/), doors with a trailing greater-than sign (>), executable files with a trailing asterisk (*), FIFOs with a trailing vertical bar (|), symbolic links with a trailing "at" sign (@), and AF_UNIX address family sockets with a trailing equals sign (=). Follows sym- links named as operands. | --file-type | Marks entries as with -F with the exception of executable | files. Executable files are not marked. Follows sym- | links named as operands. | Specifying more than one of the options in the following | groups of mutually exclusive options is not considered an | error: -C and -l (ell), -m and -l (ell), -x and -l (ell), | -@ and -l (ell), -C and -1 (one), -H and -L, -c and -u, -e and | -E, -t and -S and -U. The last option specifying a specific | timestamp (-c, -u, -% atime , -% crtime, -% ctime, and -% mtime) | determines the timestamps used for sorting or in long format listings. | The last -t, -S, or -U option determines the sorting behavior. /usr/xpg6/bin/ls -F Marks directories with a trailing slash (/), doors with a trailing greater-than sign (>), executable files with a trailing asterisk (*), FIFOs with a trailing vertical bar (|), symbolic links with a trailing "at" sign (@), and AF_UNIX address family sockets with a trailing equals sign (=). Does not fol- low symlinks named as operands unless the -H or -L SunOS 5.11 Last change: 25 Mar 2008 16 User Commands ls(1) option is specified. | --file-type | Marks entries as with -F with the exception of executable | files. Executable files are not marked. Does not fol- | low symlinks named as operands unless the -H or -L | option is specified. Specifying more than one of the options in the following mutually exclusive pairs is not considered an error: -C and -l (ell), -m and -l (ell), -x and -l (ell), -@ and -l (ell), | -C and -1 (one), -H and -L, -c and -u, -e and -E, -t and -S | and -U. The last option specifying a specific timestamp (-c, -u, -% atime , -% crtime, -% ctime, and -% mtime) determines the | timestamps used for sorting or in long format listings. The | last -t, -S, or -U option determines the sorting behavior. | COLOR OUTPUT | If color output is enabled, the environment variable LS_COLORS | is checked. If it exists, it's contents are used to control | the colors used to display filenames. If it is not set, a | default list of colors is used. | | The format of LS_COLORS is a colon separated list of attribute | specifications. Each attribute specification is of the format: | filespec=attr[;attr..] | filespec is either of the form '*.SUFFIX' (ex. '*.jar'or | '*.Z' or one of the following filetypes (in least to most | specific order): | no Normal file | fi Regular file | di Directory | ln Symbolic link | pi FIFO or named pipe | so Socket | do Door file | bd Block device | cd Character device | ex Execute bit (either user, group, or other) set | po Event port | st Sticky bit set | or Orphaned symlink | sg Setgid binary | su Setuid binary | ow World writable | tw Sticky bit and world writable | | attr is a semicolon delimited list of color and display | attributes which are combined to determine the final | output color. Possible attribute values are: | Any combination of the following can be chosen: | 00 All attributes off (default terminal color) | this cancels any preceeding effects. | 01 Display text in bold | 04 Display text with an underscore | 05 Display text as blinking | 07 Display text with foreground and background | colors reversed | 08 Display using concealed text. | | One of the following can be chosen. If multiple | values are given, the last value is used. | 30 Set foreground to black | 31 Set foreground to red | 32 Set foreground to green | 33 Set foreground to yellow | 34 Set foreground to blue | 35 Set foreground to magenta (purple) | 36 Set foreground to cyan | 37 Set foreground to white | 39 Set foreground to default terminal color | | One of the following can be chosen. If multiple | values are given, the last value is used. | 40 Set background to black | 41 Set background to red | 42 Set background to green | 43 Set background to yellow | 44 Set background to blue | 45 Set background to magenta (purple) | 46 Set background to cyan | 47 Set background to white | 49 Set background to default terminal color | | NOTE: On some terminals, setting the bold attribute | causes the foreground colors to instead be | 'high-intensity' (i.e. brighter). In such cases | the low-intensity yellow is often displayed as | a brown or orange color. | | At least one attribute must be listed for a file | specification. | | The appropriate color codes are chosen by selecting the most | specific match, starting with the file suffixes and | proceeding with the filetypes until a match is found. The | no (normal file) type will match any file. | OPERANDS The following operand is supported: file A path name of a file to be written. If the file specified is not found, a diagnostic message is out- put on standard error. USAGE See largefile(5) for the description of the behavior of ls when encountering files greater than or equal to 2 Gbyte ( 2^31 bytes). EXAMPLES Example 1 Viewing File Permissions The following example shows how to display detailed informa- tion about a file. % ls -l file.1 -rw-r--r-- 1 gozer staff 206663 Mar 14 10:15 file.1 The permissions string above (-rw-r--r--) describes that the file owner has read and write permissions, the owning group has read permissions, and others have read permissions. The following example shows how to display detailed informa- tion about a directory. % ls -ld test.dir drwxr-xr-x 2 gozer staff 2 Mar 14 10:17 test.dir SunOS 5.11 Last change: 25 Mar 2008 17 User Commands ls(1) The permissions string above (drwxr-xr-x) describes that the directory owner has read, write, and search permissions, the owning group has read and search permissions, and others have read and search permissions. Another example of listing file permissions is as follows: % ls -l file.2 -rw-rwl--- 1 gozer staff 206663 Mar 14 10:47 file.2 The permissions string above (-rw-rwl---) describes that the file owner has read and write permissions, the owning group has read and write permissions, and the file can be locked during access. Example 2 Displaying ACL Information on Files and Direc- tories The following example shows how to display verbose ACL information on a ZFS file. % ls -v file.1 -rw-r--r-- 1 marks staff 206663 Mar 14 10:15 file.1 0:owner@:execute:deny 1:owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2:group@:write_data/append_data/execute:deny 3:group@:read_data:allow 4:everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow The following example shows how to display compact ACL information on a ZFS directory. % ls -dV test.dir drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir owner@:--------------:------:deny SunOS 5.11 Last change: 25 Mar 2008 18 User Commands ls(1) owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow The following example illustrates the ls -v behavior when listing ACL information on a UFS file. $ ls -v file.3 -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 0:user::rw- 1:group::r-- #effective:r-- 2:mask:r-- 3:other:r-- Example 3 Printing the Names of All Files The following example prints the names of all files in the current directory, including those that begin with a dot (.), which normally do not print: example% ls -a Example 4 Providing File Information The following example provides file information: example% ls -aisn This command provides information on all files, including those that begin with a dot (a), the i-number, the memory address of the i-node associated with the file-printed in the left-hand column (i); the size (in blocks) of the files, printed in the column to the right of the i-numbers (s); finally, the report is displayed in the numeric version of the long list, printing the UID (instead of user name) and SunOS 5.11 Last change: 25 Mar 2008 19 User Commands ls(1) GID (instead of group name) numbers associated with the files. When the sizes of the files in a directory are listed, a total count of blocks, including indirect blocks, is printed. Example 5 Providing Extended System Attributes Information example% ls -/ c file (extended system attribute in compact mode) -rw-r--r-- 1 root root 0 May 10 14:17 file {AHRSadim-u} In this example, av_quarantined is not set. example% ls -/ v file (extended system attribute in verbose mode) -rw-r--r-- 1 root root 0 May 10 14:17 file {archive,hidden,readonly,system,appendonly\ nodump,immutable,av_modified,\ noav_quarantined,nounlink} example% ls -/ v file (no extended system attribute) -rw-r--r-- 1 root staff 0 May 16 14:48 file {} example% ls -/ c file (extended system attribute supported file system) -rw-r--r-- 1 root staff 3 Jun 4 22:04 file {A------m--} archive and av_modified attributes are set by default on an extended system attribute supported file. example% ls -/ c -%crtime file -rw-r--r-- root root 0 May 10 14:17 file {AHRSadim-u} SunOS 5.11 Last change: 25 Mar 2008 20 User Commands ls(1) This example displays the timestamp as the creation time: example% ls -l -%all file -rw-r--r-- 1 root root 0 May 10 14:17 file timestamp: atime Jun 14 08:47:37 2007 timestamp: ctime May 10 14:20:23 2007 timestamp: mtime May 10 14:17:56 2007 timestamp: crtime May 10 14:17:56 2007 example% ls -%crtime -tl file* -rw-r--r-- 1 foo staff 3 Jun 4 22:04 file1 -rw-r--r-- 1 root root 0 May 10 14:17 file -rw-r--r-- 1 foo staff 0 May 9 13:49 file.1 In this example the files are sorted by creation time. ENVIRONMENT VARIABLES See environ(5) for descriptions of the following environment variables that affect the execution of ls: LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_TIME, LC_MESSAGES, NLSPATH, and TZ. COLUMNS Determines the user's preferred column position width for writing multiple text-column output. If this variable contains a string representing a decimal integer, the ls utility calculates how many path name text columns to write (see -C) based on the width provided. If COLUMNS is not set or is invalid, 80 is used. The column width chosen to write the names of files in any given directory is constant. File names are not be truncated to fit into the multiple text-column output. | LS_COLORS Determines the coloring scheme used when | displaying color output. If not set and color | output is specified, a default scheme is used. If | TERM is not set, no color output will be used. | | TERM Determine the terminal type. If this variable is | unset or NULL, no color output will be generated | regardless of the value of the --color option. EXIT STATUS 0 All information was written successfully. >0 An error occurred. FILES /etc/group group IDs for ls -l and ls -g SunOS 5.11 Last change: 25 Mar 2008 21 User Commands ls(1) /etc/passwd user IDs for ls -l and ls -o /usr/share/lib/terminfo/?/* terminal information database ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: /usr/bin/ls ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | CSI | Enabled | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | Standard | See below. | |_____________________________|_____________________________| | For all options except -A, -b, -e, -E, -h, -S, -U, -v, -V, -@, | -/, -%, --all, --almost-all, --block-size, --classify, --color, | --colour, --dereference, --dereference-command-line, --escape, | --file-type, --full-time, --human-readable, --ignore-backups, | --inode, --no-group, --numeric-uid-gid, --reverse, --recursive, | --si, --size, and --time-style, see standards(5). /usr/xpg4/bin/ls SunOS 5.11 Last change: 25 Mar 2008 22 User Commands ls(1) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWxcu4 | |_____________________________|_____________________________| | CSI | Enabled | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | Standard | See below. | |_____________________________|_____________________________| | For all options except -A, -b, -e, -E, -h, -S, -U, -v, -V, -@, | -/, -%, --all, --almost-all, --block-size, --classify, --color, | --colour, --dereference, --dereference-command-line, --escape, | --file-type, --full-time, --human-readable, --ignore-backups, | --inode, --no-group, --numeric-uid-gid, --reverse, --recursive, | --si, --size, and --time-style, see standards(5). /usr/xpg6/bin/ls ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWxcu6 | |_____________________________|_____________________________| | CSI | Enabled | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | Standard | See below. | |_____________________________|_____________________________| | For all options except -A, -b, -e, -E, -h, -S, -U, -v, -V, -@, | -/, -%, --all, --almost-all, --block-size, --classify, --color, | --colour, --dereference, --dereference-command-line, --escape, | --file-type, --full-time, --human-readable, --ignore-backups, | --inode, --no-group, --numeric-uid-gid, --reverse, --recursive, | --si, --size, and --time-style, see standards(5). SEE ALSO chmod(1), cp(1), setfacl(1), fgetattr(3C), terminfo(4), acl(5), attributes(5), environ(5), fsattr(5), largefile(5), standards(5) NOTES Unprintable characters in file names can confuse the colum- nar output options. The total block count is incorrect if there are hard links among the files. The sort order of ls output is affected by the locale and can be overridden by the LC_COLLATE environment variable. For example, if LC_COLLATE equals C, dot files appear first, SunOS 5.11 Last change: 25 Mar 2008 23 User Commands ls(1) followed by names beginning with upper-case letters, then followed by names beginning with lower-case letters. But if LC_COLLATE equals en_US.ISO8859-1, then leading dots as well as case are ignored in determining the sort order. SunOS 5.11 Last change: 25 Mar 2008 24 --Boundary_(ID_nzxseMUJeLIyDPI5WxhsNg)-- From carlsonj@phorcys.east.sun.com Wed May 20 07:33:56 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KEXugF003141 for ; Wed, 20 May 2009 07:33:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4KEXtT1008220; Wed, 20 May 2009 07:33:56 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJY00J0X5SIMD00@nwk-avmta-2.sfbay.sun.com>; Wed, 20 May 2009 07:33:54 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00C8L5SHU6C0@nwk-avmta-2.sfbay.sun.com>; Wed, 20 May 2009 07:33:54 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KEXphW053908; Wed, 20 May 2009 10:33:51 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4KEWtip002210; Wed, 20 May 2009 10:32:55 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4KEWsaq002207; Wed, 20 May 2009 10:32:54 -0400 (EDT) Date: Wed, 20 May 2009 10:32:54 -0400 From: James Carlson Subject: Re: 2009/228 ls enhancements In-reply-to: To: Jason King Cc: PSARC-ext , John Sonnenschein , "Garrett D'Amore" , Patricia.Levinson@sun.com Message-id: <18964.5270.944764.43562@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: Status: RO Content-Length: 603 Jason King writes: > This should be the final update of the manpage changes (*crossing > fingers*), reflecting the points that Don Cragun brought up. I don't > believe they don't effect the vote (as they're just disambiguating the > interaction of options), but as always speak up if you feel otherwise. You've got my +1 for the changes. Especially since the ship has sailed. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon May 25 09:45:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4PGjEtS007322 for ; Mon, 25 May 2009 09:45:14 -0700 (PDT) Received: from newsunmail1brm.central.sun.com (localhost [127.0.0.1]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4PGjEDm043163 for ; Mon, 25 May 2009 10:45:14 -0600 (MDT) Received: (from noaccess@localhost) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/Submit) id n4PGjE96043160 for sac-opinion-not-2b-used-directly; Mon, 25 May 2009 10:45:14 -0600 (MDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4PGjDSN043142; Mon, 25 May 2009 10:45:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK700103L7DEJ00@nwk-avmta-2.sfbay.sun.com>; Mon, 25 May 2009 09:45:13 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK700JV2L7CA130@nwk-avmta-2.sfbay.sun.com>; Mon, 25 May 2009 09:45:13 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4PGjCl6016582; Mon, 25 May 2009 09:45:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK700H00L51TM00@fe-sfbay-09.sun.com>; Mon, 25 May 2009 09:45:12 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK700MU3L7CNZ50@fe-sfbay-09.sun.com>; Mon, 25 May 2009 09:45:12 -0700 (PDT) Date: Mon, 25 May 2009 09:45:12 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/228 ls enhancements Sender: Garrett.Damore@sun.com To: sac-opinion@sun.com, solaris-pac-opinion@sun.com Message-id: <4A1ACB18.9040305@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2647 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: ls enhancements Submitted by: Jason King File: PSARC/2009/228/opinion.ms Date: April 29th, 2009 Committee: Garrett D'Amore, James D. Carlson, Mark Carl- son, Sebastien Roy Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project proposes to add enhancements to the ls(1) util- ity to make it more familiar to users coming from other operating systems such as Linux. Perhaps most notable among those enhancements is addition of support for colorized listings using the --color argument. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of the ON consolidation. 3. Interfaces The project exports the following interfaces. _______________________________________________ | Interfaces Exported | |_________________|________________|__________| |Interface | Classification| Comments| |_________________|________________|__________| |/usr/bin/ls | Committed | | |/usr/xpg4/bin/ls | Committed | | |/usr/xpg6/bin/ls | Committed | | |_________________|________________|__________| PSARC/2009/228 Copyright 2009 Sun Microsystems - 2 - 4. Opinion During review, two issues concerning the use of long options (--option) were raised. The first concern pertains to the fact that not all long options have a corresponding short flag. The members of the committee felt that since this is also true of Linux interface being emulated, that this was acceptable. The second concern pertained to the fact that for some of those same options, the presence of an argument is optional. The members present felt that while such an "optional argu- ment" might be ambiguous for a short flag, for long options there is no ambiguity (because of the separating "="), and hence the behavior is acceptable. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/228. 3. ls man page File: ls.txt 3. Project proposal File: 20090408_jason.king PSARC/2009/228 Copyright 2009 Sun Microsystems From John.Fischer@sun.com Tue May 26 08:34:54 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QFYruJ012780 for ; Tue, 26 May 2009 08:34:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QFYr8v006252 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 May 2009 08:34:53 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900B8DCM5C600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 May 2009 08:34:53 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK9005ALCM1PG60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 May 2009 08:34:49 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QFYnqW021435 for ; Tue, 26 May 2009 15:34:49 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK900F008ZXBI00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 May 2009 09:34:49 -0600 (MDT) Received: from [192.168.10.5] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK900DB1CLNZ530@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 May 2009 09:34:36 -0600 (MDT) Date: Tue, 26 May 2009 08:33:13 -0700 From: John Fischer Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <4A1ACB18.9040305@sun.com> Sender: John.Fischer@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <4A1C0BB9.1070303@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A1ACB18.9040305@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3294 Garrett, Unfortunately, we have not defined what is meant by the phrase "a patch release of the ON consolidation". What is defined is "a Patch release of Solaris". Or other similar product lines. So unless something has dramatically changed in the last few months and I missed it this opinion needs to be changed to the defined terminology. Sorry I missed this while it was going through the PSARC review stage. Thanks, John Garrett D'Amore wrote: > sun > microsystems Systems Architecture Committee > > _________________________________________________________________ > > Subject: ls enhancements > > Submitted by: Jason King > > File: PSARC/2009/228/opinion.ms > > Date: April 29th, 2009 > > Committee: Garrett D'Amore, James D. Carlson, Mark Carl- > son, Sebastien Roy > > Product Approval Committee: > Solaris PAC > solaris-pac-opinion@sun.com > > 1. Summary > > This project proposes to add enhancements to the ls(1) util- > ity to make it more familiar to users coming from other > operating systems such as Linux. Perhaps most notable among > those enhancements is addition of support for colorized > listings using the --color argument. > > 2. Decision & Precedence Information > > The project is approved as specified in reference [1]. > > The project may be delivered in a patch release of the ON > consolidation. > > 3. Interfaces > > The project exports the following interfaces. > > _______________________________________________ > | Interfaces Exported | > |_________________|________________|__________| > |Interface | Classification| Comments| > |_________________|________________|__________| > |/usr/bin/ls | Committed | | > |/usr/xpg4/bin/ls | Committed | | > |/usr/xpg6/bin/ls | Committed | | > |_________________|________________|__________| > > PSARC/2009/228 Copyright 2009 Sun Microsystems > > - 2 - > > 4. Opinion > > During review, two issues concerning the use of long options > (--option) were raised. The first concern pertains to the > fact that not all long options have a corresponding short > flag. The members of the committee felt that since this is > also true of Linux interface being emulated, that this was > acceptable. > > The second concern pertained to the fact that for some of > those same options, the presence of an argument is optional. > The members present felt that while such an "optional argu- > ment" might be ambiguous for a short flag, for long options > there is no ambiguity (because of the separating "="), and > hence the behavior is acceptable. > > 5. Minority Opinion(s) > > None. > > 6. Advisory Information > > None. > > 7. Appendices > > 7.1. Appendix A: Technical Changes Required > > None. > > 7.2. Appendix B: Technical Changes Advised > > None. > > 7.3. Appendix C: Reference Material > > Unless stated otherwise, path names are relative to the case > directory PSARC/2009/228. > > 3. ls man page File: ls.txt > > 3. Project proposal File: 20090408_jason.king > > PSARC/2009/228 Copyright 2009 Sun Microsystems > > From gdamore@Sun.COM Tue May 26 08:51:45 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QFpjES013225 for ; Tue, 26 May 2009 08:51:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QFpgTp027903 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 May 2009 09:51:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900K09DE6NH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 26 May 2009 08:51:42 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK900FU9DE5FD80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 26 May 2009 08:51:41 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QFpfPf000534 for ; Tue, 26 May 2009 08:51:41 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK900600BTC1700@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 26 May 2009 08:51:41 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK900J8ODDJFO20@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 26 May 2009 08:51:20 -0700 (PDT) Date: Tue, 26 May 2009 08:51:19 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <4A1C0BB9.1070303@sun.com> Sender: Garrett.Damore@Sun.COM To: John.Fischer@Sun.COM Cc: PSARC-ext@Sun.COM Message-id: <4A1C0FF7.8020007@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A1ACB18.9040305@sun.com> <4A1C0BB9.1070303@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3793 I'd already sent this out to sac-opinion for archiving. I'm not sure how one changes the opinion at this point. Its pretty obvious what was meant, and I'm sorry I botched the terminology. Is it important enough to warrant figuring out how to fix it at this point? (I also don't have any plans to do a backport, nor am I aware of anyone else else who does, btw.) - Garrett John Fischer wrote: > Garrett, > > Unfortunately, we have not defined what is meant by the phrase > "a patch release of the ON consolidation". What is defined is > "a Patch release of Solaris". Or other similar product lines. > So unless something has dramatically changed in the last few > months and I missed it this opinion needs to be changed to the > defined terminology. > > Sorry I missed this while it was going through the PSARC review > stage. > > Thanks, > > John > > Garrett D'Amore wrote: >> sun >> microsystems Systems Architecture Committee >> >> _________________________________________________________________ >> >> Subject: ls enhancements >> >> Submitted by: Jason King >> >> File: PSARC/2009/228/opinion.ms >> >> Date: April 29th, 2009 >> >> Committee: Garrett D'Amore, James D. Carlson, Mark Carl- >> son, Sebastien Roy >> >> Product Approval Committee: >> Solaris PAC >> solaris-pac-opinion@sun.com >> >> 1. Summary >> >> This project proposes to add enhancements to the ls(1) util- >> ity to make it more familiar to users coming from other >> operating systems such as Linux. Perhaps most notable among >> those enhancements is addition of support for colorized >> listings using the --color argument. >> >> 2. Decision & Precedence Information >> >> The project is approved as specified in reference [1]. >> >> The project may be delivered in a patch release of the ON >> consolidation. >> >> 3. Interfaces >> >> The project exports the following interfaces. >> >> _______________________________________________ >> | Interfaces Exported | >> |_________________|________________|__________| >> |Interface | Classification| Comments| >> |_________________|________________|__________| >> |/usr/bin/ls | Committed | | >> |/usr/xpg4/bin/ls | Committed | | >> |/usr/xpg6/bin/ls | Committed | | >> |_________________|________________|__________| >> >> PSARC/2009/228 Copyright 2009 Sun Microsystems >> >> - 2 - >> >> 4. Opinion >> >> During review, two issues concerning the use of long options >> (--option) were raised. The first concern pertains to the >> fact that not all long options have a corresponding short >> flag. The members of the committee felt that since this is >> also true of Linux interface being emulated, that this was >> acceptable. >> >> The second concern pertained to the fact that for some of >> those same options, the presence of an argument is optional. >> The members present felt that while such an "optional argu- >> ment" might be ambiguous for a short flag, for long options >> there is no ambiguity (because of the separating "="), and >> hence the behavior is acceptable. >> >> 5. Minority Opinion(s) >> >> None. >> >> 6. Advisory Information >> >> None. >> >> 7. Appendices >> >> 7.1. Appendix A: Technical Changes Required >> >> None. >> >> 7.2. Appendix B: Technical Changes Advised >> >> None. >> >> 7.3. Appendix C: Reference Material >> >> Unless stated otherwise, path names are relative to the case >> directory PSARC/2009/228. >> >> 3. ls man page File: ls.txt >> >> 3. Project proposal File: 20090408_jason.king >> >> PSARC/2009/228 Copyright 2009 Sun Microsystems >> >> From carlsonj@phorcys.east.sun.com Tue May 26 08:52:35 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QFqYpj013261 for ; Tue, 26 May 2009 08:52:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QFqGlH013494; Tue, 26 May 2009 08:52:33 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900K0BDFGOF00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 08:52:28 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK900FFJDFGF790@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 08:52:28 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QFqRdn006518; Tue, 26 May 2009 11:52:27 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4QFpP4e015474; Tue, 26 May 2009 11:51:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4QFpPtU015471; Tue, 26 May 2009 11:51:25 -0400 (EDT) Date: Tue, 26 May 2009 11:51:25 -0400 From: James Carlson Subject: Re: PSARC 2009/228 ls enhancements In-reply-to: <4A1C0BB9.1070303@sun.com> To: John.Fischer@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <18972.4093.74103.767195@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A1ACB18.9040305@sun.com> <4A1C0BB9.1070303@sun.com> Status: RO Content-Length: 1211 John Fischer writes: > Unfortunately, we have not defined what is meant by the phrase > "a patch release of the ON consolidation". What is defined is > "a Patch release of Solaris". Or other similar product lines. > So unless something has dramatically changed in the last few > months and I missed it this opinion needs to be changed to the > defined terminology. This is something that John Plocher changed some time ago. His assertion was that (in the new world) each consolidation gets to set and manage a release binding, and so the ARC needs to specify which consolidation and type of release. What he was trying to enable was a series of consecutive Major releases for some more fluid consolidations with a series of Minor or lower releases for more stable ones. I still don't quite agree with the logic (I think it's ultimately the distributors who must set release bindings), but I think that either the traditional language or the new text works in most practical cases. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677