From sacadmin Fri Nov 11 13:08:53 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jABL8rIQ008794; Fri, 11 Nov 2005 13:08:53 -0800 (PST) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id jABL8qJM001209; Fri, 11 Nov 2005 13:08:52 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10/Submit) id jABL8qI8001205; Fri, 11 Nov 2005 13:08:52 -0800 (PST) Date: Fri, 11 Nov 2005 13:08:52 -0800 (PST) Message-Id: <200511112108.jABL8qI8001205@spartan.SFBay.Sun.COM> From: Don Cragun To: PSARC@sac.sfbay.sun.com Cc: carol.fields@sun.com Subject: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] Status: RO Content-Length: 3923 Subject: PSARC FastTrack [11/18/2005]: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab I am submitting this fasttrack for Carol Fields. Carol is seeking a patch release binding. Current plans are to implement this is ONNV, but since this is a fix for a standards violation, we will have to patch it back into earlier releases if customers complain about the current behavior. - Don Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI This information is Copyright 2005 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab 1.2. Name of Document Author/Supplier: Author: Carol Fields 1.3 Date of This Document: 11 November, 2005 4. Technical Description Summary This fasttrack proposes changing the behavior of 'crontab' in response to Bug ID 6344121. The fix will allow crontab to comply with POSIX.2-1992, SUS, SUSv2, SUSv3, and XPG4. Background IEEE Std 1003.1-2001 describes the following under 'crontab' (similar wording also appears in IEEE Std 1003.2-1992, XPG4, SUS, and SUSv2): "-e Edit a copy of the invoking user's crontab entry, or create an empty entry to edit if the crontab entry does not exist. When editing is complete, the entry shall be installed as the user's crontab entry. The following environment variables shall affect the execution of crontab: EDITOR Determine the editor to be invoked when the -e option is specified. The default editor shall be vi." /usr/bin/crontab invokes the editor specified by the environment variable VISUAL, if it is set. If VISUAL is not set, and EDITOR is set, crontab invokes the editor specified by EDITOR. If EDITOR not set, crontab invokes ed. This behavior complies with the Solaris man page, which states: "-e Edits a copy of the current user's crontab file, or creates an empty file to edit if crontab does not exist. When editing is complete, the file is installed as the user's crontab file. If a username is given, the specified user's crontab file is edited, rather than the current user's crontab file; this can only be done by a user with the solaris.jobs.admin authoriza- tion. The environment variable EDITOR determines which editor is invoked with the -e option. The default edi- tor is ed(1). EDITOR Determine the editor to be invoked when the -e option is specified. This is overriden by the VISUAL environ- mental variable. The default editor is ed(1). VISUAL Determine the visual editor to be invoked when the -e option is specified. If VISUAL is not specified, then the environment variable EDITOR is used. If that is not set, the default is ed(1)." Proposal:Description When commands conform to XPG4, they should execute in XPG4 mode, meaning that crontab should exec /usr/xpg4/bin/vi by default. When commands conform to XPG6, they should execute in XPG6 mode, meaning that crontab should exec /usr/xpg6/bin/vi by default. A new /usr/xpg4/bin/crontab and a new /usr/xpg6/bin/crontab will be created for this purpose. There is no mention of the environment variable VISUAL in SUSv3's description of crontab, therefore /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab will not check VISUAL. If EDITOR is not set in the environment, they will use vi. The behavior of /usr/bin/crontab will not be changed. The updated 'crontab' man page is included in the case's materials directory. Exported Interfaces Interface Stability --------- --------- /usr/xpg4/bin/crontab Standard /usr/xpg6/bin/crontab Standard 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Fri Nov 11 14:03:18 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jABM3IIQ012986 for ; Fri, 11 Nov 2005 14:03:18 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IPT007018WSCG@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 11 Nov 2005 14:03:17 -0800 (PST) Received: from [129.146.108.83] (yoohoo.SFBay.Sun.COM [129.146.108.83]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IPT0016198J9F@mpk-mail1.sfbay.sun.com>; Fri, 11 Nov 2005 14:02:45 -0800 (PST) Date: Fri, 11 Nov 2005 14:02:43 -0800 From: Ed Gould Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <200511112108.jABL8qI8001205@spartan.SFBay.Sun.COM> To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Message-id: <43751503.3050305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) References: <200511112108.jABL8qI8001205@spartan.SFBay.Sun.COM> Status: RO Content-Length: 951 Don Cragun wrote: > Subject: PSARC FastTrack [11/18/2005]: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab A sub-nit (i.e., even less than a nit): Please use proper English quotation when writing English. English is not C; quotation marks in English are not necessarily balanced. Specifically, when quoting multiple paragraphs, it is proper to open the quoted material with a double-quote, open each new paragraph with a double-quote, and close the entire quoted passage with a double-quote. When typographically distinct open- and close-quotes are available (not in USASCII; grave accents and single quotes - while necessary for troff - are not paired quote marks), they should be used. More to the point of this fast-track, it was hard for me to determine which sections of text were quotes from man pages, and which were interfening parts of the fast-track. The additional open-quotes would have made this much easier. --Ed From sacadmin Fri Nov 11 15:04:37 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jABN4bIQ018088 for ; Fri, 11 Nov 2005 15:04:37 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IPT00701C0F2F@mpk-mail1.sfbay.sun.com> (original mail from Jordan.Brown@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 11 Nov 2005 15:04:36 -0800 (PST) Received: from [10.6.133.198] (ray-198.SFBay.Sun.COM [10.6.133.198]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IPT0087CC3O17@mpk-mail1.sfbay.sun.com>; Fri, 11 Nov 2005 15:04:36 -0800 (PST) Date: Fri, 11 Nov 2005 15:04:35 -0800 From: Jordan Brown Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <200511112108.jABL8qI8001205@spartan.SFBay.Sun.COM> To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Message-id: <43752383.9070305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr, ru User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 References: <200511112108.jABL8qI8001205@spartan.SFBay.Sun.COM> Status: RO Content-Length: 679 If I'm reading this right, the "violation" is that our crontab pays attention to $VISUAL, which is not specified by SUSv3. Right? Is it really a standards violation when a utility is affected by the setting of a non-standard environment variable? If so, how do we reconcile this with our handling of, e.g., all of our $LD_* environment variables? I would think that the moment that you set any non-standard environment variable, you've departed the bounds of the standard. (Granted, the environment variable namespace is an awfully murky one, with standard-defined names, platform-defined names, and user-defined names living indistinguishably in the same namespace.) From sacadmin Fri Nov 11 15:37:17 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jABNbGIQ020205 for ; Fri, 11 Nov 2005 15:37:17 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jABNbGJN001546; Fri, 11 Nov 2005 15:37:16 -0800 (PST) Message-Id: <200511112337.jABNbGJN001546@spartan.SFBay.Sun.COM> Date: Fri, 11 Nov 2005 15:37:16 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Jordan.Brown@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3dc13EV809MIyvexxn5icg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 2158 >Date: Fri, 11 Nov 2005 15:04:35 -0800 >From: Jordan Brown > >If I'm reading this right, the "violation" is that our crontab pays >attention to $VISUAL, which is not specified by SUSv3. Right? No. The violation is that the current default editor (if neither $VISUAL nor $EDITOR are present in the environment) is /usr/bin/ed. It should be /usr/xpg4/bin/vi if /usr/xpg4/bin is in $PATH before /usr/xpg6/bin and /usr/bin; and it should be /usr/xpg6/bin/vi if /usr/xpg6/bin is in $PATH before /usr/xpg4/bin and /usr/bin. (This is still a slight oversimplification of the rules, but it should be sufficient for what we're discussing here.) > >Is it really a standards violation when a utility is affected by the >setting of a non-standard environment variable? No. (And this is one reason we are not making any changes to /usr/bin/crontab.) In theory, we could also allow $VISUAL to affect /usr/xpg[46]/bin/crontab and still conform to the standards, but we haven't done that with the other utilities in /usr/xpg[46]/bin. Since these two directories are intended to provide POSIX.2-1992 and XCU4 (and their successors) conformance, we decided long ago not to provide attractive nuisances that would be likely to generate complaints from application writers who inherited a dirty environment that affects the way their applications behave. (We frequently provide compatible options that are extensions to the standards; but we believe that overriding environment variables cross the line.) > >If so, how do we reconcile this with our handling of, e.g., all of our >$LD_* environment variables? The LD_* variables are an exception because they affect ld.so.1 before we have determined what program we're loading. > >I would think that the moment that you set any non-standard environment >variable, you've departed the bounds of the standard. > >(Granted, the environment variable namespace is an awfully murky one, >with standard-defined names, platform-defined names, and user-defined >names living indistinguishably in the same namespace.) Indistinguishable is a little strong, but I agree with the concept. - Don From sacadmin Fri Nov 11 15:50:13 2005 Received: from phys-d3-ha21sca-2 (phys-d3-ha21sca-2.SFBay.Sun.COM [129.145.155.165]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jABNoDIQ021273 for ; Fri, 11 Nov 2005 15:50:13 -0800 (PST) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IPT00301E704N@ha21sca-mail1.sfbay.sun.com> (original mail from alan.coopersmith@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 11 Nov 2005 15:50:41 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IPT00HA5E8GZW@ha21sca-mail1.sfbay.sun.com>; Fri, 11 Nov 2005 15:50:41 -0800 (PST) Date: Fri, 11 Nov 2005 15:50:12 -0800 From: Alan Coopersmith Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <200511112337.jABNbGJN001546@spartan.SFBay.Sun.COM> To: Don Cragun Cc: Jordan.Brown@Sun.COM, PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Message-id: <43752E34.2020601@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050515) References: <200511112337.jABNbGJN001546@spartan.SFBay.Sun.COM> Status: RO Content-Length: 839 Don Cragun wrote: > No. The violation is that the current default editor (if neither > $VISUAL nor $EDITOR are present in the environment) is /usr/bin/ed. It > should be /usr/xpg4/bin/vi if /usr/xpg4/bin is in $PATH before > /usr/xpg6/bin and /usr/bin; and it should be /usr/xpg6/bin/vi if > /usr/xpg6/bin is in $PATH before /usr/xpg4/bin and /usr/bin. (This is > still a slight oversimplification of the rules, but it should be > sufficient for what we're discussing here.) I don't suppose changing the default editor to /usr/bin/vi in /usr/bin/crontab is part of the plan? That's a seriously annoying default, and I seem to remember was a call generator back when I worked in tech support in the Solaris 2.4 days. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Fri Nov 11 16:01:16 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAC01GIQ022270 for ; Fri, 11 Nov 2005 16:01:16 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAC01GJN001711; Fri, 11 Nov 2005 16:01:16 -0800 (PST) Message-Id: <200511120001.jAC01GJN001711@spartan.SFBay.Sun.COM> Date: Fri, 11 Nov 2005 16:01:16 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: alan.coopersmith@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zliHO56hMKA7WZDlVytVjA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 925 >Date: Fri, 11 Nov 2005 15:50:12 -0800 >From: Alan Coopersmith > >Don Cragun wrote: >> No. The violation is that the current default editor (if neither >> $VISUAL nor $EDITOR are present in the environment) is /usr/bin/ed. It >> should be /usr/xpg4/bin/vi if /usr/xpg4/bin is in $PATH before >> /usr/xpg6/bin and /usr/bin; and it should be /usr/xpg6/bin/vi if >> /usr/xpg6/bin is in $PATH before /usr/xpg4/bin and /usr/bin. (This is >> still a slight oversimplification of the rules, but it should be >> sufficient for what we're discussing here.) > >I don't suppose changing the default editor to /usr/bin/vi in /usr/bin/crontab >is part of the plan? That's a seriously annoying default, and I seem to >remember was a call generator back when I worked in tech support in the Solaris >2.4 days. No. This case is strictly about fixing a standards conformance problem. - Don ... ... ... From sacadmin Fri Nov 11 16:44:46 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAC0ikIQ023924 for ; Fri, 11 Nov 2005 16:44:46 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IPT00I01GKDST@mpk-mail1.sfbay.sun.com> (original mail from Jordan.Brown@sun.com) for PSARC@sac.SFBay.sun.com; Fri, 11 Nov 2005 16:44:46 -0800 (PST) Received: from [10.6.133.198] (ray-198.SFBay.Sun.COM [10.6.133.198]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IPT00EPBGQ8DX@mpk-mail1.sfbay.sun.com>; Fri, 11 Nov 2005 16:44:33 -0800 (PST) Date: Fri, 11 Nov 2005 16:44:32 -0800 From: Jordan Brown Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <200511112337.jABNbGJN001546@spartan.SFBay.Sun.COM> To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Message-id: <43753AF0.3020508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr, ru User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 References: <200511112337.jABNbGJN001546@spartan.SFBay.Sun.COM> Status: RO Content-Length: 1754 Don Cragun wrote: > No. The violation is that the current default editor (if neither > $VISUAL nor $EDITOR are present in the environment) is /usr/bin/ed. Eww. Maybe it's time for Solaris to get into the 1980s and default to a "full screen" editor. I assume that merely changing the default to /usr/bin/vi would not be sufficient, because there are differences between /usr/bin/vi and /usr/xpg*/bin/vi, right? Could we change the default to be "the first vi on $PATH"? That would get you the xpg* versions if you had xpg* first on your $PATH, and normally the regular one otherwise. If you had some user directory before /usr/bin you might get some user-custom vi, but that could be viewed as a feature. Your other comment does stand, regardless: > In theory, we could also allow $VISUAL to affect > /usr/xpg[46]/bin/crontab and still conform to the standards, but we > haven't done that with the other utilities in /usr/xpg[46]/bin. Since > these two directories are intended to provide POSIX.2-1992 and XCU4 > (and their successors) conformance, we decided long ago not to provide > attractive nuisances that would be likely to generate complaints from > application writers who inherited a dirty environment that affects the > way their applications behave. (We frequently provide compatible > options that are extensions to the standards; but we believe that > overriding environment variables cross the line.) Hmm. Debatable whether the benefit of this purity exceeds the cost, but I'll leave that up to the ARC. I'm not particularly emotional on this subject, just trying to help ensure that we don't fork off separate versions unnecessarily. I don't think I have anything more to say on the subject, so I'll shut up now. From sacadmin Fri Nov 11 17:06:34 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAC16XIQ025132 for ; Fri, 11 Nov 2005 17:06:33 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAC16XJN001958; Fri, 11 Nov 2005 17:06:33 -0800 (PST) Message-Id: <200511120106.jAC16XJN001958@spartan.SFBay.Sun.COM> Date: Fri, 11 Nov 2005 17:06:33 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Jordan.Brown@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: N2JG5Uz/DgnMjKq0rhPgLg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 1340 >Date: Fri, 11 Nov 2005 16:44:32 -0800 >From: Jordan Brown > >Don Cragun wrote: >> No. The violation is that the current default editor (if neither >> $VISUAL nor $EDITOR are present in the environment) is /usr/bin/ed. > >Eww. Maybe it's time for Solaris to get into the 1980s and default to a > "full screen" editor. I don't disagree. ;-} That just isn't this case. ;-{ > I assume that merely changing the default to >/usr/bin/vi would not be sufficient, because there are differences >between /usr/bin/vi and /usr/xpg*/bin/vi, right? /usr/bin/vi, /usr/xpg4/bin/vi, and /usr/xpg6/bin/vi are all different. Most of the differences are minor, but for standards conformance those little differences matter. /usr/ucb/vi's differences from all of the above are more significant. > >Could we change the default to be "the first vi on $PATH"? Not if the intent is to make /usr/bin/crontab conform to all of the standards. > >That would get you the xpg* versions if you had xpg* first on your >$PATH, and normally the regular one otherwise. If you had some user >directory before /usr/bin you might get some user-custom vi, but that >could be viewed as a feature. Some people WOULD view this as a feature, but it doesn't conform to standards requirements. - Don ... ... ... From sacadmin Fri Nov 11 19:42:07 2005 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAC3g5IQ000114 for ; Fri, 11 Nov 2005 19:42:06 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAC3fhft002574; Fri, 11 Nov 2005 19:41:44 -0800 (PST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.4+Sun/8.13.4/Submit) id jAC3faZu002573; Fri, 11 Nov 2005 19:41:36 -0800 (PST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Don Cragun Cc: Jordan.Brown@sun.com, PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com In-Reply-To: <200511120106.jAC16XJN001958@spartan.SFBay.Sun.COM> References: <200511120106.jAC16XJN001958@spartan.SFBay.Sun.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1131766896.1318.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Fri, 11 Nov 2005 19:41:36 -0800 Status: RO Content-Length: 539 On Fri, 2005-11-11 at 17:06, Don Cragun wrote: > > > >Eww. Maybe it's time for Solaris to get into the 1980s and default to a > > "full screen" editor. > > I don't disagree. ;-} That just isn't this case. ;-{ It should be. we make our system incredibly more uneven when these "standards conformance" changes come along and improve the rarely-used /usr/xpgN/bin versions without also making comparable improvements to the versions in /usr/bin please change the /usr/bin/crontab default editor as part of this case. - Bill From sacadmin Sat Nov 12 10:39:56 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jACIdtIQ022587 for ; Sat, 12 Nov 2005 10:39:55 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jACIdqCM012362; Sat, 12 Nov 2005 19:39:52 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jACIdpDk002556; Sat, 12 Nov 2005 19:39:51 +0100 (MET) Message-Id: <200511121839.jACIdpDk002556@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Jordan Brown cc: Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <43752383.9070305@sun.com> References: <200511112108.jABL8qI8001205@spartan.SFBay.Sun.COM> <43752383.9070305@sun.com> Date: Sat, 12 Nov 2005 19:39:49 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 912 >If I'm reading this right, the "violation" is that our crontab pays >attention to $VISUAL, which is not specified by SUSv3. Right? > >Is it really a standards violation when a utility is affected by the >setting of a non-standard environment variable? > >If so, how do we reconcile this with our handling of, e.g., all of our >$LD_* environment variables? > >I would think that the moment that you set any non-standard environment >variable, you've departed the bounds of the standard. > >(Granted, the environment variable namespace is an awfully murky one, >with standard-defined names, platform-defined names, and user-defined >names living indistinguishably in the same namespace.) I agree with this; I think that the xpg4 and xpg6 directories are ugly warts (and why doesn't xpg4/bin/awk use the POSIX shell for system()?) I'm sure some creative thinking can get rid of most of its use.. Casper From sacadmin Sat Nov 12 11:10:53 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jACJArIQ016456 for ; Sat, 12 Nov 2005 11:10:53 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jACJAmTM362491; Sat, 12 Nov 2005 11:10:52 -0800 (PST) Message-Id: <200511121910.jACJAmTM362491@jurassic.eng.sun.com> Date: Sat, 12 Nov 2005 09:10:28 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Jordan.Brown@sun.com, Casper.Dik@sun.com Cc: Don.Cragun@sun.com, PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7zxCbG7jOZFbkTA513IWuA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1510 > From: Casper.Dik@sun.com ... > I agree with this; I think that the xpg4 and xpg6 directories are > ugly warts (and why doesn't xpg4/bin/awk use the POSIX shell for > system()?) > > I'm sure some creative thinking can get rid of most of its use.. I'm listening.... If we knew in 1990 what xpg4/xpg6/SUSv3 were to say in 2005, we could have avoided these directories. The contents contained within are components where the standard dictated behavior differs from the Stable SunOS behavior. Anything that doesn't fit this bill (other than a few enviroment identification utilities) is a bug. I don't know of any such bugs. Some people assert it is a bug that we've maintained the SunOS Stability here, rather than just tracking these standards in the base as many of our competitors have (think ksh here). Anyone wanting to fight that battle is welcome to - I don't have the energy for it. Besides, while I think we might be allowed to switch which environment was the default, I think we would be stuck maintaining all the environments (or at least two). We chose to use $PATH to implement these alternate execution environments. There are a multitude of other twisty little passages we could of used to implement this, but as we know about "twisty little passages", "they are all alike". The parenthetical remark above sounds like a bug. Is a CR filed? Anyway, we seem to be straying very far from the proposal. If this isn't the droid you are looking for, please file your own droid. - jek3 From sacadmin Mon Nov 14 03:54:36 2005 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAEBsZIQ009785 for ; Mon, 14 Nov 2005 03:54:35 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAEBsWgG007193; Mon, 14 Nov 2005 11:54:32 GMT Received: from 129.156.173.199 (estale [129.156.173.199]) by enospc.uk.sun.com (8.13.3+Sun/8.13.3/CTE 3.0) with ESMTP id jAEBsWhn005281; Mon, 14 Nov 2005 11:54:32 GMT Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Darren J Moffat To: Don Cragun Cc: Jordan.Brown@Sun.COM, PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM In-Reply-To: <200511112337.jABNbGJN001546@spartan.SFBay.Sun.COM> References: <200511112337.jABNbGJN001546@spartan.SFBay.Sun.COM> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1131969271.344710.0.camel@estale> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 14 Nov 2005 11:54:31 +0000 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 162 I couldn't understand from the case materials why we need xpg4 and xpg6 variants to fix this issue, why can't we just fix /usr/bin/crontab ? -- Darren J Moffat From sacadmin Mon Nov 14 17:19:36 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF1JQIQ029016 for ; Mon, 14 Nov 2005 17:19:36 -0800 (PST) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id jAF1JMJM006810; Mon, 14 Nov 2005 17:19:22 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10/Submit) id jAF1JMxC006809; Mon, 14 Nov 2005 17:19:22 -0800 (PST) Date: Mon, 14 Nov 2005 17:19:22 -0800 (PST) Message-Id: <200511150119.jAF1JMxC006809@spartan.SFBay.Sun.COM> From: Don Cragun To: Darren.Moffat@sun.com Cc: Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] Status: RO Content-Length: 1372 >Date: Mon, 14 Nov 2005 11:54:31 +0000 >From: Darren J Moffat > >I couldn't understand from the case materials why we need >xpg4 and xpg6 variants to fix this issue, why can't we just >fix /usr/bin/crontab ? This case merely proposes implementing the behavior documented on our standards(5) man page: "Utilities If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 conflicts with historical Solaris utility behavior, the original Solaris version of the utility is unchanged; a new version that is standard-conforming has been provided in /usr/xpg4/bin. If the behavior required by POSIX.1-2001 or SUSv3 conflicts with historical Solaris utility behavior, a new version that is standard-conforming has been provided in /usr/xpg4/bin or in /usr/xpg6/bin. If the behavior required by POSIX.1-2001 or SUSv3 conflicts with POSIX.2, POSIX.2a, SUS, or SUSv2, a new version that is SUSv3 standard- conforming has been provided in /usr/xpg6/bin." Back in SunOS 4.x we had some utilities that changed behavior based on the setting of $PATH. Providing separate versions in /usr/bin, /usr/xpg4/bin, and /usr/xpg6/bin provides the most flexibility for applications running in one standards conforming environment that want to invoke a utility conforming to a different standard. - Don > >-- >Darren J Moffat From sacadmin Mon Nov 14 17:45:41 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF1jfIQ000604 for ; Mon, 14 Nov 2005 17:45:41 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAF1jYWa019789; Mon, 14 Nov 2005 20:45:34 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAF1jYGQ003111; Mon, 14 Nov 2005 20:45:34 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Don Cragun Cc: Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511150119.jAF1JMxC006809@spartan.SFBay.Sun.COM> References: <200511150119.jAF1JMxC006809@spartan.SFBay.Sun.COM> Content-Type: text/plain Message-Id: <1132019133.148.707.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Mon, 14 Nov 2005 20:45:34 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 554 On Mon, 2005-11-14 at 20:19, Don Cragun wrote: > This case merely proposes implementing the behavior documented > on our standards(5) man page: > "Utilities > If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or > SUSv2 conflicts with historical Solaris utility behavior, > the original Solaris version of the utility is unchanged; this seems to me to be an overly restrictive interpretation of "conflicts". when the standard proposes an improvement and the change is reasonable we should run with it where possible. - Bill From sacadmin Mon Nov 14 18:36:05 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.130]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2a5IQ001756 for ; Mon, 14 Nov 2005 18:36:05 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF2a0eo159883; Mon, 14 Nov 2005 18:36:04 -0800 (PST) Message-Id: <200511150236.jAF2a0eo159883@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 16:35:35 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Don.Cragun@sun.com, sommerfeld@sun.com Cc: Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vcvv0WMf8VC6GxRaPTMZeA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1011 > On Mon, 2005-11-14 at 20:19, Don Cragun wrote: > > > This case merely proposes implementing the behavior documented > > on our standards(5) man page: > > "Utilities > > If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or > > SUSv2 conflicts with historical Solaris utility behavior, > > the original Solaris version of the utility is unchanged; > > this seems to me to be an overly restrictive interpretation of > "conflicts". > > when the standard proposes an improvement and the change is reasonable > we should run with it where possible. > > - Bill > If "when possible" == "doesn't conflict with our stable definition", then please hit delete now. We are all in agreement (I believe). For 15 years we've run with the model that the Stable meaning we've given utilities trumps what a standards body might decide. I can understand suggesting a different model and running it up through TAC (yea, TAC), but let's not try to do that in the context of a fast-track. - jek3 From sacadmin Mon Nov 14 18:40:15 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2eFIQ002466 for ; Mon, 14 Nov 2005 18:40:15 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAF2eBWa001466; Mon, 14 Nov 2005 21:40:11 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAF2eBnk003235; Mon, 14 Nov 2005 21:40:11 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Joseph Kowalski Cc: Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511150236.jAF2a0eo159883@jurassic.eng.sun.com> References: <200511150236.jAF2a0eo159883@jurassic.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1132022410.148.767.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Mon, 14 Nov 2005 21:40:11 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 262 On Mon, 2005-11-14 at 21:35, Joseph Kowalski wrote: > If "when possible" == "doesn't conflict with our stable definition", > then please hit delete now. We are all in agreement (I believe). crontab(1) has a documented stability level of Standard, not Stable From sacadmin Mon Nov 14 18:50:16 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2oGIQ002598 for ; Mon, 14 Nov 2005 18:50:16 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAF2oCH0014415; Mon, 14 Nov 2005 21:50:12 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAF2oCnw003260; Mon, 14 Nov 2005 21:50:12 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Joseph Kowalski Cc: Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <1132022410.148.767.camel@thunk> References: <200511150236.jAF2a0eo159883@jurassic.eng.sun.com> <1132022410.148.767.camel@thunk> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1132023011.148.779.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Mon, 14 Nov 2005 21:50:11 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 780 On Mon, 2005-11-14 at 21:40, Bill Sommerfeld wrote: > On Mon, 2005-11-14 at 21:35, Joseph Kowalski wrote: > > If "when possible" == "doesn't conflict with our stable definition", > > then please hit delete now. We are all in agreement (I believe). > > crontab(1) has a documented stability level of Standard, not Stable .. what's more, the crontab(1) man page is self-inconsistent, stating elsewhere: EDITOR Determine the editor to be invoked when the -e option is specified. The default editor is vi(1). (I checked as far back as 5.9. if it's been that way for at least 5 years and nobody's noticed and filed a man page bug about the inconsistency, that's evidence that the default editor used by crontab is not an Interface). - Bill From sacadmin Mon Nov 14 18:52:02 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2q2IQ002643 for ; Mon, 14 Nov 2005 18:52:02 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF2pvfx164895; Mon, 14 Nov 2005 18:52:01 -0800 (PST) Message-Id: <200511150252.jAF2pvfx164895@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 16:51:32 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iDAGgnx4QE/dJbh4KOmpbw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 573 > On Mon, 2005-11-14 at 21:35, Joseph Kowalski wrote: > > If "when possible" == "doesn't conflict with our stable definition", > > then please hit delete now. We are all in agreement (I believe). > > crontab(1) has a documented stability level of Standard, not Stable And this matters why? Standard does not allow us to track evolving standards. Are you asserting that this change is one of those "interpretation" things we have some slack on? In other words, our manpage is ambiguous enough on the topic to allow us significant latitude in interpretation? - jek3 From sacadmin Mon Nov 14 18:56:30 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2uTIQ003163 for ; Mon, 14 Nov 2005 18:56:29 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAF2uQWa005658; Mon, 14 Nov 2005 21:56:26 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAF2uP01003307; Mon, 14 Nov 2005 21:56:25 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Joseph Kowalski Cc: Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511150252.jAF2pvfx164895@jurassic.eng.sun.com> References: <200511150252.jAF2pvfx164895@jurassic.eng.sun.com> Content-Type: text/plain Message-Id: <1132023385.148.782.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Mon, 14 Nov 2005 21:56:25 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 299 On Mon, 2005-11-14 at 21:51, Joseph Kowalski wrote: > Are you asserting that this change is one of those "interpretation" > things we have some slack on? In other words, our manpage is ambiguous > enough on the topic to allow us significant latitude in interpretation? Among other things, yes. From sacadmin Mon Nov 14 18:57:09 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2v9IQ003180 for ; Mon, 14 Nov 2005 18:57:09 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF2v07U166029; Mon, 14 Nov 2005 18:57:04 -0800 (PST) Message-Id: <200511150257.jAF2v07U166029@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 16:56:35 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EQK0WqVXi9tlMH0ViOYGmQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 801 > .. what's more, the crontab(1) man page is self-inconsistent, stating > elsewhere: > > EDITOR > Determine the editor to be invoked when the -e option > is specified. The default editor is vi(1). > > (I checked as far back as 5.9. if it's been that way for at least 5 > years and nobody's noticed and filed a man page bug about the > inconsistency, that's evidence that the default editor used by crontab > is not an Interface). > > - Bill Ah! You are asserting that our man page is ambiguous enough,... yadda, yadda, yadda,... Actually, it specifies "vi(1)". That page specifies the 3x3 matrix of utilities with {vi,view,vedit} down one axis and {bin,xpg4/bin,xpg6/bin} down the other. True, crontab doesn't specify which of these. Go with it. - jek3 From sacadmin Mon Nov 14 18:58:03 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2w3IQ003201 for ; Mon, 14 Nov 2005 18:58:03 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF2vv86166273; Mon, 14 Nov 2005 18:58:01 -0800 (PST) Message-Id: <200511150258.jAF2vv86166273@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 16:57:33 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: i2Bsa6YwNVLjRCyxKXb9Rw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 364 > On Mon, 2005-11-14 at 21:51, Joseph Kowalski wrote: > > Are you asserting that this change is one of those "interpretation" > > things we have some slack on? In other words, our manpage is ambiguous > > enough on the topic to allow us significant latitude in interpretation? > > Among other things, yes. Guessed that from your next message.... 8^) - jek3 From sacadmin Mon Nov 14 18:59:17 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF2xHIQ003238 for ; Mon, 14 Nov 2005 18:59:17 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IPZ006016L83Z@mpk-mail1.sfbay.sun.com> (original mail from Jordan.Brown@sun.com) for PSARC@sac.sfbay.sun.com; Mon, 14 Nov 2005 18:59:17 -0800 (PST) Received: from [10.6.133.198] (ray-198.SFBay.Sun.COM [10.6.133.198]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IPZ0064L6YSWX@mpk-mail1.sfbay.sun.com>; Mon, 14 Nov 2005 18:59:17 -0800 (PST) Date: Mon, 14 Nov 2005 18:59:16 -0800 From: Jordan Brown Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <1132023385.148.782.camel@thunk> To: Bill Sommerfeld Cc: Joseph Kowalski , Don.Cragun@Sun.COM, Darren.Moffat@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Message-id: <43794F04.7050907@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr, ru User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 References: <200511150252.jAF2pvfx164895@jurassic.eng.sun.com> <1132023385.148.782.camel@thunk> Status: RO Content-Length: 597 Bill Sommerfeld wrote: > On Mon, 2005-11-14 at 21:51, Joseph Kowalski wrote: > >>Are you asserting that this change is one of those "interpretation" >>things we have some slack on? In other words, our manpage is ambiguous >>enough on the topic to allow us significant latitude in interpretation? > > > Among other things, yes. With respect to changing the default from "ed" to "vi", one might also mention "not being hopelessly mired in the 1970s". I think you'd be pretty hard-pressed to find any user in the world who would say that using "ed" as the default is the right thing to do. From sacadmin Mon Nov 14 19:06:42 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF36gIQ003498 for ; Mon, 14 Nov 2005 19:06:42 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IPZ0090170RDD@mpk-mail1.sfbay.sun.com> (original mail from Jordan.Brown@sun.com) for PSARC@sac.sfbay.sun.com; Mon, 14 Nov 2005 19:06:42 -0800 (PST) Received: from [10.6.133.198] (ray-198.SFBay.Sun.COM [10.6.133.198]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IPZ006EM7B5WX@mpk-mail1.sfbay.sun.com>; Mon, 14 Nov 2005 19:06:41 -0800 (PST) Date: Mon, 14 Nov 2005 19:06:41 -0800 From: Jordan Brown Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <43794F04.7050907@sun.com> To: Jordan Brown Cc: Bill Sommerfeld , Joseph Kowalski , Don.Cragun@Sun.COM, Darren.Moffat@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Message-id: <437950C1.4050303@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr, ru User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 References: <200511150252.jAF2pvfx164895@jurassic.eng.sun.com> <1132023385.148.782.camel@thunk> <43794F04.7050907@sun.com> Status: RO Content-Length: 588 Jordan Brown wrote: > With respect to changing the default from "ed" to "vi", one might also > mention "not being hopelessly mired in the 1970s". I think you'd be > pretty hard-pressed to find any user in the world who would say that > using "ed" as the default is the right thing to do. Sigh. Having said that, it occurs to me that one might semi-reasonably write a shell script around "crontab -e" using ed. I wouldn't personally do it that way, but it wouldn't be silly. I'd probably still do it, but it wouldn't be patch-appropriate and it might merit a "What's new" note. From sacadmin Mon Nov 14 19:11:16 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF3BGIQ003807 for ; Mon, 14 Nov 2005 19:11:16 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF3BApA170626; Mon, 14 Nov 2005 19:11:14 -0800 (PST) Message-Id: <200511150311.jAF3BApA170626@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 17:10:46 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: sommerfeld@sun.com, Jordan.Brown@sun.com Cc: Joseph.Kowalski@sun.com, Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: OhuigbPrtTuqdVV09fyuoQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1304 > From: Jordan Brown ... > Bill Sommerfeld wrote: > > On Mon, 2005-11-14 at 21:51, Joseph Kowalski wrote: > > > >>Are you asserting that this change is one of those "interpretation" > >>things we have some slack on? In other words, our manpage is ambiguous > >>enough on the topic to allow us significant latitude in interpretation? > > > > > > Among other things, yes. > > With respect to changing the default from "ed" to "vi", one might also > mention "not being hopelessly mired in the 1970s". I think you'd be > pretty hard-pressed to find any user in the world who would say that > using "ed" as the default is the right thing to do. Well, this is a different thing. It's "expected change". We had a long discussion of this in the context of incompatibly modifying pcfs to track the long, case sensitive names in Windows 98. The world would think us daft if we didn't evolve. Maybe they think us daft for using ed. Maybe they just think us daft, period. 8^) Go with it also, but recognize it as something different. Note: I personally don't care much about these details, so I'm not trying to assert much about what is the "right thing" to do. I just thought I saw this case spiralling out of control, but it seems I was wrong about that. Opps. - jek3 From sacadmin Mon Nov 14 19:11:45 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF3BjIQ003818 for ; Mon, 14 Nov 2005 19:11:45 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAF3BgWa009411; Mon, 14 Nov 2005 22:11:42 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAF3BgPR003354; Mon, 14 Nov 2005 22:11:42 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Jordan Brown Cc: Joseph Kowalski , Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <437950C1.4050303@sun.com> References: <200511150252.jAF2pvfx164895@jurassic.eng.sun.com> <1132023385.148.782.camel@thunk> <43794F04.7050907@sun.com> <437950C1.4050303@sun.com> Content-Type: text/plain Message-Id: <1132024301.148.794.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Mon, 14 Nov 2005 22:11:42 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 483 On Mon, 2005-11-14 at 22:06, Jordan Brown wrote: > I'd probably still do it, but it wouldn't be patch-appropriate and it > might merit a "What's new" note. Perhaps. But that view would also make the original proposal (adding /usr/xpgN/bin/crontab) not patch-appropriate, either. I'd argue that a robust script using crontab -e would set EDITOR first given the confusion in the man page and the fact that a bunch of relevant standards say the default editor is vi. - Bill From sacadmin Mon Nov 14 19:14:13 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF3EDIQ003898 for ; Mon, 14 Nov 2005 19:14:13 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF3E8Qs171449; Mon, 14 Nov 2005 19:14:12 -0800 (PST) Message-Id: <200511150314.jAF3E8Qs171449@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 17:13:44 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Jordan.Brown@sun.com Cc: sommerfeld@sun.com, Joseph.Kowalski@sun.com, Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: c4Pd/PuQoPaf+dxFL0Adig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 475 > From: Jordan Brown ... > I'd probably still do it, but it wouldn't be patch-appropriate and it > might merit a "What's new" note. OK, a minor technical opinion (assuming the change is viable for other reasons). Minor release binding (I really have a hard line for patch binding) Release note? Nah. Its noise. Our release notes are so long, its not clear anybody reads them any more. Let's reserve them for the truly important. - jek3 From sacadmin Mon Nov 14 19:22:12 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF3MCIQ004081 for ; Mon, 14 Nov 2005 19:22:12 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAF3M8Te005007 for ; Mon, 14 Nov 2005 19:22:08 -0800 (PST) Received: from d1-sfbay-01.sun.com ([192.18.39.111]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id jAF3M3Vs007847 for ; Mon, 14 Nov 2005 19:22:03 -0800 (PST) Received: from conversion-daemon.d1-sfbay-01.sun.com by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IPZ00801389NT00@d1-sfbay-01.sun.com> (original mail from Mike.Oliver@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 14 Nov 2005 19:22:02 -0800 (PST) Received: from [10.6.102.113] by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IPZ0085980P3340@d1-sfbay-01.sun.com>; Mon, 14 Nov 2005 19:22:01 -0800 (PST) Date: Mon, 14 Nov 2005 19:22:01 -0800 From: Mike Oliver Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <200511150257.jAF2v07U166029@jurassic.eng.sun.com> Sender: Mike.Oliver@Sun.COM To: Joseph Kowalski Cc: sommerfeld@Sun.COM, Don.Cragun@Sun.COM, Darren.Moffat@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Reply-to: Mike.Oliver@Sun.COM Message-id: <43795459.7050504@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200511150257.jAF2v07U166029@jurassic.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 1675 Joseph Kowalski wrote: >Bill Sommerfeld wrote: >>.. what's more, the crontab(1) man page is self-inconsistent, stating >>elsewhere: >> >> EDITOR >> Determine the editor to be invoked when the -e option >> is specified. The default editor is vi(1). >> >>(I checked as far back as 5.9. if it's been that way for at least 5 >>years and nobody's noticed and filed a man page bug about the >>inconsistency, that's evidence that the default editor used by crontab >>is not an Interface). Maybe it's just evidence that people are so used to buggy manpages that they don't bother to file bugs against them. Although in this case someone did care enough to report this bug, see CR 6306391. > Ah! You are asserting that our man page is ambiguous enough,... yadda, yadda, > yadda,... I don't know about ambiguous but that man page is certainly wrong, where "wrong" is defined as "disagrees with the implementation". 'crontab -e' (tested on S10) behaves as specified in the Sol 7 manpage. That is, it uses VISUAL if set, else EDITOR if set, else 'ed'. The code is quite straightforward: editor = getenv("VISUAL"); if (editor == NULL) editor = getenv("EDITOR"); if (editor == NULL) editor = "ed"; That code is unchanged from as far back as I care to look in /ws/on* all the way up through onnv. > Actually, it specifies "vi(1)". That page specifies the 3x3 matrix of > utilities with {vi,view,vedit} down one axis and {bin,xpg4/bin,xpg6/bin} > down the other. True, crontab doesn't specify which of these. It does 'system("ed ...")', so whichever appears first on your $PATH. Mike. -- mike.oliver@sun.com From sacadmin Mon Nov 14 19:22:24 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF3MOIQ004097 for ; Mon, 14 Nov 2005 19:22:24 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF3MJwQ173256; Mon, 14 Nov 2005 19:22:23 -0800 (PST) Message-Id: <200511150322.jAF3MJwQ173256@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 17:21:55 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Jordan.Brown@sun.com, sommerfeld@sun.com Cc: Joseph.Kowalski@sun.com, Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ke7QIYZK1iMrN1Xcxp60Lg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 979 > Perhaps. But that view would also make the original proposal (adding > /usr/xpgN/bin/crontab) not patch-appropriate, either. Because it might break someone with xpg4/bin before bin in their path? I don't think that flies, because this potentially incompatable change is bringing us into conformance with the specification (xpg4). Hummm,... I think we had this discussion many moons ago in some context and decided that by puttig xpg4 into your path, you bought into this sorta thing. I could be wrong. The memory is faint. > I'd argue that a robust script using crontab -e would set EDITOR first > given the confusion in the man page and the fact that a bunch of > relevant standards say the default editor is vi. Well sure. Who needs to worry about the robust scripts? Its the unwashed masses... 8^) I'm going to bow out of this (as its triggered my personal cost/benefit alarm), but don't take that as a condemnation of additional discussion by others. - jek3 From sacadmin Mon Nov 14 19:26:23 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF3QNIQ004204 for ; Mon, 14 Nov 2005 19:26:23 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAF3QFUT175119; Mon, 14 Nov 2005 19:26:19 -0800 (PST) Message-Id: <200511150326.jAF3QFUT175119@jurassic.eng.sun.com> Date: Mon, 14 Nov 2005 17:25:51 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, Mike.Oliver@sun.com Cc: sommerfeld@sun.com, Don.Cragun@sun.com, Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mOOQCNOODt3PUkVJHcNpaQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 403 > From: Mike Oliver .. > I don't know about ambiguous but that man page is certainly wrong, > where "wrong" is defined as "disagrees with the implementation". Well, that means one or the other is wrong, but really doesn't indicate which. Of course, I've never seen an application broken because we brought the man page into conformance with the implementation.... 8^) - jek3 From sacadmin Tue Nov 15 01:32:50 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAF9WnIQ016440 for ; Tue, 15 Nov 2005 01:32:49 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAF9WhCM027511; Tue, 15 Nov 2005 10:32:43 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAF9WgDk023705; Tue, 15 Nov 2005 10:32:42 +0100 (MET) Message-Id: <200511150932.jAF9WgDk023705@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Jordan Brown cc: Bill Sommerfeld , Joseph Kowalski , Don.Cragun@Sun.COM, Darren.Moffat@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <437950C1.4050303@sun.com> References: <200511150252.jAF2pvfx164895@jurassic.eng.sun.com> <1132023385.148.782.camel@thunk> <43794F04.7050907@sun.com> <437950C1.4050303@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Nov 2005 10:32:40 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 647 >Jordan Brown wrote: >> With respect to changing the default from "ed" to "vi", one might also >> mention "not being hopelessly mired in the 1970s". I think you'd be >> pretty hard-pressed to find any user in the world who would say that >> using "ed" as the default is the right thing to do. > >Sigh. Having said that, it occurs to me that one might semi-reasonably >write a shell script around "crontab -e" using ed. I wouldn't >personally do it that way, but it wouldn't be silly. Generally, you would set $EDITOR for that (I remember doing something similar for "edquota"; the $EDITOR was a script which did the editing). Casper From sacadmin Tue Nov 15 03:15:37 2005 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFBFaIQ020766 for ; Tue, 15 Nov 2005 03:15:37 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAFBFYgG011895; Tue, 15 Nov 2005 11:15:34 GMT Received: from 129.156.173.199 (estale [129.156.173.199]) by enospc.uk.sun.com (8.13.3+Sun/8.13.3/CTE 3.0) with ESMTP id jAFBFXcL002941; Tue, 15 Nov 2005 11:15:33 GMT Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Darren J Moffat To: Don Cragun Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com In-Reply-To: <200511150119.jAF1JMxC006809@spartan.SFBay.Sun.COM> References: <200511150119.jAF1JMxC006809@spartan.SFBay.Sun.COM> Content-Type: text/plain; charset=iso-8859-15 Organization: Sun Microsystems, Inc. Message-Id: <1132053332.615093.108.camel@estale> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 15 Nov 2005 11:15:33 +0000 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1972 On Tue, 2005-11-15 at 01:19, Don Cragun wrote: > >Date: Mon, 14 Nov 2005 11:54:31 +0000 > >From: Darren J Moffat > > > >I couldn't understand from the case materials why we need > >xpg4 and xpg6 variants to fix this issue, why can't we just > >fix /usr/bin/crontab ? > > This case merely proposes implementing the behavior documented > on our standards(5) man page: > "Utilities > If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or > SUSv2 conflicts with historical Solaris utility behavior, > the original Solaris version of the utility is unchanged; a > new version that is standard-conforming has been provided in > /usr/xpg4/bin. If the behavior required by POSIX.1-2001 or > SUSv3 conflicts with historical Solaris utility behavior, a > new version that is standard-conforming has been provided in > /usr/xpg4/bin or in /usr/xpg6/bin. If the behavior required > by POSIX.1-2001 or SUSv3 conflicts with POSIX.2, POSIX.2a, > SUS, or SUSv2, a new version that is SUSv3 standard- > conforming has been provided in /usr/xpg6/bin." > > Back in SunOS 4.x we had some utilities that changed behavior based on > the setting of $PATH. Providing separate versions in /usr/bin, > /usr/xpg4/bin, and /usr/xpg6/bin provides the most flexibility for > applications running in one standards conforming environment that want > to invoke a utility conforming to a different standard. That doesn't answer my question. Why is this change not appropriate for /usr/bin/crontab ? Why must we introduce /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab ? What is the incompatible change that would be made to /usr/bin/crontab that the project team believes is unacceptable for a Stable command in /usr/bin ? The reason I'm asking is I can't work it out from the materials nor can I work it out from the man page you quoted, ie specifically what is the incompatible change for /usr/bin/crontab ? -- Darren J Moffat From sacadmin Tue Nov 15 09:28:31 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFHSVIQ009942 for ; Tue, 15 Nov 2005 09:28:31 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAFHSVJN007914; Tue, 15 Nov 2005 09:28:31 -0800 (PST) Message-Id: <200511151728.jAFHSVJN007914@spartan.SFBay.Sun.COM> Date: Tue, 15 Nov 2005 09:28:31 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Jordan.Brown@Sun.COM, sommerfeld@Sun.COM, Joseph.Kowalski@eng.sun.com, Mike.Oliver@Sun.COM Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vt2rtvwFpKig+uZ0bolNFg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 3171 >Date: Mon, 14 Nov 2005 19:22:01 -0800 >From: Mike Oliver > >Joseph Kowalski wrote: > >Bill Sommerfeld wrote: >>>.. what's more, the crontab(1) man page is self-inconsistent, stating >>>elsewhere: >>> >>> EDITOR >>> Determine the editor to be invoked when the -e option >>> is specified. The default editor is vi(1). >>> >>>(I checked as far back as 5.9. if it's been that way for at least 5 >>>years and nobody's noticed and filed a man page bug about the >>>inconsistency, that's evidence that the default editor used by crontab >>>is not an Interface). > >Maybe it's just evidence that people are so used to buggy manpages that >they don't bother to file bugs against them. Although in this case >someone did care enough to report this bug, see CR 6306391. Mike, Jordan, Bill, and Joe, Bug ID 6306391 has been fixed in the ON10u1 documentation gate and in the ONNV documentation gate. And, the man page in the materials directory for this case includes those fixes as well as the updates noting the new, correct (according to the various standards) default if $VISUAL and $EDITOR are not set. The man page inconsistency was fixed three months ago. It should't be used as an argument now for why this case should not proceed. > >> Ah! You are asserting that our man page is ambiguous enough,... yadda, yadda, >> yadda,... > >I don't know about ambiguous but that man page is certainly wrong, >where "wrong" is defined as "disagrees with the implementation". >'crontab -e' (tested on S10) behaves as specified in the Sol 7 manpage. >That is, it uses VISUAL if set, else EDITOR if set, else 'ed'. The >code is quite straightforward: > > editor = getenv("VISUAL"); > if (editor == NULL) > editor = getenv("EDITOR"); > if (editor == NULL) > editor = "ed"; > >That code is unchanged from as far back as I care to look in /ws/on* >all the way up through onnv. > >> Actually, it specifies "vi(1)". That page specifies the 3x3 matrix of >> utilities with {vi,view,vedit} down one axis and {bin,xpg4/bin,xpg6/bin} >> down the other. True, crontab doesn't specify which of these. > >It does 'system("ed ...")', so whichever appears first on your $PATH. And we now know that this violates various standards. This case is about conforming to the behavior required by standards we have claimed to support since Solaris 2.5 while maintaining compatibility with the behavior that was present in SunOS 5.0 and UNIX System V Release 4. Furthermore, I stand by the patch release binding that has been requested for this case. As stated earlier, if a customer requests a patch to provide the standards-conforming behavior that we promised, we will need to issue patches to bring supported Solaris releases into conformance with the standards. If someone wants to request that the behavior of /usr/bin/crontab -e be changed to default to /usr/bin/vi rather than /usr/bin/ed, that is not this case. That change would clearly not be suitable for a patch release binding and, if a case is submitted, needs to be discussed on the its own merits. - Don > >Mike. >-- >mike.oliver@sun.com From sacadmin Tue Nov 15 09:30:08 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFHU8IQ009991 for ; Tue, 15 Nov 2005 09:30:08 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAFHU7JN007917; Tue, 15 Nov 2005 09:30:08 -0800 (PST) Message-Id: <200511151730.jAFHU7JN007917@spartan.SFBay.Sun.COM> Date: Tue, 15 Nov 2005 09:30:08 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Darren.Moffat@Sun.COM Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8yvt1JmAZ5bO0ugKUpCCtw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 3286 >From: Darren J Moffat >To: Don Cragun >Cc: Carol.Fields@sun.com, PSARC@sac.SFBay.Sun.COM >Date: Tue, 15 Nov 2005 11:15:33 +0000 > >On Tue, 2005-11-15 at 01:19, Don Cragun wrote: >> >Date: Mon, 14 Nov 2005 11:54:31 +0000 >> >From: Darren J Moffat >> > >> >I couldn't understand from the case materials why we need >> >xpg4 and xpg6 variants to fix this issue, why can't we just >> >fix /usr/bin/crontab ? >> >> This case merely proposes implementing the behavior documented >> on our standards(5) man page: >> "Utilities >> If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or >> SUSv2 conflicts with historical Solaris utility behavior, >> the original Solaris version of the utility is unchanged; a >> new version that is standard-conforming has been provided in >> /usr/xpg4/bin. If the behavior required by POSIX.1-2001 or >> SUSv3 conflicts with historical Solaris utility behavior, a >> new version that is standard-conforming has been provided in >> /usr/xpg4/bin or in /usr/xpg6/bin. If the behavior required >> by POSIX.1-2001 or SUSv3 conflicts with POSIX.2, POSIX.2a, >> SUS, or SUSv2, a new version that is SUSv3 standard- >> conforming has been provided in /usr/xpg6/bin." >> >> Back in SunOS 4.x we had some utilities that changed behavior based on >> the setting of $PATH. Providing separate versions in /usr/bin, >> /usr/xpg4/bin, and /usr/xpg6/bin provides the most flexibility for >> applications running in one standards conforming environment that want >> to invoke a utility conforming to a different standard. > >That doesn't answer my question. Why is this change not appropriate >for /usr/bin/crontab ? Why must we introduce /usr/xpg4/bin/crontab >and /usr/xpg6/bin/crontab ? What is the incompatible change that >would be made to /usr/bin/crontab that the project team believes >is unacceptable for a Stable command in /usr/bin ? > >The reason I'm asking is I can't work it out from the materials >nor can I work it out from the man page you quoted, ie specifically >what is the incompatible change for /usr/bin/crontab ? The incompatible change is what editor is invoked in response to commands of the form: crontab -e [username] If neither $EDITOR nor $VISUAL are set, /usr/bin/crontab has historically and is intended to continue to invoke /usr/bin/ed on the appropriate user's crontab file when the -e option is specified. POSIX.2-1992, XPG4, SUSv1, and SUSv2 require that the crontab utility invoke a POSIX.2-, XPG4-, SUSv1-, and SUSv2-conforming vi in this case. And, SUSv3 requires that the crontab utility invoke an SUSv3-conforming vi in this case. /usr/bin/ed, /usr/xpg4/bin/vi, and /usr/xpg6/bin/vi are all different. Saying that /usr/bin/crontab should choose one of these and ignore the others is saying that we should break 2 out of the 4 (or more) conforming utilities' environments we provide. If you're suggesting that /usr/bin/crontab -e should key off of $PATH to determine which editor to invoke, it violates the principle from the standards(5) man page quoted above and makes it harder for Solaris application writers to understand how our conforming utilities environments work. - Don > >-- >Darren J Moffat > From sacadmin Tue Nov 15 10:22:17 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFIMGIQ021545 for ; Tue, 15 Nov 2005 10:22:17 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAFIM9Wa001894; Tue, 15 Nov 2005 13:22:09 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAFIM9j2003103; Tue, 15 Nov 2005 13:22:09 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Don Cragun Cc: Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511151730.jAFHU7JN007917@spartan.SFBay.Sun.COM> References: <200511151730.jAFHU7JN007917@spartan.SFBay.Sun.COM> Content-Type: text/plain Message-Id: <1132078928.3069.6.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 15 Nov 2005 13:22:09 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 917 On Tue, 2005-11-15 at 12:30, Don Cragun wrote: > If neither $EDITOR nor $VISUAL are set, /usr/bin/crontab has > historically and is intended to continue to invoke /usr/bin/ed on the > appropriate user's crontab file when the -e option is specified. I believe it is inappropriate to add new /usr/xpgN/bin/* commands without taking a close look at whether it's appropriate to add the standards-required behaivor to the /usr/bin version. Historically we have not done a very careful job of this, and this leads to many percieved annoyances when there is no evidence that the existing behavior is either well-considered or required by a competing standard.. It's clearly appropriate to change the default editor for /usr/bin/crontab and changing the default editor in the XPG4 and XPG6 environments without also changing it in the default environment introduces an unreasonable variance in behavior. - Bill From sacadmin Tue Nov 15 10:41:02 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFIf1IQ025825 for ; Tue, 15 Nov 2005 10:41:01 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAFIf1JN008100; Tue, 15 Nov 2005 10:41:01 -0800 (PST) Message-Id: <200511151841.jAFIf1JN008100@spartan.SFBay.Sun.COM> Date: Tue, 15 Nov 2005 10:41:01 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: sommerfeld@Sun.COM Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MHpadJEVqRuQVWNf//+CCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 1808 >Date: Tue, 15 Nov 2005 13:22:09 -0500 >From: Bill Sommerfeld > >On Tue, 2005-11-15 at 12:30, Don Cragun wrote: >> If neither $EDITOR nor $VISUAL are set, /usr/bin/crontab has >> historically and is intended to continue to invoke /usr/bin/ed on the >> appropriate user's crontab file when the -e option is specified. > >I believe it is inappropriate to add new /usr/xpgN/bin/* commands >without taking a close look at whether it's appropriate to add the >standards-required behaivor to the /usr/bin version. OK. Let's look at it. > >Historically we have not done a very careful job of this, and this leads >to many percieved annoyances when there is no evidence that the existing >behavior is either well-considered or required by a competing standard.. I disagree. > >It's clearly appropriate to change the default editor for >/usr/bin/crontab and changing the default editor in the XPG4 and XPG6 >environments without also changing it in the default environment >introduces an unreasonable variance in behavior. No. As has already been pointed out, changing from /usr/bin/ed as the default for /usr/bin/crontab to vi may break existing applications that depend on the current, documented behavior. The fact that a bug report was recently filed and fixed to make the documentation match the implementation is further indication that someone cares about the current behavior. Having /usr/bin/crontab change in this way cannot be done in a patch. Adding /usr/xpg[46]/bin/crontab will have to be done in a patch if we get a customer complaint about standards non-compliance. Changing the behavior of /usr/bin/crontab to switch from ed to vi is a completely orthogonal issue to adding /usr/xpg[46]/bin/crontab to meet standards conformance requirements. - Don > > - Bill From sacadmin Tue Nov 15 11:04:50 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFJ4nIQ027439 for ; Tue, 15 Nov 2005 11:04:49 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAFJ4lH0000376; Tue, 15 Nov 2005 14:04:47 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAFJ4l1J003200; Tue, 15 Nov 2005 14:04:47 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Don Cragun Cc: Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511151841.jAFIf1JN008100@spartan.SFBay.Sun.COM> References: <200511151841.jAFIf1JN008100@spartan.SFBay.Sun.COM> Content-Type: text/plain Message-Id: <1132081487.3069.8.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 15 Nov 2005 14:04:47 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 271 On Tue, 2005-11-15 at 13:41, Don Cragun wrote: > Changing the behavior of /usr/bin/crontab to switch from ed to vi is a > completely orthogonal issue to adding /usr/xpg[46]/bin/crontab to meet > standards conformance requirements. I disagree. It is closely related. From sacadmin Tue Nov 15 11:11:07 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFJB6IQ027924 for ; Tue, 15 Nov 2005 11:11:07 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAFJB3CM014159; Tue, 15 Nov 2005 20:11:03 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAFJB3Dk000842; Tue, 15 Nov 2005 20:11:03 +0100 (MET) Message-Id: <200511151911.jAFJB3Dk000842@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Don Cragun , Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <1132078928.3069.6.camel@thunk> References: <200511151730.jAFHU7JN007917@spartan.SFBay.Sun.COM> <1132078928.3069.6.camel@thunk> Date: Tue, 15 Nov 2005 20:11:01 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 269 >It's clearly appropriate to change the default editor for >/usr/bin/crontab and changing the default editor in the XPG4 and XPG6 >environments without also changing it in the default environment >introduces an unreasonable variance in behavior. Hear, hear! Casper From sacadmin Tue Nov 15 12:42:54 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFKgrIQ004576 for ; Tue, 15 Nov 2005 12:42:53 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAFKgmGe764370; Tue, 15 Nov 2005 12:42:52 -0800 (PST) Message-Id: <200511152042.jAFKgmGe764370@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 10:42:23 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Don.Cragun@sun.com, sommerfeld@sun.com Cc: Darren.Moffat@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vcp/BxbQLBh2sh37/NZFBQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1182 I'm trying to stay out of this. Oh well. > From: Bill Sommerfeld ... > I believe it is inappropriate to add new /usr/xpgN/bin/* commands > without taking a close look at whether it's appropriate to add the > standards-required behaivor to the /usr/bin version. > > Historically we have not done a very careful job of this, and this leads > to many percieved annoyances when there is no evidence that the existing > behavior is either well-considered or required by a competing standard.. > > It's clearly appropriate to change the default editor for > /usr/bin/crontab and changing the default editor in the XPG4 and XPG6 > environments without also changing it in the default environment > introduces an unreasonable variance in behavior. All true. It seems like the sticking point is that the customer who noted the failure is intitled to relief in a patch/update. I think there are branding issues behind this. Maybe they can be worked. Maybe not. It also seems that the changes you propose are appropriate for a Minor binding (or at least that's my opinion). The core issue here seems to be the conflict in appropriate binding levels. - jek3 From sacadmin Tue Nov 15 12:45:44 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFKjiIQ004786 for ; Tue, 15 Nov 2005 12:45:44 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAFKjd5L765868; Tue, 15 Nov 2005 12:45:43 -0800 (PST) Message-Id: <200511152045.jAFKjd5L765868@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 10:45:14 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: sommerfeld@sun.com, don.cragun@sun.com Cc: Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jOYKp78V9cxBh6NjH1gUZg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 478 > From: Don Cragun ... > Having /usr/bin/crontab change in this way cannot be done in a patch. > Adding /usr/xpg[46]/bin/crontab will have to be done in a patch if we > get a customer complaint about standards non-compliance. Just probing... Would it be possible to do what Bill is suggesting (with a Minor binding) with the understanding that we will do something with a patch binding if the customer complaint referred to above should happen? - jek3 From sacadmin Tue Nov 15 13:51:26 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFLpQIQ010659 for ; Tue, 15 Nov 2005 13:51:26 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAFLpPJN008494; Tue, 15 Nov 2005 13:51:25 -0800 (PST) Message-Id: <200511152151.jAFLpPJN008494@spartan.SFBay.Sun.COM> Date: Tue, 15 Nov 2005 13:51:25 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gcAFemkqeqLzACsMQzd8WQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 2340 >Date: Tue, 15 Nov 2005 10:45:14 -1000 (HST) >From: Joseph Kowalski > >> From: Don Cragun >... >> Having /usr/bin/crontab change in this way cannot be done in a patch. >> Adding /usr/xpg[46]/bin/crontab will have to be done in a patch if we >> get a customer complaint about standards non-compliance. > >Just probing... > >Would it be possible to do what Bill is suggesting (with a Minor binding) >with the understanding that we will do something with a patch binding if >the customer complaint referred to above should happen? I repeat. This case is about adding /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab to align with standards requirements. The standards (and our way of doing things since at least Solaris release 2.5) force us to create /usr/xpg[46]/bin/crontab. The addition of /usr/xpg[46]/bin/crontab is contractually required to be delivered in a patch if a customer request or test suite update complains about our standards non-conformance. A case to change the behavior of /usr/bin/crontab is an orthogonal issue with a completely different set of arguments and a different release binding. Furthermore, even if we do later change /usr/bin/crontab to use vi rather than ed, it would be to use /usr/bin/vi; not /usr/xpg4/bin/vi or /usr/xpg6/bin/vi. So, /usr/xpg[46]/bin/crontab would still be needed for standards conformance. These are orthogonal issues! The desire to change /usr/bin/crontab -e to use vi rather than ed is an arbitrary (although perhaps desirable) change that may break existing customer shell scripts. Despite Bill's statements saying it is appropriate to change the default editor for /usr/bin/crontab from ed to vi because ed is pre-1970's technology, I don't believe the taxonomy allows changing the behavior of /usr/bin/crontab (with "Standard" interface stability level) in this incompatible manner in a patch unless we find that SVID3 or XPG3 requires this behavior change. Neither SVID3 nor XPG3 mention the editor used nor the EDITOR or VISUAL environment variables; XPG3 didn't even mention the -e option. Therefore, the issues involved in changing /usr/bin/crontab are matters of personal preferences and of binary compatibility. No standard is forcing us to change /usr/bin/crontab to use vi rather than ed. - Don > >- jek3 From sacadmin Tue Nov 15 14:03:29 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFM3SIQ011529 for ; Tue, 15 Nov 2005 14:03:28 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAFM3NfX799635; Tue, 15 Nov 2005 14:03:27 -0800 (PST) Message-Id: <200511152203.jAFM3NfX799635@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 12:02:56 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, don.cragun@Sun.COM Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: L75+RDTJhO0+ygcSuVnFng== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 3324 > From: Don Cragun ... > >Just probing... > > > >Would it be possible to do what Bill is suggesting (with a Minor binding) > >with the understanding that we will do something with a patch binding if > >the customer complaint referred to above should happen? > > I repeat. This case is about adding /usr/xpg4/bin/crontab and > /usr/xpg6/bin/crontab to align with standards requirements. The > standards (and our way of doing things since at least Solaris release > 2.5) force us to create /usr/xpg[46]/bin/crontab. I don't agree. The algorithm (since well before 2.5) is: if the base utility can compatibly be made standard conformant do so else implement /usr//... I'm trying to probe the "if" condition. The interesting bit here seems to be a belief that the base utility can be made standard conformant, but only in a minor release (due to our assesment of the seriousness of the incompatibility). > The addition of /usr/xpg[46]/bin/crontab is contractually required to > be delivered in a patch if a customer request or test suite update > complains about our standards non-conformance. Yes. Hence my final clause on what I was probing. Have the causal events you mention above actually happened? > A case to change the behavior of /usr/bin/crontab is an orthogonal > issue with a completely different set of arguments and a different > release binding. Furthermore, even if we do later change > /usr/bin/crontab to use vi rather than ed, it would be to use > /usr/bin/vi; not /usr/xpg4/bin/vi or /usr/xpg6/bin/vi. So, > /usr/xpg[46]/bin/crontab would still be needed for standards > conformance. These are orthogonal issues! Not orthogonal, but if we are contrained to use the standard based vi (which I think you asserted have trivial differences), then I see a reason that the base version can't be made standard conformant. If true, it would seem to end this discussion. (Uh, is xpg4/bin/vi actually different from xpg6/bin/vi? Yes or no is fine) > The desire to change /usr/bin/crontab -e to use vi rather than ed is an > arbitrary (although perhaps desirable) change that may break existing > customer shell scripts. Yep, hence the assertion about Minor binding. > Despite Bill's statements saying it is appropriate to change the > default editor for /usr/bin/crontab from ed to vi because ed is > pre-1970's technology, I don't believe the taxonomy allows changing the > behavior of /usr/bin/crontab (with "Standard" interface stability > level) in this incompatible manner in a patch unless we find that SVID3 > or XPG3 requires this behavior change. Neither SVID3 nor XPG3 mention > the editor used nor the EDITOR or VISUAL environment variables; XPG3 > didn't even mention the -e option. Therefore, the issues involved in > changing /usr/bin/crontab are matters of personal preferences and of > binary compatibility. No standard is forcing us to change > /usr/bin/crontab to use vi rather than ed. Judgement allows us to make incompatable changes which can be justified. I think this falls under the expected change clause (as per pcfs). Each of us on the ARC may have a different opinion as to if the fit is good enough, but by concensus it is decided. (Note: I tend to be a stickler about these, but this one flies below my radar.) - jek3 From sacadmin Tue Nov 15 14:51:06 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFMp6IQ013798 for ; Tue, 15 Nov 2005 14:51:06 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAFMp5JN008581; Tue, 15 Nov 2005 14:51:05 -0800 (PST) Message-Id: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> Date: Tue, 15 Nov 2005 14:51:05 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EGFh6lQHoi2a4H8qZagiJA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 5721 >Date: Tue, 15 Nov 2005 12:02:56 -1000 (HST) >From: Joseph Kowalski > >> From: Don Cragun >... >> >Just probing... >> > >> >Would it be possible to do what Bill is suggesting (with a Minor binding) >> >with the understanding that we will do something with a patch binding if >> >the customer complaint referred to above should happen? >> >> I repeat. This case is about adding /usr/xpg4/bin/crontab and >> /usr/xpg6/bin/crontab to align with standards requirements. The >> standards (and our way of doing things since at least Solaris release >> 2.5) force us to create /usr/xpg[46]/bin/crontab. > >I don't agree. > >The algorithm (since well before 2.5) is: > > if the base utility can compatibly be made standard conformant > > do so > > else > > implement /usr//... > >I'm trying to probe the "if" condition. /usr/bin/crontab currently uses /usr/bin/ed. As has already been noted at least twice, there may be customer scripts that invoke crontab with here-documents consisting of ed commands that will be broken if /usr/bin/crontab starts using /usr/bin/vi rather than /usr/bin/ed. Therefore, your if condition fails. Changing ed to vi is not a compatible change. Furthermore, since XPG3 and SVID3 (the standards specifying /usr/bin utility behavior) do not require an incompatible change in behavior, I do not believe /usr/bin/crontab changes are the subject of this case. > >The interesting bit here seems to be a belief that the base utility >can be made standard conformant, but only in a minor release (due >to our assesment of the seriousness of the incompatibility). No. No! No!!! /usr/bin/crontab already conforms to SVID3 and XPG3. We can change /usr/bin/crontab to use vi rather than ed (an incompatible change) in a minor release if we want to. Doing so won't affect SVID3 or XPG3 conformance. Making an incompatible change to a "standard" interface not required by a standards conformance problem is not allowed in a patch release. The problem this case is addressing is that /usr/bin/crontab doesn't conform to POSIX.2-1992, XPG4, SUS, SUSv2, or SUSv3. We need to add /usr/xpg4/bin/crontab to conform to POSIX.2-1992, SVID3, SUS, and SUSv2. We need to add /usr/xpg6/bin/crontab to conform to SUSv3. After splitting out /usr/xpg[46]/bin/crontab, changing /usr/bin/crontab is an orthogonal issue and is not a standards conformance issue. But, there is a binary compatibility issue that precludes a patch binding for a change to /usr/bin/crontab. > >> The addition of /usr/xpg[46]/bin/crontab is contractually required to >> be delivered in a patch if a customer request or test suite update >> complains about our standards non-conformance. > >Yes. Hence my final clause on what I was probing. > >Have the causal events you mention above actually happened? No. Which is why I stated in my submission of this case: "I am submitting this fasttrack for Carol Fields. Carol is seeking a patch release binding. Current plans are to implement this is ONNV, but since this is a fix for a standards violation, we will have to patch it back into earlier releases if customers complain about the current behavior." > >> A case to change the behavior of /usr/bin/crontab is an orthogonal >> issue with a completely different set of arguments and a different >> release binding. Furthermore, even if we do later change >> /usr/bin/crontab to use vi rather than ed, it would be to use >> /usr/bin/vi; not /usr/xpg4/bin/vi or /usr/xpg6/bin/vi. So, >> /usr/xpg[46]/bin/crontab would still be needed for standards >> conformance. These are orthogonal issues! > >Not orthogonal, but if we are contrained to use the standard based vi >(which I think you asserted have trivial differences), then I see a >reason that the base version can't be made standard conformant. If >true, it would seem to end this discussion. Oh happy day! ;-} > >(Uh, is xpg4/bin/vi actually different from xpg6/bin/vi? Yes or no is fine) Yes. /usr/bin/vi, /usr/ucb/vi, /usr/xpg4/bin/vi, and /usr/xpg6/bin/vi are all different. > >> The desire to change /usr/bin/crontab -e to use vi rather than ed is an >> arbitrary (although perhaps desirable) change that may break existing >> customer shell scripts. > >Yep, hence the assertion about Minor binding. Yes. The Minor binding only applies to changing /usr/bin/crontab's editor of choice; it does not apply to splitting /usr/xpg[46]/bin/crontab out from /usr/bin/crontab and having them invoke /usr/xpg[46]/bin/vi, respectively, as required by standards approved during or after 1992. > >> Despite Bill's statements saying it is appropriate to change the >> default editor for /usr/bin/crontab from ed to vi because ed is >> pre-1970's technology, I don't believe the taxonomy allows changing the >> behavior of /usr/bin/crontab (with "Standard" interface stability >> level) in this incompatible manner in a patch unless we find that SVID3 >> or XPG3 requires this behavior change. Neither SVID3 nor XPG3 mention >> the editor used nor the EDITOR or VISUAL environment variables; XPG3 >> didn't even mention the -e option. Therefore, the issues involved in >> changing /usr/bin/crontab are matters of personal preferences and of >> binary compatibility. No standard is forcing us to change >> /usr/bin/crontab to use vi rather than ed. > >Judgement allows us to make incompatable changes which can be justified. >I think this falls under the expected change clause (as per pcfs). Each >of us on the ARC may have a different opinion as to if the fit is good >enough, but by concensus it is decided. (Note: I tend to be a stickler >about these, but this one flies below my radar.) > >- jek3 From sacadmin Tue Nov 15 15:00:42 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFN0fIQ014558 for ; Tue, 15 Nov 2005 15:00:41 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAFN0aCM001320; Wed, 16 Nov 2005 00:00:36 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAFN0aDk024714; Wed, 16 Nov 2005 00:00:36 +0100 (MET) Message-Id: <200511152300.jAFN0aDk024714@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Don Cragun cc: Joseph.Kowalski@eng.sun.com, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> References: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> Date: Wed, 16 Nov 2005 00:00:33 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 943 >/usr/bin/crontab currently uses /usr/bin/ed. As has already been noted >at least twice, there may be customer scripts that invoke crontab with >here-documents consisting of ed commands that will be broken if >/usr/bin/crontab starts using /usr/bin/vi rather than /usr/bin/ed. >Therefore, your if condition fails. Changing ed to vi is not a >compatible change. Furthermore, since XPG3 and SVID3 (the standards >specifying /usr/bin utility behavior) do not require an incompatible >change in behavior, I do not believe /usr/bin/crontab changes are the >subject of this case. I've only seen this noticed *once* that there *may* be scripts with *here* documents. It seems that we can easily fix that issue by using fairly simple logic like: editor = getenv("VISUAL"); if (editor == NULL) editor = getenv("EDITOR"); if (editor == NULL) editor = isatty(0) ? "vi" : "ed"; If stdin is a tty, then there's no here document.... Casper From sacadmin Tue Nov 15 15:04:47 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFN4lIQ014715 for ; Tue, 15 Nov 2005 15:04:47 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAFN4gbC829644; Tue, 15 Nov 2005 15:04:45 -0800 (PST) Message-Id: <200511152304.jAFN4gbC829644@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 13:04:14 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, don.cragun@Sun.COM Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VKM9hWrSW3BxBVUVVj9rNg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 773 Much deleted. Much I agree with. Much I don't agree with. However, let's not argue about angels on the head of a pin, if we don't have to... > From: Don Cragun ... > >Not orthogonal, but if we are contrained to use the standard based vi > >(which I think you asserted have trivial differences), then I see a > >reason that the base version can't be made standard conformant. If > >true, it would seem to end this discussion. > > Oh happy day! ;-} So, put concisely, there is no single value we can set the default for -e to be which satisfies all standards or expectations. This is independent of the question of what the appropriate value for the base (/usr/bin) version is. Unless someone can refute this, I'm done with my probes. - jek3 From sacadmin Tue Nov 15 15:17:23 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFNHNIQ015153 for ; Tue, 15 Nov 2005 15:17:23 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAFNHCWa004713; Tue, 15 Nov 2005 18:17:12 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAFNHBq6004790; Tue, 15 Nov 2005 18:17:12 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Don Cragun Cc: Joseph.Kowalski@eng.sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> References: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1132096631.3263.874.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 15 Nov 2005 18:17:11 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 359 I'm derailing, on the grounds that the policy being executed here (fossilizing implementation accidents and creating inconsistencies between the XPGn environment and perpetual divergence between default solaris behavior and standards) is out of touch with current user expectations and will continue to create dissatisfaction among our users. - Bill From sacadmin Tue Nov 15 15:25:49 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFNPnIQ015642 for ; Tue, 15 Nov 2005 15:25:49 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAFNPg5E848253; Tue, 15 Nov 2005 15:25:47 -0800 (PST) Message-Id: <200511152325.jAFNPg5E848253@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 13:25:16 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Don.Cragun@sun.com, sommerfeld@sun.com Cc: Joseph.Kowalski@eng.sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iMQiQP3Olxvq83Mn+oeaLw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1004 > Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] > From: Bill Sommerfeld > To: Don Cragun > Cc: Joseph.Kowalski@eng.sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com > Mime-Version: 1.0 > Date: Tue, 15 Nov 2005 18:17:11 -0500 > Content-Transfer-Encoding: 7bit > > I'm derailing, on the grounds that the policy being executed here > (fossilizing implementation accidents and creating inconsistencies > between the XPGn environment and perpetual divergence between default > solaris behavior and standards) is out of touch with current user > expectations and will continue to create dissatisfaction among our > users. > > - Bill Since you are stating that the proposed answer is wrong (for whatever reason), could you state simply what you think the right answer is? (in this specific case, not general terms) I seem to have become confused about that in all the words. - thanks, - jek3 From sacadmin Tue Nov 15 15:32:56 2005 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.Central.Sun.COM [129.147.62.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFNWuIQ015753 for ; Tue, 15 Nov 2005 15:32:56 -0800 (PST) Received: from [192.168.0.100] (vpn-129-153-214-71.Central.Sun.COM [129.153.214.71]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAFNWs5I011771; Tue, 15 Nov 2005 16:32:55 -0700 (MST) In-Reply-To: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> References: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4f4a7c7db562a3a35db41762c1569fbd@sun.com> Content-Transfer-Encoding: 7bit Cc: Don Cragun , Carol.Fields@sun.com From: David Robinson Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] Date: Tue, 15 Nov 2005 17:32:53 -0600 To: PSARC@sac.sfbay.sun.com X-Mailer: Apple Mail (2.623) Status: RO Content-Length: 1391 [from the wings...] On Nov 15, 2005, at 4:51 PM, Don Cragun wrote: > No. No! No!!! /usr/bin/crontab already conforms to SVID3 and XPG3. > We can change /usr/bin/crontab to use vi rather than ed (an > incompatible change) in a minor release if we want to. Doing so won't > affect SVID3 or XPG3 conformance. Making an incompatible change to a > "standard" interface not required by a standards conformance problem is > not allowed in a patch release. I may be wrong, but what I think I am hearing people say is: Yes, you are correct that making the change in a patch is not strictly allowed. But in this case, 'we' think it is OK and since 'we' are the ones that make the rules and exception can be made. Other than the fact that changing /usr/bin/crontab is against existing policy, I think I have heard anything that prevents the proposed changes from being be made in /usr/bin/crontab. The project team is rightfully not proposing that (probably in a futile attempt to avoid this whole discussion in the first place). So if I see things correctly it boils down to a simple decision tree: if (PSARC thinks this is worth an exception to the patch rule) put changes in /usr/bin/crontab else put changes in /usr/xpg*/crontab as proposed. In theory one could appeal PSARC's decision as well. So what does PSARC think? -David [Back to my lurking...] From sacadmin Tue Nov 15 15:45:24 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFNjOIQ017777 for ; Tue, 15 Nov 2005 15:45:24 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAFNjLWa011224; Tue, 15 Nov 2005 18:45:21 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAFNjLHb004868; Tue, 15 Nov 2005 18:45:21 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Joseph Kowalski Cc: Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511152325.jAFNPg5E848253@jurassic.eng.sun.com> References: <200511152325.jAFNPg5E848253@jurassic.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1132098321.3263.927.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 15 Nov 2005 18:45:21 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 986 On Tue, 2005-11-15 at 18:25, Joseph Kowalski wrote: > Since you are stating that the proposed answer is wrong (for whatever > reason), could you state simply what you think the right answer is? > (in this specific case, not general terms) All instances of crontab delivered in solaris should invoke "the same" editor if VISUAL and EDITOR are not set. I've reviewed a sample of the #ifdef XPG*'s in the vi source and, based on that review, consider /usr/bin/vi, /usr/xpg4/bin/vi and /usr/xpg6/bin/vi to be "the same" -- the differences between them appear to largely consist of little fiddly details which are dwarfed by the large-scale differences between vi and ed. I'm willing to hold my nose and allow the specific change to /usr/bin/crontab to only be given Minor release binding even if the others are given Patch binding, particularly since there are no actual plans to backport. But, for consistency, I'd prefer to see the same release binding for both. - Bill From sacadmin Tue Nov 15 15:50:32 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFNoWIQ017863 for ; Tue, 15 Nov 2005 15:50:32 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAFNoWEp012952; Tue, 15 Nov 2005 18:50:32 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAFNoVJY012949; Tue, 15 Nov 2005 18:50:31 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17274.29767.928510.253900@gargle.gargle.HOWL> Date: Tue, 15 Nov 2005 18:50:31 -0500 From: James Carlson To: David Robinson Cc: PSARC@sac.sfbay.sun.com, Don Cragun , Carol.Fields@sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: David Robinson's message of 15 November 2005 17:32:53 References: <200511152251.jAFMp5JN008581@spartan.SFBay.Sun.COM> <4f4a7c7db562a3a35db41762c1569fbd@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1222 David Robinson writes: > So if I see things correctly it boils down to a simple > decision tree: > > if (PSARC thinks this is worth an exception to the patch rule) > put changes in /usr/bin/crontab > else > put changes in /usr/xpg*/crontab as proposed. > > In theory one could appeal PSARC's decision as well. > > So what does PSARC think? I don't know that PSARC thinks (or, if so, then what), but I think you've got that right. Especially with Casper's suggestion of checking isatty, the change seems fairly obviously acceptable (and welcome!) even in a patch, and since the standards also (essentially) dictate how $PATH must be constructed to maintain compliance, we end up killing several birds with one stone. I mostly agree with Bill that we ought to try harder to avoid letting base Solaris drift too far from the standards, and to avoid populating those /usr/xpg*/bin/ directories with excessive numbers of variants. Neither does us good in the long run. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Nov 15 15:57:09 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAFNv9IQ018446 for ; Tue, 15 Nov 2005 15:57:09 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAFNv03M864310; Tue, 15 Nov 2005 15:57:05 -0800 (PST) Message-Id: <200511152357.jAFNv03M864310@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 13:56:34 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lFJ8+Pn6AYID6jOtA8QMHg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 739 > I've reviewed a sample of the #ifdef XPG*'s in the vi source and, based > on that review, consider /usr/bin/vi, /usr/xpg4/bin/vi and > /usr/xpg6/bin/vi to be "the same" -- the differences between them appear > to largely consist of little fiddly details which are dwarfed by the > large-scale differences between vi and ed. OK thanks. I don't think standards bodies view those "fiddly details" in the same light you do, but at least I now know what the discussion is going to be about. I was thinking down a similar path: Why can't /usr/xpg6/bin/vi be the one "true" editor? (Other than I believe its in an optional package). I believe that finding out that the xpg4 and xpg6 versions were different harpooned that idea. - jek3 From sacadmin Tue Nov 15 16:32:44 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAG0WiIQ019911 for ; Tue, 15 Nov 2005 16:32:44 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAG0WgWa023334; Tue, 15 Nov 2005 19:32:42 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAG0Wgah005220; Tue, 15 Nov 2005 19:32:42 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Joseph Kowalski Cc: Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511152357.jAFNv03M864310@jurassic.eng.sun.com> References: <200511152357.jAFNv03M864310@jurassic.eng.sun.com> Content-Type: text/plain Message-Id: <1132101161.3263.1024.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 15 Nov 2005 19:32:42 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1639 On Tue, 2005-11-15 at 18:56, Joseph Kowalski wrote: > I don't think standards bodies view those "fiddly details" in the same > light you do ... It depends on the standards body. The IETF expressly rejects conformance tests because (among other reasons), they cause a focus on details which causes implementors to lose sight of the big picture - you can pass a conformance test but still have an unusable implementation that won't talk to anything but the conformance tester. The big picture here is that divergence between different sub-environments on solaris is bad. This case proposed to introduce just such a divergence when there is, in my opinion at least, ample room to make the change in a way which doesn't create a divergence. > I was thinking down a similar path: Why can't /usr/xpg6/bin/vi be the > one "true" editor? (Other than I believe its in an optional package). > I believe that finding out that the xpg4 and xpg6 versions were different > harpooned that idea. What's even more bizarre is that, in a bunch of places, xpg4's vi diverges from solaris traditional behavior, while xpg6 doesn't: #ifdef XPG4ONLY setcount2(); donewline(); #else /* XPG6 and Solaris */ setCNL(); #endif /* XPG4ONLY */ (I'm not sure I want to know why this can't be handled as a bug in XPG4). Oh, and for the historians in the audience, the setCNL() function is prefaced with: /* * Abbreviations to make code smaller * Left over from squashing ex version 1.1 into * 11/34's and 11/40's. */ I feel fortunate to have missed the PDP-11 era... - Bill From sacadmin Tue Nov 15 16:42:12 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAG0gCIQ020861 for ; Tue, 15 Nov 2005 16:42:12 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAG0g60X897516; Tue, 15 Nov 2005 16:42:10 -0800 (PST) Message-Id: <200511160042.jAG0g60X897516@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 14:41:40 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vuioyKYwL37ixgrXcG9/Ww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1703 > From: Bill Sommerfeld ... > On Tue, 2005-11-15 at 18:56, Joseph Kowalski wrote: > > I don't think standards bodies view those "fiddly details" in the same > > light you do ... > > It depends on the standards body. The IETF expressly rejects > conformance tests because (among other reasons), they cause a focus on > details which causes implementors to lose sight of the big picture - you > can pass a conformance test but still have an unusable implementation > that won't talk to anything but the conformance tester. Well, sure. I guess I should have said "these standards bodies". 8^) > The big picture here is that divergence between different > sub-environments on solaris is bad. This case proposed to introduce > just such a divergence when there is, in my opinion at least, ample room > to make the change in a way which doesn't create a divergence. I'm much less involved with this stuff now, but when I was involved we made every effort for avoid gratuitous divergence. I have no reason to think things are different now. I think the only difference may be that you have the mistaken (sorry!) idea that these particular standards groups can be made to change their minds. "opps" doesn't appear to be in their vocabulary. Anyway, you derailed this. The discussion seems to be if we have ample room to avoid divergence or not. You seem to think so. I also hoped so, but have been convinced we don't. Let's have the discussion. > What's even more bizarre is that, in a bunch of places, xpg4's vi > diverges from solaris traditional behavior, while xpg6 doesn't: ... From here down picture Joe with his fingers in his ears going "la, la, la, ..." - jek3 From sacadmin Tue Nov 15 16:46:30 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAG0kUIQ020884 for ; Tue, 15 Nov 2005 16:46:30 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAG0kSH0011102; Tue, 15 Nov 2005 19:46:28 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAG0kRai005666; Tue, 15 Nov 2005 19:46:27 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Joseph Kowalski Cc: Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511160042.jAG0g60X897516@jurassic.eng.sun.com> References: <200511160042.jAG0g60X897516@jurassic.eng.sun.com> Content-Type: text/plain Message-Id: <1132101987.3263.1042.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 15 Nov 2005 19:46:27 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1143 On Tue, 2005-11-15 at 19:41, Joseph Kowalski wrote: > I'm much less involved with this stuff now, but when I was involved > we made every effort for avoid gratuitous divergence. I have no reason > to think things are different now. I keep stumbling across places where the /usr/bin command complains of a syntax error for something accepted by the /usr/xpgN/bin version. I haven't been keeping track but I'm going to start. > I think the only difference may be that you have the mistaken (sorry!) > idea that these particular standards groups can be made to change their > minds. hmm? i haven't advocated making the standards groups change their specs during this case. > > Anyway, you derailed this. The discussion seems to be if we have ample > room to avoid divergence or not. You seem to think so. I also hoped > so, but have been convinced we don't. Let's have the discussion. > > > What's even more bizarre is that, in a bunch of places, xpg4's vi > > diverges from solaris traditional behavior, while xpg6 doesn't: > ... > From here down picture Joe with his fingers in his ears going "la, la, la, ..." > > - jek3 > From sacadmin Tue Nov 15 18:00:04 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAG204IQ024629 for ; Tue, 15 Nov 2005 18:00:04 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IQ000E01YP5P9@mpk-mail1.sfbay.sun.com> (original mail from Jordan.Brown@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 15 Nov 2005 18:00:04 -0800 (PST) Received: from [10.6.133.198] (ray-198.SFBay.Sun.COM [10.6.133.198]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IQ000LPNYV9MN@mpk-mail1.sfbay.sun.com>; Tue, 15 Nov 2005 17:59:34 -0800 (PST) Date: Tue, 15 Nov 2005 17:59:33 -0800 From: Jordan Brown Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <200511152151.jAFLpPJN008494@spartan.SFBay.Sun.COM> To: Don Cragun Cc: Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Message-id: <437A9285.7040900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr, ru User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 References: <200511152151.jAFLpPJN008494@spartan.SFBay.Sun.COM> Status: RO Content-Length: 2569 [ I'm trying to shut up and, as usual, failing. Sigh. ] Don Cragun wrote: > A case to change the behavior of /usr/bin/crontab is an orthogonal > issue with a completely different set of arguments and a different > release binding. Suppose for a moment we assume that it's acceptable to change the behavior of /usr/bin/crontab so that it runs vi by default. Can we enumerate the standards-compliance issues that would remain? I'm not sure, but I think the list is 1. *which* vi does it run? 2. It pays attention to $VISUAL, which the standard doesn't discuss. Anything else? > Furthermore, even if we do later change > /usr/bin/crontab to use vi rather than ed, it would be to use > /usr/bin/vi; not /usr/xpg4/bin/vi or /usr/xpg6/bin/vi. So, > /usr/xpg[46]/bin/crontab would still be needed for standards > conformance. Is this really true? Suppose that the behavior would be much as it is today, that it runs system("vi") or equivalent and so gets the first vi in your $PATH. With our rules for $PATH settings for standards conformance, would that yield standards-acceptable behavior? Do the standards say anything about the behavior of standards-conformant applications when $PATH includes a different version of the application before the standard version? If "the first one in $PATH" isn't acceptable, then I'm a bit concerned about the implications. It would seem that we would need /usr/xpg* versions of every single application that invokes an underlying application, because at some number of levels of invocation lower there might be an application where the /usr/xpg* version is different from the /usr/bin version. Suppose we have /usr/bin/xxx, which is standards conformant without requiring a /usr/xpg*/bin variant. It invokes yyy, which is also standards conformant without requiring a /usr/xpg*/bin variant. That in turn invokes zzz, for which /usr/bin/zzz is *not* standards conformant, and *does* need a /usr/xpg*/bin variant. In "XPG mode", yyy must somehow invoke /usr/xpg4/bin/zzz. If that's not through $PATH searching, how does it happen? It seems that it'd need a /usr/xpg*/bin/yyy. But then, in XPG mode, xxx must invoke /usr/xpg*/bin/yyy instead of /usr/bin/yyy. That in turn means that there must be a separate /usr/xpg*/bin/xxx. It seems like that way lies madness, and I think it's exactly what you're suggesting here. No one step would be insane, but the path to the Dark Side is a series of small steps, each reasonable in and of itself. (OK, I just watched SW3RotS again last night :-) From sacadmin Tue Nov 15 20:04:41 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAG44fIQ000748 for ; Tue, 15 Nov 2005 20:04:41 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAG44a3v195891; Tue, 15 Nov 2005 20:04:40 -0800 (PST) Message-Id: <200511160404.jAG44a3v195891@jurassic.eng.sun.com> Date: Tue, 15 Nov 2005 18:04:09 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HTOhHGPBvs2Lepzbp/Qk4g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 397 > > I think the only difference may be that you have the mistaken (sorry!) > > idea that these particular standards groups can be made to change their > > minds. > > hmm? i haven't advocated making the standards groups change their specs > during this case. I thought that was part of the wiggle room, implied by your discussion IETF behavior. Sorry if I read too much into that. - jek3 From sacadmin Wed Nov 16 01:36:17 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAG9aGIQ010559 for ; Wed, 16 Nov 2005 01:36:17 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAG9ZVCM018455; Wed, 16 Nov 2005 10:35:46 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAG9Z1Dk012031; Wed, 16 Nov 2005 10:35:15 +0100 (MET) Message-Id: <200511160935.jAG9Z1Dk012031@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Jordan Brown cc: Don Cragun , Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <437A9285.7040900@sun.com> References: <200511152151.jAFLpPJN008494@spartan.SFBay.Sun.COM> <437A9285.7040900@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Nov 2005 10:34:59 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1104 >Suppose for a moment we assume that it's acceptable to change the >behavior of /usr/bin/crontab so that it runs vi by default. Can we >enumerate the standards-compliance issues that would remain? > >I'm not sure, but I think the list is > >1. *which* vi does it run? The first one found in $PATH. If xpg4/6 compliance requires those to be first in the PATH it will find the "proper" vi. >2. It pays attention to $VISUAL, which the standard doesn't discuss. Which isn't a problem, as far as I can tell (as noted, all Solaris applications change their behaviour under non-standard environment variables) >Is this really true? Suppose that the behavior would be much as it is >today, that it runs system("vi") or equivalent and so gets the first vi >in your $PATH. With our rules for $PATH settings for standards >conformance, would that yield standards-acceptable behavior? Do the >standards say anything about the behavior of standards-conformant >applications when $PATH includes a different version of the application >before the standard version? I would think so. Casper From sacadmin Wed Nov 16 04:05:06 2005 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGC56IQ014676 for ; Wed, 16 Nov 2005 04:05:06 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAGC51gG001161; Wed, 16 Nov 2005 12:05:02 GMT Received: from 129.156.173.199 (estale [129.156.173.199]) by enospc.uk.sun.com (8.13.3+Sun/8.13.3/CTE 3.0) with ESMTP id jAGC51O6025932; Wed, 16 Nov 2005 12:05:01 GMT Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Darren J Moffat To: Don Cragun Cc: Joseph.Kowalski@eng.sun.com, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com In-Reply-To: <200511152151.jAFLpPJN008494@spartan.SFBay.Sun.COM> References: <200511152151.jAFLpPJN008494@spartan.SFBay.Sun.COM> Content-Type: text/plain; charset=iso-8859-15 Organization: Sun Microsystems, Inc. Message-Id: <1132142700.368349.25.camel@estale> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 16 Nov 2005 12:05:01 +0000 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1300 On Tue, 2005-11-15 at 21:51, Don Cragun wrote: > >Would it be possible to do what Bill is suggesting (with a Minor binding) > >with the understanding that we will do something with a patch binding if > >the customer complaint referred to above should happen? > > I repeat. This case is about adding /usr/xpg4/bin/crontab and > /usr/xpg6/bin/crontab to align with standards requirements. The > standards (and our way of doing things since at least Solaris release > 2.5 I'm derailing this case, it is no longer obvious and several ARC members seem to be hinting that it isn't complete and that changes to /usr/bin/crontab should be included in this case as well. This case needs a full review to determine what the correct policy for this and future /usr/xpg?/bin vs /usr/bin actually is we can't go on like this every time one of these cases comes up. Note that a possible outcome may well be that some of the changes are appropriate for a patch and some are not. It may also be that a /usr/xpg?/bin/crontab could exist for a patch binding but that changes to /usr/bin/crontab are the correct thing for a micro or minor release (note the careful distinction between true micro releases and patch releases). However all of this is for the full case review to determine. -- Darren J Moffat From sacadmin Wed Nov 16 09:17:57 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGHHvIQ026231 for ; Wed, 16 Nov 2005 09:17:57 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAGHHquO002627; Wed, 16 Nov 2005 09:17:56 -0800 (PST) Message-Id: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> Date: Wed, 16 Nov 2005 07:17:24 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Jordan.Brown@Sun.COM, Casper.Dik@Sun.COM Cc: Don.Cragun@Sun.COM, Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YEJfH/G/pVq6rfIGMLrf/w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 492 > From: Casper.Dik@Sun.COM ... > >1. *which* vi does it run? > > The first one found in $PATH. If xpg4/6 compliance requires those to > be first in the PATH it will find the "proper" vi. Don can comment, but I suspect the PATH setting isn't a requirement. Both of the following should work: /usr/xpg4/bin/crontab PATH=/usr/xpg4/bin:$PATH crontab I believe being able to pick an choose an individual xpg4 utility implementation is a requirement. If its not, it should be. - jek3 From sacadmin Wed Nov 16 09:22:16 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGHMFIQ026466 for ; Wed, 16 Nov 2005 09:22:15 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAGHM8CM008101; Wed, 16 Nov 2005 18:22:08 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAGHM7Dk029434; Wed, 16 Nov 2005 18:22:07 +0100 (MET) Message-Id: <200511161722.jAGHM7Dk029434@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Joseph Kowalski cc: Jordan.Brown@Sun.COM, Don.Cragun@Sun.COM, Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> Date: Wed, 16 Nov 2005 18:22:05 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 788 > >> From: Casper.Dik@Sun.COM >... >> >1. *which* vi does it run? >> >> The first one found in $PATH. If xpg4/6 compliance requires those to >> be first in the PATH it will find the "proper" vi. > >Don can comment, but I suspect the PATH setting isn't a requirement. Both >of the following should work: > > /usr/xpg4/bin/crontab Surely such a call is *not* standards conformant? The standard does not prescribe these paths so standard conforming programs cannot use them. > PATH=/usr/xpg4/bin:$PATH crontab This, I think, looks like the only viable way to get standards conforming behaviour. >I believe being able to pick an choose an individual xpg4 utility implementation >is a requirement. If its not, it should be. Is that a requirement for standards conformance? Casper From sacadmin Wed Nov 16 09:28:35 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGHSYIQ026679 for ; Wed, 16 Nov 2005 09:28:34 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAGHSWFJ016045; Wed, 16 Nov 2005 12:28:33 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAGHSWUX016042; Wed, 16 Nov 2005 12:28:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17275.27712.81666.328361@gargle.gargle.HOWL> Date: Wed, 16 Nov 2005 12:28:32 -0500 From: James Carlson To: Joseph Kowalski Cc: Jordan.Brown@sun.com, Casper.Dik@sun.com, Don.Cragun@sun.com, Joseph.Kowalski@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: Joseph Kowalski's message of 16 November 2005 07:17:24 References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1018 Joseph Kowalski writes: > > The first one found in $PATH. If xpg4/6 compliance requires those to > > be first in the PATH it will find the "proper" vi. > > Don can comment, but I suspect the PATH setting isn't a requirement. Both > of the following should work: [...] A snippet from standards(5): An application that wants to use standard-conforming utili- tues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) environment variable to specify the directories listed in the following table in the order specified to get the appropriate utilities: [...] POSIX.2, POSIX.2a, SUS, SUSv2, XPG4 1. /usr/xpg4/bin [...] POSIX.1-2001, SUSv3 1. /usr/xpg6/bin 2. /usr/xpg4/bin -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Nov 16 09:43:34 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGHhYIQ027913 for ; Wed, 16 Nov 2005 09:43:34 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IQ200M015PS56@mpk-mail1.sfbay.sun.com> (original mail from Jordan.Brown@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 16 Nov 2005 09:43:33 -0800 (PST) Received: from [10.6.102.102] (sunray2.SFBay.Sun.COM [10.6.102.102]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IQ200HY16HDCU@mpk-mail1.sfbay.sun.com>; Wed, 16 Nov 2005 09:41:38 -0800 (PST) Date: Wed, 16 Nov 2005 09:41:37 -0800 From: Jordan Brown Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-reply-to: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> To: Joseph Kowalski Cc: Casper.Dik@Sun.COM, Don.Cragun@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Message-id: <437B6F51.6030004@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr, ru User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> Status: RO Content-Length: 1571 Joseph Kowalski wrote: > Don can comment, but I suspect the PATH setting isn't a requirement. Both > of the following should work: > > /usr/xpg4/bin/crontab > > PATH=/usr/xpg4/bin:$PATH crontab > > I believe being able to pick an choose an individual xpg4 utility implementation > is a requirement. If its not, it should be. It seems a little hard to believe that the standards per se would have such a requirement, since (I presume) they don't have a concept of the existence of non-standard variants. *Solaris* might impose such a requirement, as part of our mechanisms for supporting both the standards and our own proprietary behavior. I'm concerned that this way lies madness, because then you'd have to require that xpg* variants invoke only other xpg* variants. Like I said in an earlier message, allowing an xpg* variant to invoke a /usr/bin variant (even when that variant is xpg* compliant) could eventually lead to executing a /usr/bin variant that's not xpg* compliant. We're seeing exactly that concern here, a concern that even if /usr/bin/crontab was itself xpg* compliant it would be broken because it wouldn't invoke the xpg* version of vi. In fact, you'd have to require xpg* variants of every application that invokes an underlying application, so that there's always a way to run the application in "xpg*-compliant" mode. Plus, since the user shouldn't know which applications can invoke underlying applications, you'd need xpg* variants of *everything* listed in xpg*. I don't think that's a rock you want to turn over. From sacadmin Wed Nov 16 10:11:19 2005 Received: from localhost.east.sun.com (vpn-129-150-80-8.East.Sun.COM [129.150.80.8]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGIBIIQ029525 for ; Wed, 16 Nov 2005 10:11:19 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAGIB7Mp001461; Wed, 16 Nov 2005 13:11:07 -0500 (EST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.4+Sun/8.13.4/Submit) id jAGIB7j1001460; Wed, 16 Nov 2005 13:11:07 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Jordan Brown Cc: Joseph Kowalski , Casper.Dik@sun.com, Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <437B6F51.6030004@sun.com> References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> <437B6F51.6030004@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1132164666.943.143.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Wed, 16 Nov 2005 13:11:07 -0500 Status: RO Content-Length: 1847 On Wed, 2005-11-16 at 12:41, Jordan Brown wrote: > Joseph Kowalski wrote: > > Don can comment, but I suspect the PATH setting isn't a requirement. Both > > of the following should work: > > > > /usr/xpg4/bin/crontab > > > > PATH=/usr/xpg4/bin:$PATH crontab > > > > I believe being able to pick an choose an individual xpg4 utility implementation > > is a requirement. If its not, it should be. > > It seems a little hard to believe that the standards per se would have > such a requirement, since (I presume) they don't have a concept of the > existence of non-standard variants. *Solaris* might impose such a > requirement, as part of our mechanisms for supporting both the standards > and our own proprietary behavior. > > I'm concerned that this way lies madness, because then you'd have to > require that xpg* variants invoke only other xpg* variants. Like I said > in an earlier message, allowing an xpg* variant to invoke a /usr/bin > variant (even when that variant is xpg* compliant) could eventually lead > to executing a /usr/bin variant that's not xpg* compliant. We're seeing > exactly that concern here, a concern that even if /usr/bin/crontab was > itself xpg* compliant it would be broken because it wouldn't invoke the > xpg* version of vi. > > In fact, you'd have to require xpg* variants of every application that > invokes an underlying application, so that there's always a way to run > the application in "xpg*-compliant" mode. Plus, since the user > shouldn't know which applications can invoke underlying applications, > you'd need xpg* variants of *everything* listed in xpg*. Not to mention the need to do surgery on every single "portable" shell script to add #! /usr/xpg4/bin/sh at the top. trust me, we are not making friends. > > I don't think that's a rock you want to turn over. From sacadmin Wed Nov 16 10:25:26 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGIPQIQ000052 for ; Wed, 16 Nov 2005 10:25:26 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAGIPKo9023964; Wed, 16 Nov 2005 10:25:25 -0800 (PST) Message-Id: <200511161825.jAGIPKo9023964@jurassic.eng.sun.com> Date: Wed, 16 Nov 2005 08:24:53 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, Casper.Dik@Sun.COM Cc: Jordan.Brown@Sun.COM, Don.Cragun@Sun.COM, Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xAtWNJ4QPJA9hu+lkbPklQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1154 > From: Casper.Dik@Sun.COM ... > >Don can comment, but I suspect the PATH setting isn't a requirement. Both > >of the following should work: > > > > /usr/xpg4/bin/crontab > > Surely such a call is *not* standards conformant? > > The standard does not prescribe these paths so standard conforming programs > cannot use them. Interesting point. We've now reach maximal velocity on my head spinning. My view is that such a call is not standard conformant, but that such a call would/should be supported by our implementation. Put another way, I think its a rather important feature, not to be done away with lightly. > > PATH=/usr/xpg4/bin:$PATH crontab > > This, I think, looks like the only viable way to get standards conforming > behaviour. > > >I believe being able to pick an choose an individual xpg4 utility implementation > >is a requirement. If its not, it should be. > > Is that a requirement for standards conformance? As above, **probably** not. I believe it is an obvious and benefical attribute of our current implementation (assuming it is, and bugs seem to indicate it might not be, but bug is the key word here). - jek3 From sacadmin Wed Nov 16 10:32:11 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGIWBIQ000300 for ; Wed, 16 Nov 2005 10:32:11 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAGIVhFh026364; Wed, 16 Nov 2005 10:32:05 -0800 (PST) Message-Id: <200511161832.jAGIVhFh026364@jurassic.eng.sun.com> Date: Wed, 16 Nov 2005 08:31:29 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Joseph.Kowalski@eng.sun.com, james.d.carlson@sun.com Cc: Jordan.Brown@sun.com, Casper.Dik@sun.com, Don.Cragun@sun.com, Joseph.Kowalski@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0m0MMQsnAfPpvv68C4Iqhg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1564 Well, that's pretty convincing.... 8^) > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Date: Wed, 16 Nov 2005 12:28:32 -0500 > From: James Carlson > To: Joseph Kowalski > Cc: Jordan.Brown@sun.com, Casper.Dik@sun.com, Don.Cragun@sun.com, Joseph.Kowalski@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com > Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] > > Joseph Kowalski writes: > > > The first one found in $PATH. If xpg4/6 compliance requires those to > > > be first in the PATH it will find the "proper" vi. > > > > Don can comment, but I suspect the PATH setting isn't a requirement. Both > > of the following should work: > [...] > > A snippet from standards(5): > > An application that wants to use standard-conforming utili- > tues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) > environment variable to specify the directories listed in > the following table in the order specified to get the > appropriate utilities: > [...] > POSIX.2, POSIX.2a, > SUS, SUSv2, XPG4 1. /usr/xpg4/bin > [...] > POSIX.1-2001, SUSv3 > 1. /usr/xpg6/bin > > > 2. /usr/xpg4/bin > > > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Nov 16 10:59:13 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGIxCIQ002107 for ; Wed, 16 Nov 2005 10:59:13 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAGIx2CM003034; Wed, 16 Nov 2005 19:59:02 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAGIx2Dk000678; Wed, 16 Nov 2005 19:59:02 +0100 (MET) Message-Id: <200511161859.jAGIx2Dk000678@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: James Carlson cc: Joseph Kowalski , Jordan.Brown@Sun.COM, Don.Cragun@Sun.COM, Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <17275.27712.81666.328361@gargle.gargle.HOWL> References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> <17275.27712.81666.328361@gargle.gargle.HOWL> Date: Wed, 16 Nov 2005 19:59:00 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 969 >Joseph Kowalski writes: >> > The first one found in $PATH. If xpg4/6 compliance requires those to >> > be first in the PATH it will find the "proper" vi. >> >> Don can comment, but I suspect the PATH setting isn't a requirement. Both >> of the following should work: >[...] > >A snippet from standards(5): > > An application that wants to use standard-conforming utili- > tues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) > environment variable to specify the directories listed in > the following table in the order specified to get the > appropriate utilities: >[...] > POSIX.2, POSIX.2a, > SUS, SUSv2, XPG4 1. /usr/xpg4/bin >[...] > POSIX.1-2001, SUSv3 > 1. /usr/xpg6/bin > > > 2. /usr/xpg4/bin > But not call: /usr/xpg4/bin/crontab As the PATH is explicitely required to be set here, I assume using fill pathnames is not supported. Casper From sacadmin Wed Nov 16 11:02:04 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGJ23IQ002272 for ; Wed, 16 Nov 2005 11:02:04 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAGJ1jCM004238; Wed, 16 Nov 2005 20:01:45 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAGJ1jDk002445; Wed, 16 Nov 2005 20:01:45 +0100 (MET) Message-Id: <200511161901.jAGJ1jDk002445@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Jordan Brown , Joseph Kowalski , Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <1132164666.943.143.camel@localhost> References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> <437B6F51.6030004@sun.com> <1132164666.943.143.camel@localhost> Date: Wed, 16 Nov 2005 20:01:43 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 224 >Not to mention the need to do surgery on every single "portable" shell >script to add > >#! /usr/xpg4/bin/sh Does the standard require this pathname to exist? (If not, than *portable* is somewhat of a stretch) Casper From sacadmin Wed Nov 16 11:03:30 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGJ3TIQ002285 for ; Wed, 16 Nov 2005 11:03:29 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAGJ3SbH016547; Wed, 16 Nov 2005 14:03:28 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAGJ3SQA016544; Wed, 16 Nov 2005 14:03:28 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17275.33408.77294.626692@gargle.gargle.HOWL> Date: Wed, 16 Nov 2005 14:03:28 -0500 From: James Carlson To: Casper.Dik@Sun.COM Cc: Joseph Kowalski , Jordan.Brown@Sun.COM, Don.Cragun@Sun.COM, Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: Casper.Dik@Sun.COM's message of 16 November 2005 19:59:00 References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> <17275.27712.81666.328361@gargle.gargle.HOWL> <200511161859.jAGIx2Dk000678@vaticaan.Holland.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1151 Casper.Dik@Sun.COM writes: > But not call: > > /usr/xpg4/bin/crontab > > As the PATH is explicitely required to be set here, I assume using > fill pathnames is not supported. I don't think anybody cares if you run /usr/xpg4/bin/crontab. The point is that Solaris itself (in standards(5)) *requires* you to set PATH in a particular way when you want to be in a standards-conformant environment. And that *required* PATH would certainly allow the implementor of crontab to do the equivalent of system("vi") without worry. It is guaranteed to pick up the right "vi" in all cases. Thus, there's no need to differentiate among 'crontab' variants purely on the path of vi. The only reason to do it would be for the ed/vi split, and there are at least a few of us who feel that switching to vi (perhaps with your isatty(0) test first) would be something to consider. This particular 'ed' doesn't have a lot of friends. :-> -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Nov 16 11:08:57 2005 Received: from localhost.east.sun.com (vpn-129-150-80-8.East.Sun.COM [129.150.80.8]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGJ8uIQ002666 for ; Wed, 16 Nov 2005 11:08:57 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jAGJ8jsg001740; Wed, 16 Nov 2005 14:08:45 -0500 (EST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.4+Sun/8.13.4/Submit) id jAGJ8j6K001739; Wed, 16 Nov 2005 14:08:45 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Jordan Brown , Joseph Kowalski , Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200511161901.jAGJ1jDk002445@vaticaan.Holland.Sun.COM> References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> <437B6F51.6030004@sun.com> <1132164666.943.143.camel@localhost> <200511161901.jAGJ1jDk002445@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ASCII Content-Transfer-Encoding: 7bit Message-Id: <1132168124.943.149.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Wed, 16 Nov 2005 14:08:45 -0500 Status: RO Content-Length: 455 On Wed, 2005-11-16 at 14:01, Casper.Dik@sun.com wrote: > >#! /usr/xpg4/bin/sh > > Does the standard require this pathname to exist? > > (If not, than *portable* is somewhat of a stretch) indeed. the quotes were intended to indicate sarcasm. either just the #! line is portable, just the body of the script is portable, or you find yourself limited yourself to an ancient shell subset. either way of these three is painful for ISV's. - Bill From sacadmin Wed Nov 16 11:19:19 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGJJIIQ002785 for ; Wed, 16 Nov 2005 11:19:19 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAGJJECM015240; Wed, 16 Nov 2005 20:19:14 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAGJJEDk013680; Wed, 16 Nov 2005 20:19:14 +0100 (MET) Message-Id: <200511161919.jAGJJEDk013680@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Joseph Kowalski cc: Jordan.Brown@Sun.COM, Don.Cragun@Sun.COM, Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <200511161825.jAGIPKo9023964@jurassic.eng.sun.com> References: <200511161825.jAGIPKo9023964@jurassic.eng.sun.com> Date: Wed, 16 Nov 2005 20:19:12 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 436 >As above, **probably** not. > >I believe it is an obvious and benefical attribute of our current implementation >(assuming it is, and bugs seem to indicate it might not be, but bug is the >key word here). You can't really have a standards compliant version by just running /usr/xpg4/bin/path. E.g., awk will not run the proper system("vi") and such. I'm not sure what the meaning of these executables is without $PATH set. Casper From sacadmin Wed Nov 16 11:22:33 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGJMWIQ002829 for ; Wed, 16 Nov 2005 11:22:32 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAGJMSCM016987; Wed, 16 Nov 2005 20:22:28 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAGJMSDk015717; Wed, 16 Nov 2005 20:22:28 +0100 (MET) Message-Id: <200511161922.jAGJMSDk015717@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Jordan Brown , Joseph Kowalski , Don.Cragun@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: <1132168124.943.149.camel@localhost> References: <200511161717.jAGHHquO002627@jurassic.eng.sun.com> <437B6F51.6030004@sun.com> <1132164666.943.143.camel@localhost> <200511161901.jAGJ1jDk002445@vaticaan.Holland.Sun.COM> <1132168124.943.149.camel@localhost> Date: Wed, 16 Nov 2005 20:22:26 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 547 >On Wed, 2005-11-16 at 14:01, Casper.Dik@sun.com wrote: >> >#! /usr/xpg4/bin/sh >> >> Does the standard require this pathname to exist? >> >> (If not, than *portable* is somewhat of a stretch) > >indeed. the quotes were intended to indicate sarcasm. > >either just the #! line is portable, just the body of the script is >portable, or you find yourself limited yourself to an ancient shell >subset. either way of these three is painful for ISV's. What about: #!/usr/bin/env sh and setting $PATH to have /usr/xpg4/bin before /bin? Casper From sacadmin Wed Nov 16 11:30:47 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGJUlIQ003064 for ; Wed, 16 Nov 2005 11:30:47 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAGJUaoP027317; Wed, 16 Nov 2005 11:30:45 -0800 (PST) Message-Id: <200511161930.jAGJUaoP027317@jurassic.eng.sun.com> Date: Wed, 16 Nov 2005 09:30:14 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: James.D.Carlson@Sun.COM, Casper.Dik@Sun.COM Cc: Joseph.Kowalski@eng.sun.com, Jordan.Brown@Sun.COM, Don.Cragun@Sun.COM, Joseph.Kowalski@Sun.COM, Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ugyCydeOakgefvEljdSM+w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 439 > From: Casper.Dik@Sun.COM ... > But not call: > > /usr/xpg4/bin/crontab > > As the PATH is explicitely required to be set here, I assume using > fill pathnames is not supported. I'd phrase it as "not guarenteed to be standard conformant" but for the purposes of this discussion, there is no practical difference. Just in case anybody hasn't figured it out yet, I was wrong on this detail as Jim's snippet made quite clear. - jek3 From sacadmin Wed Nov 16 11:36:52 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGJapIQ003135 for ; Wed, 16 Nov 2005 11:36:51 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAGJapJN009722; Wed, 16 Nov 2005 11:36:51 -0800 (PST) Message-Id: <200511161936.jAGJapJN009722@spartan.SFBay.Sun.COM> Date: Wed, 16 Nov 2005 11:36:51 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] To: Casper.Dik@Sun.COM, Joseph.Kowalski@eng.sun.com, Jordan.Brown@Sun.COM, Darren.Moffat@Sun.COM, sommerfeld@Sun.COM Cc: Carol.Fields@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rEiTAEwkDfN62YGdGruDPw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 3113 Since I spent so much time responding to this thread yesterday, I am not going to be able to spend much time on it today. Below are a few quick points that may help refocus some of the discussion. I'll give more details when the case is discussed. (Now that two members have derailed this case, who is the case owner?) - Don >Date: Wed, 16 Nov 2005 19:59:00 +0100 >From: Casper.Dik@sun.com > >>Joseph Kowalski writes: >>> > The first one found in $PATH. If xpg4/6 compliance requires those to >>> > be first in the PATH it will find the "proper" vi. They do not. >>> >>> Don can comment, but I suspect the PATH setting isn't a requirement. Both >>> of the following should work: >>[...] Yes, either of the forms Joe gave (deleted in this snippet) should work. IBM, HP, and some of our customers believe that Solaris provides the gold standard of simultaneous conformance to multiple utility and system interface standards. I hate that some members of PSARC want to dismantle these features. Furthermore, until we implement the LSB, applications written to conform to any of the standards we claim to support have been able to freely invoke applications written to any of the standards we claim to support with no problems as long as a minimal amount of care is taken by conforming applications. (Not many applications make use of this feature, but those that do value it highly.) >> >>A snippet from standards(5): >> >> An application that wants to use standard-conforming utili- >> tues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) >> environment variable to specify the directories listed in >> the following table in the order specified to get the >> appropriate utilities: >>[...] >> POSIX.2, POSIX.2a, >> SUS, SUSv2, XPG4 1. /usr/xpg4/bin >>[...] >> POSIX.1-2001, SUSv3 >> 1. /usr/xpg6/bin >> >> >> 2. /usr/xpg4/bin This is a simplification describing something that works for those who don't want to read the standards to find the real requirements. It is absolutely required to find the correct initial getconf utility on which applications can then fine tune their environment unless the application knows Solaris implementation details. See further comments below. >> > >But not call: > > /usr/xpg4/bin/crontab > >As the PATH is explicitely required to be set here, I assume using >fill pathnames is not supported. /usr/xpg4/bin, /usr/xpg6/bin, and /usr/bin are Solaris implementation details, but using full pathnames is supported. The 1992 and later standards allow users to get a setting for $PATH from the getconf utility. A user can then find the full pathname of any utility specified by the appropriate standard. As mentioned above, you currently need to set $PATH as indicated in standards(5) to find the proper getconf utility to bootstrap this process. (If I have my way, extensions to getconf on the design board will reduce this requirement considerably. Other projects have precluded implementing these extensions for the time being.) > > >Casper From sacadmin Wed Nov 16 13:48:42 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAGLmgIQ009416 for ; Wed, 16 Nov 2005 13:48:42 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAGLmeIi017477; Wed, 16 Nov 2005 16:48:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAGLmeSw017474; Wed, 16 Nov 2005 16:48:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17275.43319.640843.976004@gargle.gargle.HOWL> Date: Wed, 16 Nov 2005 16:48:39 -0500 From: James Carlson To: Don Cragun Cc: Casper.Dik@sun.com, Joseph.Kowalski@eng.sun.com, Jordan.Brown@sun.com, Darren.Moffat@sun.com, sommerfeld@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] In-Reply-To: Don Cragun's message of 16 November 2005 11:36:51 References: <200511161936.jAGJapJN009722@spartan.SFBay.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1411 Don Cragun writes: > Since I spent so much time responding to this thread yesterday, I am > not going to be able to spend much time on it today. Below are a few > quick points that may help refocus some of the discussion. I'll give > more details when the case is discussed. (Now that two members have > derailed this case, who is the case owner?) I think first-to-derail ought to win. > Yes, either of the forms Joe gave (deleted in this snippet) should > work. IBM, HP, and some of our customers believe that Solaris provides > the gold standard of simultaneous conformance to multiple utility and > system interface standards. I hate that some members of PSARC want to > dismantle these features. Furthermore, until we implement the LSB, [...] What? No, that's not it at all. Nobody here is suggesting dismantling any features. What we *are* suggesting is minimizing the number of artifacts we introduce. Fewer are better. Please don't confuse one for the other. Asking to make sure that the split is in fact _required_ in any particular case (and that there's no other way to comply) is not equivalent to a desire to "dismantle" the standards or our support for them. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Nov 29 16:41:26 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAU0fQIQ014854 for ; Tue, 29 Nov 2005 16:41:26 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAU0fQJN007171; Tue, 29 Nov 2005 16:41:26 -0800 (PST) Message-Id: <200511300041.jAU0fQJN007171@spartan.SFBay.Sun.COM> Date: Tue, 29 Nov 2005 16:41:26 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] To: PSARC@sac.sfbay.sun.com Cc: Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tHU4U8EXLxxY4YCyRgp0hA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 514 In preparation for tomorrow's review of this case, I have created an issues file in the case's directory made up of excerpts from the mail log with project team responses. Rather than being in the usual order (grouped by comment submitter), the issues are listed in cronological order. Many messages have been deleted because it was believed that no new issues were raised. If anyone has an issue that has not been addressed, the project team will be happy to discuss them during the review. Sincerely, Don From sacadmin Tue Nov 29 17:30:26 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAU1UQIQ018453 for ; Tue, 29 Nov 2005 17:30:26 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAU1UOH0026939; Tue, 29 Nov 2005 20:30:24 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAU1UNQL005752; Tue, 29 Nov 2005 20:30:23 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] From: Bill Sommerfeld To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com In-Reply-To: <200511300041.jAU0fQJN007171@spartan.SFBay.Sun.COM> References: <200511300041.jAU0fQJN007171@spartan.SFBay.Sun.COM> Content-Type: text/plain Message-Id: <1133314222.2367.550.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 29 Nov 2005 20:30:23 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1476 On Tue, 2005-11-29 at 19:41, Don Cragun wrote: > In preparation for tomorrow's review of this case, I have created an > issues file in the case's directory made up of excerpts from the mail > log with project team responses. Rather than being in the usual order > (grouped by comment submitter), the issues are listed in cronological > order. Many messages have been deleted because it was believed that no > new issues were raised. If anyone has an issue that has not been > addressed, the project team will be happy to discuss them during the > review. The responses entered so far show a significant misinterpretation of my objections to the path taken in this case, most notably conflating and confusing my views about: - what I think we should have done a long time ago - what I'd prefer to see in the long run in an ideal world - what I believe is achievable in the context of this case I'll attempt to clarify in the file before the meeting tomorrow and will be prepared to further clarify on the call. In addition, I still have some open questions about what *specifically* is required by the standards (as opposed to how we have traditionally implemented the standards requirements), and I am contemplating a proposed TCR for this case (namely, to deliver a change to /usr/bin/crontab in addition to whatever else it delivers). I'll be adding these issues to the end of the issues file in our conventional issues format. (wes-NN, etc.) - Bill From sacadmin Tue Nov 29 17:57:07 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAU1v7IQ020532 for ; Tue, 29 Nov 2005 17:57:07 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAU1v6nj029525; Tue, 29 Nov 2005 17:57:06 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id jAU1uCAt007454; Tue, 29 Nov 2005 17:56:12 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id jAU1uChH007453; Tue, 29 Nov 2005 17:56:12 -0800 (PST) Date: Tue, 29 Nov 2005 17:56:12 -0800 (PST) From: Gary Winiger Message-Id: <200511300156.jAU1uChH007453@marduk.eng.sun.com> To: Don.Cragun@sun.com, sommerfeld@sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 277 Bill, > I'll attempt to clarify in the file before the meeting tomorrow and will > be prepared to further clarify on the call. Would you kindly send the diffs to the mail log. Some of us (I) are planning to read what Don has done offline over the evening. Thankx, Gary.. From sacadmin Tue Nov 29 18:47:04 2005 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAU2l4IQ022198 for ; Tue, 29 Nov 2005 18:47:04 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IQQ00801Y9FP8@mpk-mail1.sfbay.sun.com> (original mail from Jordan.Brown@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 29 Nov 2005 18:47:04 -0800 (PST) Received: from [10.6.102.102] (sunray2.SFBay.Sun.COM [10.6.102.102]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IQQ000M3YE14B@mpk-mail1.sfbay.sun.com>; Tue, 29 Nov 2005 18:46:50 -0800 (PST) Date: Tue, 29 Nov 2005 18:46:49 -0800 From: Jordan Brown Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-reply-to: <200511300041.jAU0fQJN007171@spartan.SFBay.Sun.COM> To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Message-id: <438D1299.3080102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr, ru User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 References: <200511300041.jAU0fQJN007171@spartan.SFBay.Sun.COM> Status: RO Content-Length: 1879 Assume for a moment that it is not necessary to set $PATH correctly in order to get standards-compliant behavior. Assume that all that is necessary is to invoke the /usr/xpg4/bin version of the command. (In symbolic logic, we'd call this a working premise, one that we expect to lead to a contradiction and therefore be proven false.) Consider the shell script "foo": vi Invoking /usr/xpg4/bin/sh foo must invoke an xpg4-compliant version of vi. ... but it doesn't. Therefore either our working premise is false, and it *is* necessary to set $PATH correctly, or everything is broken and "crontab -e" is the least of our worries. (Alternatively, tell me why this script is not standards conformant and tell me how to write this shell script conformantly, so that it works with this invocation.) Similar arguments apply to awk's system() invocation - not the shell invoked, but the command requested by the awk script - and to vi's shell escape mechanism. There are numerous others. When you set $PATH correctly, we should guarantee that you get standards-conformant behavior. When you invoke the /usr/xpg*/bin variant with entries in your $PATH before the /usr/xpg* entries, you are entering a gray area. You will get some standards-conformant behavior, and may get some non-conformant behavior. We should use good engineering judgement to determine when to insist on conformance and when to accept non-conformance. Note that by definition a standards conformance test cannot invoke a /usr/xpg*/bin variant directly, because the path "/usr/xpg*/bin" is not in the standard. Note also that every case where the /usr/bin variant of a tool differs from the /usr/xpg*/bin variant is an opportunity for the problems described above, and so our standards-conformance is *improved* when we make /usr/bin variants be natively standards-conformant. From sacadmin Tue Nov 29 20:48:02 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAU4m2IQ028333 for ; Tue, 29 Nov 2005 20:48:02 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAU4m1JN007345; Tue, 29 Nov 2005 20:48:01 -0800 (PST) Message-Id: <200511300448.jAU4m1JN007345@spartan.SFBay.Sun.COM> Date: Tue, 29 Nov 2005 20:48:01 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] To: Jordan.Brown@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: d76PAottHPmMsG+1cxzhhw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 5044 >Date: Tue, 29 Nov 2005 18:46:49 -0800 >From: Jordan Brown > >Assume for a moment that it is not necessary to set $PATH correctly in >order to get standards-compliant behavior. Assume that all that is >necessary is to invoke the /usr/xpg4/bin version of the command. (In >symbolic logic, we'd call this a working premise, one that we expect to >lead to a contradiction and therefore be proven false.) OK. > >Consider the shell script "foo": > > vi OK. > >Invoking > > /usr/xpg4/bin/sh foo > >must invoke an xpg4-compliant version of vi. No. A version of sh that conforms to POSIX.2-1992, XPG4, SUS, SUSv2, and SUSv3 is required to invoke the command vi that is identified by searching $PATH. There is no requirement that /usr/xpg4/bin/sh only execute XPG4 conforming utilities. If $PATH contains /usr/ucb, /usr/bin (or /bin), /usr/xpg6/bin, or any other directory that contains a vi that isn't xpg4-compliant, the standards require that the vi that is executed by this command must not be /usr/xpg4/bin/vi. > >... but it doesn't. > >Therefore either our working premise is false, and it *is* necessary to >set $PATH correctly, or everything is broken and "crontab -e" is the >least of our worries. You are correct here; your working premise is false. > >(Alternatively, tell me why this script is not standards conformant and >tell me how to write this shell script conformantly, so that it works >with this invocation.) Conforming to what? If you are trying to be sure that foo always invokes a version of vi that is xpg4-compliant, then foo should be: PATH=/usr/xpg4/bin:/usr/bin:$PATH vi if it is safe to assume that some version of sh or ksh will be used to invoke foo; if not, foo needs to specify which shell it will use using #!. If you want foo to invoke the first executable vi found in $PATH, your script is correct as it is written. > >Similar arguments apply to awk's system() invocation - not the shell >invoked, but the command requested by the awk script - and to vi's shell >escape mechanism. There are numerous others. > >When you set $PATH correctly, we should guarantee that you get >standards-conformant behavior. If you set $PATH as specified in standards(5), the utilities that are not shell built-ins will behave as documented in the corresponding standards for any shell you choose to use. If you set $PATH as specified in standards(5) and use sh as found by that setting of $PATH, all of the utilities specified by that standard will behave as documented in that standard including the shell command language itself and the shell built-ins. > >When you invoke the /usr/xpg*/bin variant with entries in your $PATH >before the /usr/xpg* entries, you are entering a gray area. You will >get some standards-conformant behavior, and may get some non-conformant >behavior. We should use good engineering judgement to determine when to >insist on conformance and when to accept non-conformance. Agreed. > >Note that by definition a standards conformance test cannot invoke a >/usr/xpg*/bin variant directly, because the path "/usr/xpg*/bin" is not >in the standard. If it includes a script that sets $PATH as specified on our standards(5) man page and then searches $PATH for a particular standards-conforming utility, the test suite can indeed invoke that variant directly. Otherwise, it can't. The test suites don't try to do this and it can be argued that the standards don't require them to work if they do. Our Solaris implementation of the standards simultaneously supports all of the standards listed on the standards(5) man page; none of the standards require that an implementation support more than two standards (e.g. SUSv3 requires that we support SUSv3 and C99, SUSv2 requires that we support SUSv2 and C90). The fact that we allow an application running in an SUSv3 environment to build and run applications that conform to SUSv2 is a feature that is not required by SUSv3. > >Note also that every case where the /usr/bin variant of a tool differs >from the /usr/xpg*/bin variant is an opportunity for the problems >described above, and so our standards-conformance is *improved* when we >make /usr/bin variants be natively standards-conformant. No. This would only true if your original premise were true. The mechanism we actually provide makes it much easier for an application written to use one standard as its programming manual to use invoke another application that uses another standard as its programming manual. The fact that most of us don't write standards-conforming shell scripts doesn't mean that we should remove the flexibility we have from our customers (even if they are small in number) who do depend on this behavior. The customers who do depend on this behavior tend to be some of our larger customers (government, Wall Street, database vendors, etc.). We used the model you're proposing in SunOS 4.1.x, but abandoned it in favor of our current model in SunOS 5.0 because it is a lot more flexible. - Don From sacadmin Wed Nov 30 02:24:54 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUAOrIQ010122 for ; Wed, 30 Nov 2005 02:24:53 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAUAOnCM008185; Wed, 30 Nov 2005 11:24:49 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAUAOnDk014635; Wed, 30 Nov 2005 11:24:49 +0100 (MET) Message-Id: <200511301024.jAUAOnDk014635@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Don Cragun cc: Jordan.Brown@Sun.COM, PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: <200511300448.jAU4m1JN007345@spartan.SFBay.Sun.COM> References: <200511300448.jAU4m1JN007345@spartan.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Nov 2005 11:24:47 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1634 >The mechanism we actually provide makes it much easier for an >application written to use one standard as its programming manual to >use invoke another application that uses another standard as its >programming manual. The fact that most of us don't write >standards-conforming shell scripts doesn't mean that we should remove >the flexibility we have from our customers (even if they are small in >number) who do depend on this behavior. The customers who do depend on >this behavior tend to be some of our larger customers (government, Wall >Street, database vendors, etc.). But as we've already determined that calling /usr/xpg4/bin/ does not give a standards conforming program *unless* we set $PATH, what use is there in having /usr/xpg4/bin/crontab? I consider any program in /usr/xpg4/bin a bug that needs fixing; now some cannot be fixed but I'm sure other can. >We used the model you're proposing in SunOS 4.1.x, but abandoned it in >favor of our current model in SunOS 5.0 because it is a lot more >flexible. But perhaps I misunderstand the "mechanism" we provide. Are you seriously suggesting that people are actually using /usr/xpg4/bin/ foo and /usr/xpg6/bin/bar in one and the same script? (Even though, as we've discovered such calls do not yield fully standards conforming programs). Once that we've determined that we can change crontab(1), and I think we have, I see no reason not to prefer that PATH. Because I'm not thinking solely of the users who think standards conformance is important but also those who get confused when they call crontab -e and don't know what to tell ed. Casper From sacadmin Wed Nov 30 07:08:53 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUF8rIQ018386 for ; Wed, 30 Nov 2005 07:08:53 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAUF8qJN007865; Wed, 30 Nov 2005 07:08:52 -0800 (PST) Message-Id: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> Date: Wed, 30 Nov 2005 07:08:52 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] To: Casper.Dik@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BCFs0yeCmuvtlJFpNKG40Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 3406 >Date: Wed, 30 Nov 2005 11:24:47 +0100 >From: Casper.Dik@sun.com > >>The mechanism we actually provide makes it much easier for an >>application written to use one standard as its programming manual to >>use invoke another application that uses another standard as its >>programming manual. The fact that most of us don't write >>standards-conforming shell scripts doesn't mean that we should remove >>the flexibility we have from our customers (even if they are small in >>number) who do depend on this behavior. The customers who do depend on >>this behavior tend to be some of our larger customers (government, Wall >>Street, database vendors, etc.). > > >But as we've already determined that calling /usr/xpg4/bin/ >does not give a standards conforming program *unless* we set $PATH, >what use is there in having /usr/xpg4/bin/crontab? We have not determined this. We have determined that invoking a utility in /usr/xpg4/bin, /usr/xpg6/bin, or /usr/bin without setting $PATH doesn't give you a standards conforming environment for any particular standard; but that is different from having that specific utility behave as specified by a particular standard. > >I consider any program in /usr/xpg4/bin a bug that needs fixing; now >some cannot be fixed but I'm sure other can. I'm having trouble with this sentence. I believe you are saying you believe that having /usr/xpg4/bin and /usr/xpg6/bin present on Solaris systems is a bug, but I don't understand what you are trying to say with the clause after the semicolon. > >>We used the model you're proposing in SunOS 4.1.x, but abandoned it in >>favor of our current model in SunOS 5.0 because it is a lot more >>flexible. > > >But perhaps I misunderstand the "mechanism" we provide. > >Are you seriously suggesting that people are actually using /usr/xpg4/bin/ >foo and /usr/xpg6/bin/bar in one and the same script? Yes. Doing so is not common, but having $PATH set to something like: $HOME/bin:/usr/bin:/opt/SUNWspro/bin:/usr/ccs/bin:/sbin:. and directly executing a particular utility in /usr/xpg4/bin is common. > >(Even though, as we've discovered such calls do not yield fully standards >conforming programs). Correct. The user is able to pick and choose the desired behavior based on the individual utility they want to use rather than being stuck with all of the utilities specified by a standard as a monolithic set. The standards provide the monolithic sets; our Solaris implementation provides the pick and choose capabilities as well. > >Once that we've determined that we can change crontab(1), and I think >we have, I see no reason not to prefer that PATH. > >Because I'm not thinking solely of the users who think standards >conformance is important but also those who get confused when they call >crontab -e and don't know what to tell ed. The default editor to be used by crontab -e is a different issue. It can be handled on its own no matter whether /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab are created or not. Making the XPG4-conforming crontab execute the XPG4-conforming vi is a standards conformance issue. Making the XPG6-conforming crontab execute the XPG6-conforming vi is a standards conformance issue. Choosing whether the SVID3-conforming crontab executes /usr/bin/vi or /usr/bin/ed is not a standards conformance issue; it is "just" a binary compatibility issue. - Don > >Casper From sacadmin Wed Nov 30 07:17:51 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUFHoIQ018440 for ; Wed, 30 Nov 2005 07:17:51 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAUFHlCM003818; Wed, 30 Nov 2005 16:17:47 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAUFHlDk016693; Wed, 30 Nov 2005 16:17:47 +0100 (MET) Message-Id: <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Don Cragun cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> Date: Wed, 30 Nov 2005 16:17:45 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 2771 >We have not determined this. We have determined that invoking a >utility in /usr/xpg4/bin, /usr/xpg6/bin, or /usr/bin without setting >$PATH doesn't give you a standards conforming environment for any >particular standard; but that is different from having that specific >utility behave as specified by a particular standard. Ok: so who are the consumers who execute /usr/xpg4/bin/xxx? >> >>I consider any program in /usr/xpg4/bin a bug that needs fixing; now >>some cannot be fixed but I'm sure other can. > >I'm having trouble with this sentence. I believe you are saying you >believe that having /usr/xpg4/bin and /usr/xpg6/bin present on Solaris >systems is a bug, but I don't understand what you are trying to say >with the clause after the semicolon. I'm saying that: - if we can bring standards conformance to the /usr/bin application then that is preferred over having a /usr/xpgX/bin/* application Reason: "X works properly under <> but not under Solaris." "Oh, but you have to use /usr/xpg4/bin" The executables which work need to be in /usr/bin; we should not gather dusty decks there. I understand that in some cases this is just too hard (awk, sh), but we need to bend over backwards to make it work in as many cases as we can. >>Are you seriously suggesting that people are actually using /usr/xpg4/bin/ >>foo and /usr/xpg6/bin/bar in one and the same script? > >Yes. Doing so is not common, but having $PATH set to something like: > $HOME/bin:/usr/bin:/opt/SUNWspro/bin:/usr/ccs/bin:/sbin:. >and directly executing a particular utility in /usr/xpg4/bin is common. Ok, but that doesn't preclude us from not adding new xpg4 entries... >Correct. The user is able to pick and choose the desired behavior >based on the individual utility they want to use rather than being >stuck with all of the utilities specified by a standard as a monolithic >set. The standards provide the monolithic sets; our Solaris >implementation provides the pick and choose capabilities as well. Which is good because? >The default editor to be used by crontab -e is a different issue. It >can be handled on its own no matter whether /usr/xpg4/bin/crontab and >/usr/xpg6/bin/crontab are created or not. Making the XPG4-conforming >crontab execute the XPG4-conforming vi is a standards conformance >issue. Making the XPG6-conforming crontab execute the XPG6-conforming >vi is a standards conformance issue. Choosing whether the >SVID3-conforming crontab executes /usr/bin/vi or /usr/bin/ed is not a >standards conformance issue; it is "just" a binary compatibility >issue. But it appears that the $PATH requirement solves this? Or do you feel that /usr/xpg4/bin/crontab -e must execute /usr/xpg4/bin/vi when the suggestion is it would not? Casper From sacadmin Wed Nov 30 09:05:14 2005 Received: from albian-mail.SFBay.Sun.COM (albian-mail.SFBay.Sun.COM [10.11.30.12]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUH5EIQ005459 for ; Wed, 30 Nov 2005 09:05:14 -0800 (PST) Received: from [192.168.100.80] (vpn-129-150-24-97.SFBay.Sun.COM [129.150.24.97]) by albian-mail.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAUH5CEm009204; Wed, 30 Nov 2005 09:05:12 -0800 (PST) In-Reply-To: <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com Content-Transfer-Encoding: 7bit From: Allen Wittenauer Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] Date: Wed, 30 Nov 2005 09:05:29 -0800 To: Casper.Dik@sun.com X-Mailer: Apple Mail (2.746.2) Status: RO Content-Length: 867 On Nov 30, 2005, at 7:17 AM, Casper.Dik@sun.com wrote: > >> We have not determined this. We have determined that invoking a >> utility in /usr/xpg4/bin, /usr/xpg6/bin, or /usr/bin without setting >> $PATH doesn't give you a standards conforming environment for any >> particular standard; but that is different from having that specific >> utility behave as specified by a particular standard. > > Ok: so who are the consumers who execute /usr/xpg4/bin/xxx? There are definitely instances where the xpg4 versions provide additional functionality beyond what the /usr/bin versions do. My favorite example here (that I've both used in my own scripts and have seen others use) is grep, in particular for -e and -f. [I'm not sure why /usr/bin/grep doesn't support those options. I keep meaning to file a bug on this but haven't gotten around to it.] From sacadmin Wed Nov 30 09:13:45 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUHDjIQ005639 for ; Wed, 30 Nov 2005 09:13:45 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAUHDiJN008137; Wed, 30 Nov 2005 09:13:44 -0800 (PST) Message-Id: <200511301713.jAUHDiJN008137@spartan.SFBay.Sun.COM> Date: Wed, 30 Nov 2005 09:13:44 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] To: Casper.Dik@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: luI5GQyrA9py8jFEygyF+Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 3693 >Date: Wed, 30 Nov 2005 16:17:45 +0100 >From: Casper.Dik@sun.com > >>We have not determined this. We have determined that invoking a >>utility in /usr/xpg4/bin, /usr/xpg6/bin, or /usr/bin without setting >>$PATH doesn't give you a standards conforming environment for any >>particular standard; but that is different from having that specific >>utility behave as specified by a particular standard. > >Ok: so who are the consumers who execute /usr/xpg4/bin/xxx? Me for one (although I do it in reverse). Others I know of include, but I am sure are not limited to, Siebold, US Navy, and Bloomberg. Since our tools don't report this type of activity (and have no way of knowing when it occurs), it is hard to make any assumptions about how often it happens in practice. > >>> >>>I consider any program in /usr/xpg4/bin a bug that needs fixing; now >>>some cannot be fixed but I'm sure other can. >> >>I'm having trouble with this sentence. I believe you are saying you >>believe that having /usr/xpg4/bin and /usr/xpg6/bin present on Solaris >>systems is a bug, but I don't understand what you are trying to say >>with the clause after the semicolon. > >I'm saying that: > - if we can bring standards conformance to the /usr/bin > application then that is preferred over having a /usr/xpgX/bin/* > application > >Reason: "X works properly under <> but not under Solaris." > "Oh, but you have to use /usr/xpg4/bin" <> doesn't have the track record of binary compatibility and simultaneous conformance to multiple standards that Solaris systems provide. > >The executables which work need to be in /usr/bin; we should not >gather dusty decks there. > >I understand that in some cases this is just too hard (awk, sh), >but we need to bend over backwards to make it work in as >many cases as we can. > >>>Are you seriously suggesting that people are actually using /usr/xpg4/bin/ >>>foo and /usr/xpg6/bin/bar in one and the same script? >> >>Yes. Doing so is not common, but having $PATH set to something like: >> $HOME/bin:/usr/bin:/opt/SUNWspro/bin:/usr/ccs/bin:/sbin:. >>and directly executing a particular utility in /usr/xpg4/bin is common. > >Ok, but that doesn't preclude us from not adding new xpg4 entries... > >>Correct. The user is able to pick and choose the desired behavior >>based on the individual utility they want to use rather than being >>stuck with all of the utilities specified by a standard as a monolithic >>set. The standards provide the monolithic sets; our Solaris >>implementation provides the pick and choose capabilities as well. > >Which is good because? > >>The default editor to be used by crontab -e is a different issue. It >>can be handled on its own no matter whether /usr/xpg4/bin/crontab and >>/usr/xpg6/bin/crontab are created or not. Making the XPG4-conforming >>crontab execute the XPG4-conforming vi is a standards conformance >>issue. Making the XPG6-conforming crontab execute the XPG6-conforming >>vi is a standards conformance issue. Choosing whether the >>SVID3-conforming crontab executes /usr/bin/vi or /usr/bin/ed is not a >>standards conformance issue; it is "just" a binary compatibility >>issue. > >But it appears that the $PATH requirement solves this? Or do you >feel that /usr/xpg4/bin/crontab -e must execute /usr/xpg4/bin/vi >when the suggestion is it would not? An XPG4-conforming crontab -e must invoke an XPG4-conforming vi unless $EDITOR (or possibly $VISUAL) specifies another editor. An XPG6-conforming crontab -e must invoke an XPG6-conforming vi unless $EDITOR (or possibly $VISUAL) specifies another editor. /usr/bin/vi is neither an XPG4-conforming vi nor an XPG6-conforming vi. - Don > >Casper From sacadmin Wed Nov 30 09:21:39 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUHLdIQ005719 for ; Wed, 30 Nov 2005 09:21:39 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAUHLSJN008173; Wed, 30 Nov 2005 09:21:29 -0800 (PST) Message-Id: <200511301721.jAUHLSJN008173@spartan.SFBay.Sun.COM> Date: Wed, 30 Nov 2005 09:21:29 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] To: allenw@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zVIgL3dIQ0C5zNCvUWOx3Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 563 >Date: Wed, 30 Nov 2005 09:05:29 -0800 >From: Allen Wittenauer > > There are definitely instances where the xpg4 versions provide >additional functionality beyond what the /usr/bin versions do. My >favorite example here (that I've both used in my own scripts and have >seen others use) is grep, in particular for -e and -f. [I'm not >sure why /usr/bin/grep doesn't support those options. I keep meaning >to file a bug on this but haven't gotten around to it.] Please file the bug. And, consider adding -E and -F as well. - Don From sacadmin Wed Nov 30 09:26:39 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUHQdIQ005834 for ; Wed, 30 Nov 2005 09:26:39 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAUHQceZ022588; Wed, 30 Nov 2005 12:26:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAUHQcdC022583; Wed, 30 Nov 2005 12:26:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17293.57549.989187.60023@gargle.gargle.HOWL> Date: Wed, 30 Nov 2005 12:26:37 -0500 From: James Carlson To: Allen Wittenauer Cc: Casper.Dik@sun.com, Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: Allen Wittenauer's message of 30 November 2005 09:05:29 References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2823 Allen Wittenauer writes: > > Ok: so who are the consumers who execute /usr/xpg4/bin/xxx? > > There are definitely instances where the xpg4 versions provide > additional functionality beyond what the /usr/bin versions do. My > favorite example here (that I've both used in my own scripts and have > seen others use) is grep, in particular for -e and -f. [I'm not > sure why /usr/bin/grep doesn't support those options. I keep meaning > to file a bug on this but haven't gotten around to it.] That's not quite the question. Yes, you can (if you like) run any of the XPG4 or XPG6 binaries on your own from outside the standards-conforming environment. They work and they sometimes provide new and useful features. (In the specific case of 'grep,' I don't see a good reason for the split, but I guess I could be missing something, and that's perhaps a separate issue.) If you're in the standards-conforming environment, though, you're required to set your PATH to have the /usr/xpg[46]/bin path first. Once you do that, an exec of "vi" will pick up the correct standards- conforming one. The big question, I think, is what ought to happen when the user has some 'vi' other than /usr/xpg4/bin/vi on the path first, and the user directly invokes "/usr/xpg4/bin/crontab -e." We've heard what seem to be two assertions: - This case effectively says that /usr/xpg4/bin/crontab must exec /usr/xpg4/bin/vi even if the $PATH is configured to have a different vi first. The implication is that we need a separate /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab just to satisfy the varying explicit path. It also asserts that crontab should ignore $VISUAL, though the standards don't actually require that. - The other respondents on this thread have said that it'd be ok (and perhaps quite *expected*) for /usr/xpg[46]/bin/crontab to invoke whatever 'vi' happens to be on the $PATH first. If the user is in the standards-conforming environment, that will necessarily be the correct standards-conforming /usr/xpg[46]/bin/vi because the system requires a specific contents of $PATH. The benefit of the second assertion is that we can completely avoid the fork, at least for a Minor release binding. Just accept that changing the default from 'ed' to 'vi' is a Good Thing for /usr/bin/crontab, and make it invoke "vi" without a path. There are quite a few of us who think that forking here is in general something we need to avoid whenever we can, even if it means dragging some parts of Solaris into the 1980's, kicking and screaming. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Nov 30 09:49:38 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUHnbIQ007232 for ; Wed, 30 Nov 2005 09:49:38 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAUHnZCM010682; Wed, 30 Nov 2005 18:49:35 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAUHnZDk026765; Wed, 30 Nov 2005 18:49:35 +0100 (MET) Message-Id: <200511301749.jAUHnZDk026765@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Don Cragun cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: <200511301713.jAUHDiJN008137@spartan.SFBay.Sun.COM> References: <200511301713.jAUHDiJN008137@spartan.SFBay.Sun.COM> Date: Wed, 30 Nov 2005 18:49:33 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1601 ><> doesn't have the track record of binary compatibility and >simultaneous conformance to multiple standards that Solaris systems >provide. Yes, but people known to <> are a very large group; incoporating standards compliance and new options in /usr/bin tools helps *both* are large corporate customers and the people we try to lure form <>. The /usr/xpg?/bin/* isn't generally helpful to "Solaris immigrants". >An XPG4-conforming crontab -e must invoke an XPG4-conforming vi unless >$EDITOR (or possibly $VISUAL) specifies another editor. An >XPG6-conforming crontab -e must invoke an XPG6-conforming vi unless >$EDITOR (or possibly $VISUAL) specifies another editor. /usr/bin/vi is >neither an XPG4-conforming vi nor an XPG6-conforming vi. SInce there is *no* established usage for /usr/xpg4/bin/crontab it's just as easy to prefix $PATH in script as running /usr/xpg4/bin/crontab. I believe system("vi") in "crontab -e" meets the standards requirement with a properly setup PATH and scripts can be written to invoke it in such a manner. (Swiftly changing hats) I also like to warn that we're proposing to add two more set-uid executables to the OS; this means more code to patch and more code at risk and more concerned customers. (And in the old days, xpg4 apps behaved differently and were more prone to security issues when invoking external programs, so this is not just a theoretical additional risk) Also, I strongly feel that much of the xpg4 stuff was done wrong; there is NO reason I can think of why /bin/grep did not get the /usr/xpg4/bin/grep options. Casper From sacadmin Wed Nov 30 11:40:32 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUJeWIQ013749 for ; Wed, 30 Nov 2005 11:40:32 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAUJeQH0026714; Wed, 30 Nov 2005 14:40:26 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAUJeQlN011988; Wed, 30 Nov 2005 14:40:26 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] From: Bill Sommerfeld To: Allen Wittenauer Cc: Casper.Dik@sun.com, Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com In-Reply-To: References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1133379625.11418.48.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 30 Nov 2005 14:40:26 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3194 On Wed, 2005-11-30 at 12:05, Allen Wittenauer wrote: > There are definitely instances where the xpg4 versions provide > additional functionality beyond what the /usr/bin versions do. My > favorite example here (that I've both used in my own scripts and have > seen others use) is grep, in particular for -e and -f. [I'm not > sure why /usr/bin/grep doesn't support those options. I keep meaning > to file a bug on this but haven't gotten around to it.] There is firm consensus of PSARC that this behavior is unquestionably a bug. For those of you not on the call, this is, I believe, the conclusions of the meeting and will form the core of the draft opinion... - while literal standards conformance does not require delivery of separate /usr/xpgN/bin variants of crontab, our past practice does require it. There was rough consensus that it is not appropriate at this time to revisit this element of the architecture. - However, the project's spec will be amended to add, in addition to the delivery in a patch of the xpgN variants of crontab, a change with Minor release binding to /usr/bin/crontab to use the first vi on $PATH as the default editor. The proposal to conditionally use "ed" vs "vi" based on isatty(0) was thought to be overly complicated for a change with Minor binding. - there will be a combination of opinion fodder and advice stating: - The full capabilities of our standards compliance implementation is poorly documented and understood by the developer & user community; at the very least, the documentation needs work. "Cherrypicking" of commands from one environment while running in another environment is supported, but both the ability to do this and the limitations on this are not well expressed in documentation, including standards(5). - There is divergence between our architecture and our implementation. In many cases, once a decision to "fork" a command was made, many individual non-conflicting behaviors were never integrated into the default implementation. Our current architecture is that there should be no cases where a particular command feature, option, or the like accepted by a /usr/xpgN/bin variant should generate a syntax error when fed to the default system (/usr/bin) variant. This divergence has created both confusion about the architecture, and an increased need to "cherrypick" commands in scripts. This confusion is harmful to Solaris and to our users. When members of the community encounter such divergence, they should file bugs against the commands. (While not discussed in the meeting, I'm going to recommend in the opinion that these bugs should be tagged with a specific keyword so they can be tracked as a group. any suggestions for the keyword?) - since such bugs are a recurring source of irritation and confusion, attention should be given to fixing them. my current list of divergent behavior: id -u grep (multiple options including, at a minimum, -e, -f, -E, -F, and -q) tail -n du sh syntax: export foo=bar (accepted by ksh and xpg4/bin/sh; generates 'foo=bar: is not an identifier') $(cmd) (yields "syntax error: `(' unexpected") ---- - Bill From sacadmin Wed Nov 30 11:48:29 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUJmSIQ014133 for ; Wed, 30 Nov 2005 11:48:29 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAUJmQCM013866; Wed, 30 Nov 2005 20:48:26 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAUJmPDk002251; Wed, 30 Nov 2005 20:48:25 +0100 (MET) Message-Id: <200511301948.jAUJmPDk002251@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Allen Wittenauer , Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: <1133379625.11418.48.camel@thunk> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> Date: Wed, 30 Nov 2005 20:48:23 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 779 > - while literal standards conformance does not require delivery of >separate /usr/xpgN/bin variants of crontab, our past practice does >require it. There was rough consensus that it is not appropriate at >this time to revisit this element of the architecture. > I'm *very* unhappy with two new set-uid programs being delivered. I will therefor request that the new binaries be implemented as non-setuid wrappers for the standard crontab command. (Setting $EDITOR and other things as appropriate) Casper (Aside, I really don't understand how past practice can force us to deliver new pathnames as use of such pathnames require editing of scripts and the suggested alternatives which kept a single binary oculd be made to be compliant with similar, but different editing) From sacadmin Wed Nov 30 12:23:52 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUKNfIQ015750 for ; Wed, 30 Nov 2005 12:23:52 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAUKNewx023956; Wed, 30 Nov 2005 15:23:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAUKNejr023953; Wed, 30 Nov 2005 15:23:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17294.2636.605110.137402@gargle.gargle.HOWL> Date: Wed, 30 Nov 2005 15:23:40 -0500 From: James Carlson To: Casper.Dik@sun.com Cc: Bill Sommerfeld , Allen Wittenauer , Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: Casper.Dik@sun.com's message of 30 November 2005 20:48:23 References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> <200511301948.jAUJmPDk002251@vaticaan.Holland.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 966 Casper.Dik@sun.com writes: > I'm *very* unhappy with two new set-uid programs being > delivered. Are two set-uid programs generated by a single set of sources with trivial ifdefs really very much different from one set-uid program? > (Aside, I really don't understand how past practice can > force us to deliver new pathnames as use of such pathnames require > editing of scripts and the suggested alternatives which > kept a single binary oculd be made to be compliant with similar, > but different editing) It's the "cherrypicking" issue that we discussed during the meeting. Historically, we've allowed it, even though it leads to very strange behavior and even though it can't really be supported in any sane way from within a script. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Nov 30 12:39:18 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUKdHIQ016095 for ; Wed, 30 Nov 2005 12:39:18 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAUKdECM025838; Wed, 30 Nov 2005 21:39:14 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAUKdEDk004325; Wed, 30 Nov 2005 21:39:14 +0100 (MET) Message-Id: <200511302039.jAUKdEDk004325@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: James Carlson cc: Bill Sommerfeld , Allen Wittenauer , Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: <17294.2636.605110.137402@gargle.gargle.HOWL> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> <200511301948.jAUJmPDk002251@vaticaan.Holland.Sun.COM> <17294.2636.605110.137402@gargle.gargle.HOWL> Date: Wed, 30 Nov 2005 21:39:11 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1511 >Casper.Dik@sun.com writes: >> I'm *very* unhappy with two new set-uid programs being >> delivered. > >Are two set-uid programs generated by a single set of sources with >trivial ifdefs really very much different from one set-uid program? The behaviour os xpg4 library calls is not trivially the same; there have been instances of programs which had security bgs because they were compiled with -D_XPG4; had they not been compiled with that, the issue bug would not have arisen. >> (Aside, I really don't understand how past practice can >> force us to deliver new pathnames as use of such pathnames require >> editing of scripts and the suggested alternatives which >> kept a single binary oculd be made to be compliant with similar, >> but different editing) > >It's the "cherrypicking" issue that we discussed during the meeting. >Historically, we've allowed it, even though it leads to very strange >behavior and even though it can't really be supported in any sane way >from within a script. Yes, that is true, but whether the "cherry picking" behaviour is available through: PATH=/usr/xpg4/bin:$PATH crontab -e or PATH=/usr/xpg4/bin:$PATH /usr/xpg4/bin/crontab -e or /usr/xpg4/bin/crontab -e or EDITOR=/usr/xpg4/bin/vi crontab -e doesn't really make much difference, does it? The /usr/xpg4/bin/crontab variant doesn't exist at this time, so a different new cherry pick mechanism is fine in this case (and I can't think of a reason why you'd want $EDITOR not be the same all the time) Casper From sacadmin Wed Nov 30 12:41:33 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUKfXIQ016804 for ; Wed, 30 Nov 2005 12:41:33 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAUKfUH0018206; Wed, 30 Nov 2005 15:41:30 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jAUKfU6n012144; Wed, 30 Nov 2005 15:41:30 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Allen Wittenauer , Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com In-Reply-To: <200511301948.jAUJmPDk002251@vaticaan.Holland.Sun.COM> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> <200511301948.jAUJmPDk002251@vaticaan.Holland.Sun.COM> Content-Type: text/plain Message-Id: <1133383290.11418.73.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 30 Nov 2005 15:41:30 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 597 On Wed, 2005-11-30 at 14:48, Casper.Dik@sun.com wrote: > I'm *very* unhappy with two new set-uid programs being > delivered. This issue didn't surface during the review, wasn't added to the issues file, and you didn't call into the meeting... > I will therefor request that the new binaries be implemented > as non-setuid wrappers for the standard crontab command. > (Setting $EDITOR and other things as appropriate) Can the project team comment on whether this is acceptable to them? seems like this would allow the the variant crontab programs to be implemented as scripts.. - Bill From sacadmin Wed Nov 30 12:43:15 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUKhEIQ016845 for ; Wed, 30 Nov 2005 12:43:14 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jAUKhCCM026838; Wed, 30 Nov 2005 21:43:12 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jAUKhCDk004531; Wed, 30 Nov 2005 21:43:12 +0100 (MET) Message-Id: <200511302043.jAUKhCDk004531@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Allen Wittenauer , Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: <1133383290.11418.73.camel@thunk> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> <200511301948.jAUJmPDk002251@vaticaan.Holland.Sun.COM> <1133383290.11418.73.camel@thunk> Date: Wed, 30 Nov 2005 21:43:09 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 789 >On Wed, 2005-11-30 at 14:48, Casper.Dik@sun.com wrote: >> I'm *very* unhappy with two new set-uid programs being >> delivered. > >This issue didn't surface during the review, wasn't added to the issues >file, and you didn't call into the meeting... I try to avoid meetings during diner; but I agree, I should have added it to the issues file. It didn't dawn on me until probably during the meeting when I wrote my email. >> I will therefor request that the new binaries be implemented >> as non-setuid wrappers for the standard crontab command. >> (Setting $EDITOR and other things as appropriate) > >Can the project team comment on whether this is acceptable to them? >seems like this would allow the the variant crontab programs to be >implemented as scripts.. That, too. Casper From sacadmin Wed Nov 30 13:00:57 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUL0uIQ018567 for ; Wed, 30 Nov 2005 13:00:56 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAUL0u5j024240; Wed, 30 Nov 2005 16:00:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAUL0uQm024237; Wed, 30 Nov 2005 16:00:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17294.4872.253100.24753@gargle.gargle.HOWL> Date: Wed, 30 Nov 2005 16:00:56 -0500 From: James Carlson To: Casper.Dik@sun.com Cc: Bill Sommerfeld , Allen Wittenauer , Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: Casper.Dik@sun.com's message of 30 November 2005 21:39:11 References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> <200511301948.jAUJmPDk002251@vaticaan.Holland.Sun.COM> <17294.2636.605110.137402@gargle.gargle.HOWL> <200511302039.jAUKdEDk004325@vaticaan.Holland.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 836 Casper.Dik@sun.com writes: > Yes, that is true, but whether the "cherry picking" behaviour is available > through: [...] > doesn't really make much difference, does it? Certainly not to me, but Don has asserted that just one form (direct path to executable without modifying anything in the environment) is acceptable to those who need to cherry-pick and that the others are not. Now, I'm not sure at all why this would be specially true of the editor invoked by crontab -e (it seems to me like a marginal case compared with the default shell chosen for ":sh"), but it doesn't seem like a point worth arguing. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Nov 30 15:24:43 2005 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUNOhIQ027525 for ; Wed, 30 Nov 2005 15:24:43 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id jAUNOhJN008563; Wed, 30 Nov 2005 15:24:43 -0800 (PST) Message-Id: <200511302324.jAUNOhJN008563@spartan.SFBay.Sun.COM> Date: Wed, 30 Nov 2005 15:24:43 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] To: Casper.Dik@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jYswUga2l911Xrpw/gVK7w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 3201 >From: Casper.Dik@sun.com >Date: Wed, 30 Nov 2005 21:39:11 +0100 > >>Casper.Dik@sun.com writes: >>> I'm *very* unhappy with two new set-uid programs being >>> delivered. >> >>Are two set-uid programs generated by a single set of sources with >>trivial ifdefs really very much different from one set-uid program? > >The behaviour os xpg4 library calls is not trivially the same; >there have been instances of programs which had security bgs >because they were compiled with -D_XPG4; had they not been compiled with >that, the issue bug would not have arisen. Carol can correct me if I'm wrong, but I don't expect values-xpg4.o or values-xpg6.o to be linked in to deal with this change. I expect that the ifdef's will only choose "vi", "/usr/xpg4/bin/vi", or "/usr/xpg6/bin/vi" to be executed for /usr/bin/crontab -e (when neither $VISUAL nor $EDITOR are set), /usr/xpg4/bin/crontab -e (when $EDITOR is not set), or /usr/xpg6/bin/crontab -e (when $EDITOR is not set), respectively. > >>> (Aside, I really don't understand how past practice can >>> force us to deliver new pathnames as use of such pathnames require >>> editing of scripts and the suggested alternatives which >>> kept a single binary oculd be made to be compliant with similar, >>> but different editing) >> >>It's the "cherrypicking" issue that we discussed during the meeting. >>Historically, we've allowed it, even though it leads to very strange >>behavior and even though it can't really be supported in any sane way >>from within a script. > >Yes, that is true, but whether the "cherry picking" behaviour is available >through: > > PATH=/usr/xpg4/bin:$PATH crontab -e > >or > PATH=/usr/xpg4/bin:$PATH /usr/xpg4/bin/crontab -e > >or > /usr/xpg4/bin/crontab -e >or > EDITOR=/usr/xpg4/bin/vi crontab -e > >doesn't really make much difference, does it? If the user enters any of the above, the results should all be similar. But, in the picky details of standards conformance, it does matter if you make /usr/xpg4/bin/crontab be the shell script: EDITOR=/usr/xpg4/bin/vi crontab The standards conforming utilities should not be setting environment variables that can affect behavior of exec'ed children unless doing so is documented as a side effect of running that utility. (This only matters for environment variables that are in userland namespace, but $EDITOR is one of these environment variables.) In the question we talked about during the meeting: If you run /usr/xpg4/bin/crontab -e and execute a shell escape from vi that invokes vi (without using a full pathname), which vi do you get? The answer was that /usr/xpg4/bin/crontab -e needs to exec /usr/xpg4/bin/vi, but if the user then enters the command ":!vi file" the vi that is invoked must be the first one found in $PATH; not necessarily /usr/xpg4/bin/vi. The same logic applies with $EDITOR. > >The /usr/xpg4/bin/crontab variant doesn't exist at this time, >so a different new cherry pick mechanism is fine in this case >(and I can't think of a reason why you'd want $EDITOR not be the >same all the time) You don't want it to because $EDITOR overrides $PATH and the implementation should not be changing the environment the user set. - Don > >Casper From sacadmin Wed Nov 30 16:34:21 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jB10YKIQ000870 for ; Wed, 30 Nov 2005 16:34:21 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB10YAWa018195; Wed, 30 Nov 2005 19:34:10 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jB10YATG014091; Wed, 30 Nov 2005 19:34:10 -0500 (EST) Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] From: Bill Sommerfeld To: Allen Wittenauer Cc: Casper.Dik@sun.com, Don Cragun , PSARC@sac.sfbay.sun.com, Carol.Fields@sun.com In-Reply-To: <1133379625.11418.48.camel@thunk> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1133397249.11418.132.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 30 Nov 2005 19:34:10 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 373 On Wed, 2005-11-30 at 14:40, Bill Sommerfeld wrote: > (While not discussed in the meeting, I'm going to recommend in the > opinion that these bugs should be tagged with a specific keyword so they > can be tracked as a group. any suggestions for the keyword?) So, since nobody else made a (serious) suggestion I've marked a few bugs "missing-std-feature". - Bill From sacadmin Wed Nov 30 19:20:04 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jB13K3IQ005689 for ; Wed, 30 Nov 2005 19:20:03 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB13K2Wa008344; Wed, 30 Nov 2005 22:20:02 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jB13K1N6014699; Wed, 30 Nov 2005 22:20:01 -0500 (EST) Subject: 2005/683 crontab -e very drafty opinion From: Bill Sommerfeld To: psarc@sac.sfbay.sun.com Cc: Carol.Fields@sun.com In-Reply-To: <1133397249.11418.132.camel@thunk> References: <200511301508.jAUF8qJN007865@spartan.SFBay.Sun.COM> <200511301517.jAUFHlDk016693@vaticaan.Holland.Sun.COM> <1133379625.11418.48.camel@thunk> <1133397249.11418.132.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1133407201.11418.175.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 30 Nov 2005 22:20:01 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 9821 This is not yet ready for full review as there are a few TBDs but as I was on a roll I wanted to get this out for an initial review while this is still fresh in everyone's mind.. - Bill sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: /usr/xpgN/bin/crontab Submitted by: Carol Fields File: PSARC/2005/683/opinion.ms Date: November 30th, 2005 Committee: Bill Sommerfeld, Robert Berube Jr, James D Carlson, Ed Gould, Joseph Kowalski, Glenn Skinner, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac-opinion@Sun.COM 1. Summary This project proposed to deliver xpg4 and xpg6 variants of the "crontab" command which invoke the xpg4 and xpg6 vari- ants of "vi" as their default editors. In addition, the project will deliver a change to the /usr/bin variant of crontab to uses "vi" rather than "ed" as the default editor. 2. Decision & Precedence Information This project is approved as specified in reference [1]. The entirety of this project may be delivered in a Minor release of Solaris. In addition, the two xpg variants of crontab may be delivered in a Patch release of Solaris. PSARC/2005/683 Copyright 2005 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. __________________________________________________________ | Interfaces Exported | |_____________________|________________|_________________| |Interface | Classification| Comments | |_____________________|________________|_________________| |/usr/xpg4/bin/crontab| Standard | XPG4 behavior;| | | | required by Sun| | | | precedent | |/usr/xpg6/bin/crontab| Standard | XPG6 behavior;| | | | required by Sun| | | | precedent | |/usr/bin/crontab -e | Standard | vi as default| | | | editor | |_____________________|________________|_________________| 4. Opinion 4.1. Background During the era of SunOS 4.1, our standards-compliance approach relied exclusively on the setting of $PATH. Based on customer feedback, we subsequently added the additional ability for users to "cherry-pick" specific commands from the variant directories. At present, we document a combined approach: setting $PATH as specified in standards(5) for a complete standards-compliant environment, and, in addition, variant forms of individual commands are documented by path- name in the individual command manpages. 4.2. Original Proposal The original proposal left the existing behavior of /usr/bin/crontab -e unchanged, using the first "ed" in $PATH as the default editor. 4.3. Amendment Several reviewers expressed concern with the divergence in behavor between /usr/bin and xpgN variants introduced by this case. The project team accepted a suggestion during the meeting to amend the spec to add, in addition to the delivery with Patch binding of the xpg4 and xpg6 variants of crontab, a change with Minor release binding to /usr/bin/crontab to use the first vi on $PATH as the default editor. PSARC/2005/683 Copyright 2005 Sun Microsystems - 3 - 4.4. Standards Strategy Unclear To Many Additionally, several reviewers expressed concern with the slowly growing proliferation of additional variant commands in the /usr/xpg4/bin and /usr/xpg6/bin directories, trig- gered solely by the behavior of a spawned subprocess. This concern was reinforced by the observed behavior that many of the variant commands in /usr/xpg4/bin support options which are simply rejected by the default variant; for instance, /usr/xpg4/bin/id supports a '-u' option; while /usr/bin/id rejects -u with an "illegal option" usage message. The heated discussion which followed made it clear that our strategy for standards compliance is not well understood among solaris developers as well as among solaris users & developers of applications for solaris. Selective cherry- picking is documented, but there is additionally a signifi- cant concern among a number of members of the Committee that the cherry-picking of complex commands which invoke other commands is of very limited applicability. Both ability to cherrypick and the limitations on this are not well expressed in our documentation, including the standards(5) man page. This led to the advice given in section 6.1. While conformance with the letter of the standards could be satisfied by changing /usr/bin/crontab's default editor to the first "vi" in $PATH, precedent as defined by [2] and [3] among other cases leads us to also deliver xpg4 and xpg6 variants to allow for cherry-picking. Several reviewers felt that this takes cherry-picking too far but there was no consensus among the committee to break with past precedent; a median view among the Committee is that any change to this strategy needs to involve significant review and considera- tion. 4.5. Gratuitous Divergence Obscures The Architecture The discussion also exposed significant divergence between our standards compliance architecture and its implementa- tion. In many cases, once a decision to "fork" a command was made, many new non-conflicting behaviors were integrated only into the xpgN variants. However, as a general rule, there should be no cases where a particular command feature, option, or the like accepted by a /usr/xpgN/bin variant should generate a syntax error when fed to the default sys- tem (/usr/bin) variant. This divergence has created both confusion about the overall architecture, and also substantially increases the need to cherry-pick specific commands in scripts. This degree of confusion is harmful to Solaris and to our users. When members of the community encounter such PSARC/2005/683 Copyright 2005 Sun Microsystems - 4 - divergence, they should file bugs against the commands in question, and should flag those bugs with the "missing-std- feature" keyword. 4.6. Examples Of Divergence Specific examples of divergence, where options and syntax are supported by an xpgN variant of a command and are rejected as syntax errors by the /usr/bin variant: 4.6.1. id -u, -g, -G, -n, and -r 4.6.2. grep -e, -f, -E, -F, and -q 4.6.3. tail -n and possibly -c 4.6.4. du -x 4.6.5. sh's lack of support for "export env=expr" and $(cmd) syntax. This is by no means a comprehensive list. DRAFT NOTE: By the time this opinion is submitted for PSARC review, bugs will have been filed to track these issues, and the bugids will be included in the opinion. Fixing these bugs, and identifying other inconsistencies is outside the scope of the case, but resulted in the advice given in section 6.2. 4.7. Heroic Compatibility Measures Unnecessary A proposal was made to suggest that any potential issue of script compatibility could be addressed by having crontab invoke "ed" if isatty(0) returned zero and "vi" if it returned nonzero. However, as there was no consensus that a patch binding was otherwise compatible with a change to the default editor spawned by the crontab command, these heroic measures were deemed unnecessary in a change with Minor release binding. 4.8. Proliferation of additional setuid commands Subsequent to the meeting, concern was expressed regarding the delivery of additional setuid variant commands; this concern was underscored by prior incidents where XPG4 vari- ants which were setuid had security holes not found in the default system variant. This was resolved by . PSARC/2005/683 Copyright 2005 Sun Microsystems - 5 - 5. Minority Opinion(s) No members voted to deny; however, a minority of the Commit- tee believe that the xpgN variants of the crontab push vari- ant cherry-picking beyond its actual usefulness. 6. Advisory Information 6.1. Improve standards(5) documentation relating to cherry-picking. The PAC should ensure that both our user-facing and our developer-facing process documentation relating to standards-related command variants is reviewed for clarity and approchability. 6.2. Repair Existing Gratuitous Divergence Unnecessarily divergent behavior between standards-compliant and default variants of the commands we ship in Solaris is a recurring source of irritation, confusion, and dissatisfac- tion. While each individual instance of divergence is minor, the cumulative impact is akin to that of a thousand paper cuts. Many of these fixes are likely to be small "starter" bugs appropriate for new developers, though subtleties requiring review from experienced engineers will abound. Engineers should be encouraged to fix these and other "irritant" bugs as they are found. 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/2005/683. 1. Amended specification. File: 2. PSARC 1994/161 XCU4 Conformance 3. PSARC 2000/492 Austin Group Common Revision of SUSv2 and POSIX Standards. PSARC/2005/683 Copyright 2005 Sun Microsystems From sacadmin Thu Dec 1 00:50:31 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jB18oUIQ021417 for ; Thu, 1 Dec 2005 00:50:30 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jB18oQCM026639; Thu, 1 Dec 2005 09:50:26 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jB18oQDk017712; Thu, 1 Dec 2005 09:50:26 +0100 (MET) Message-Id: <200512010850.jB18oQDk017712@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Don Cragun cc: PSARC@sac.sfbay.sun.com, Carol.Fields@Sun.COM Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683] In-Reply-To: <200511302324.jAUNOhJN008563@spartan.SFBay.Sun.COM> References: <200511302324.jAUNOhJN008563@spartan.SFBay.Sun.COM> Date: Thu, 01 Dec 2005 09:50:24 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 372 >If the user enters any of the above, the results should all be >similar. But, in the picky details of standards conformance, it does >matter if you make /usr/xpg4/bin/crontab be the shell script: > EDITOR=/usr/xpg4/bin/vi crontab So adding a "-E default editor" option would satisfy that constraint (running crontab -E /usr/xpg4/bin/vi "$@" from the script)? Casper From sacadmin Mon Dec 5 10:04:15 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jB5I4FIQ017418 for ; Mon, 5 Dec 2005 10:04:15 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id jB5I4Bk25169; Mon, 5 Dec 2005 11:04:11 -0700 (MST) Received: from sun.com (vpn-129-150-30-73.SFBay.Sun.COM [129.150.30.73]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jB5I48Dt303710; Mon, 5 Dec 2005 10:04:08 -0800 (PST) Message-ID: <43948111.1060003@sun.com> Date: Mon, 05 Dec 2005 10:04:01 -0800 From: Sherri Shieh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sun.com CC: carol.fields@sun.com, craig.payne@sun.com, Alan Coopersmith , mark.haywod@sun.com, "Terry (Sarito) Whatley" , Danek Duvall , stephen.hahn@sun.com Subject: PSARC Meeting Minutes 11/30/2005 Inception: 2005/683; Commitment: 2004/368; Discussion: Open Solaris Content-Type: multipart/mixed; boundary="------------000103050302040106030606" Status: RO This is a multi-part message in MIME format. --------------000103050302040106030606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, Meeting minutes for 11/30/2005 are now available and are attached. Also, audio files are available: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20051130.arcbiz.mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20051130.2005.683.inception.mp3 (3) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20051130.2004.368.commitment.mp3 (4) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20051130.OpenSolaris.discussion.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20051130.html If you have any corrections/feedback, please direc them to me. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, System Architecture ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------000103050302040106030606 Content-Type: text/plain; name="20051130.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="20051130.txt" SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 11/30/2005 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: yes (on sabbatical) Glenn Skinner: yes Robert Berube yes Andy Rudoff: no (on sabbatical) James Carlson: yes Shudong Zhou: yes Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes David Robinson no (on sabbatical) Sherri Shieh: yes ATTENDEES- Interns: Don Cragun: yes Peter Dennis: no (on sabbatical) Wyllys Ingersoll: no Rick Matthews: yes Alec Muffett: no (on sabbatical) James Falkner: no (on sabbatical) Kais Belgaied: no Phil Harman: no Calum Mackay yes (out for afternoon mtg) Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback yes Michael Haines no Sebastien Roy yes Alan Hargreaves yes GUESTS: Joel Buckman Carol Fields Jeop P. John Martin Craig Payne Alan Coopersmith Mark Haywood Terry Whatley JOhn Plocher Danek Douvall Stephen Hahn Bonnie Coreman --------------------------------------------------------------------------- AGENDA ------- 11/30/2005 (NOTE: there will be two meetings for this day) (morning meeting: will start at 10am PDT) 10:00-10:45 Discussion: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/cronta (2005/683) Submitter: Carol Fields Owner: Bill Sommerfeld (afternoon meeting: will start at 1pm PDT) 1:00-1:10 project id 1:10-1:20 ARC Business - case owner/intern for 2005/691 - case owner/intern for 2005/573 1:20-2:05 Commitment: Secure By Default, Phase I (2004/368) Submitter: Craig Payne Owner: Gary Winiger 2:05-2:50 Discussion: Brainstorming OpenSolaris and the ARCs Submitter: John Plocher, Stephen Hahn * What _do_ the OpenSolaris charter, governance and development process proposals currently say about the ARCs; what _should_ they say? Charter: http://www.opensolaris.org/jive/thread.jspa?threadID=3186&tstart=0 Governance: http://www.opensolaris.org/jive/thread.jspa?threadID=1341&tstart=29 http://www.opensolaris.org/jive/thread.jspa?threadID=1393&tstart=30 Dev Proc: http://www.opensolaris.org/os/community/onnv/os_dev_process/ * Brainstorming and discussion of what works, what should be done, logistics and infrastructure, etc: * Getting started - self-reviews and fasttracks from the community * Getting serious - full reviews and community membership * Are there differences between "today", "while we are in a transition", and "when we are done"? * If ARC membership comes from the set of community leaders because they are the stewards of their shared source-code commons, how are you involved with the OpenSolaris community? --------------------------------------------------------------------------- Case Anchors: 1) case 1:Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/cronta (2005/683)
2)case 2: Secure By Default, Phase I (2004/368)
3)case 3: Discussion: Brainstorming OpenSolaris and the ARCs
=========================================================================== ARC BUSINESS -------------- Fast tracks ----------- 2004/826 Opteron/Athlon64 Frequency Management Mark Haywood (was An waiting fast-track 11/30/2005 Terry Whatley * Spec was updated * Approved 2005/594 lock(1) - tty lock program Rich Teer waiting fast-track 10/19/2005 Darren Moffat * Gary asked for the final spec - hasn't seen it yet; Gary will follow up * pending the final spec * leave it - Sherri will let case owner to follow up 2005/617 Mars 1.0 Project Gary Morton waiting fast-track 11/23/2005 Darren Moffat * time needs to be extended - more time and need Gary's questions answered 2005/672 vold eof Artem Kachitchkin waiting fast-track 11/30/2005 Frits Vanderlinden * approved 2005/675 Mars 1.0 Linux support Gary Morton waiting fast-track 11/17/2005 Darren Moffat * concluded that the spec for this was based on the spec of 617...case dependency * Darren should updated this case and mark it closed - Sherri will ping Darren 2005/697 Tamale Data Protocol Extensions for Larg Farrell Woods waiting fast-track 11/23/2005 Bill Sommerfeld * still need contract * Approved 2005/698 Seattle/Boston Chassis Serial Number Sudhir Bhole waiting fast-track 11/23/2005 Bill Sommerfeld * still need contract * Approved 2005/703 Hostname interposer for applications on Ashutosh Tripathi waiting fast-track 11/28/2005 Ed Gould * All questions have been responded to * Why shouldn't this be a part of Solaris? * Approved 2005/706 SIGEV_THREAD and SIGEV_PORT Roger Faulkner waiting fast-track 12/05/2005 Roger Faulkner * Approved 2005/711 Zone move and clone Jerry Jelinek waiting fast-track 12/06/2005 Gerald Jelinek * More time 2005/371 * let it run * Times out: 12/07 Other Business -------------- - case owner/intern for 2005/691 12/14/2005 (DonC, EdG out) 45 min Inception: Trusted Extensions for Device Allocation (2005/691) Submitter: ashish.joshi@sun.com Owner: Bill Sommerfeld Intern: Alan Hargreaves - case owner/intern for 2005/573 12/21/2005 Inception: Solaris Trusted Extensions for Printing (2005/573) Submitter: glenn.faden@sun.com Owner: Intern: * Update him on the latest information - ask if he can do it in the beginning of the year =========================================================================== Discussion: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/cronta (2005/683) Submitter: Carol Fields Owner: Bill Sommerfeld SUMMARY ======= * Documentation is needed to be made extremely clear - the man pages should describe that a person can choose between standards. * TCR - project team is wiling to change the spec and changing ed to vi (in usr/bin) while invoking vi first on path. An opinion should be drafted that includes all the changes and conversation of what was said today. ISSUES ====== The following are extracted from the case's mail file. Some duplicates have been removed. These entries are in date order; not grouped by submitter. Responses to these issues are included on lines starting with "RESP". Jordan_Brown #1 Date: Fri, 11 Nov 2005 15:04:35 -0800 If I'm reading this right, the "violation" is that our crontab pays attention to $VISUAL, which is not specified by SUSv3. Right? RESP No. The violation is that the current default editor (if RESP neither $VISUAL nor $EDITOR are present in the environment) is RESP /usr/bin/ed. It should be /usr/xpg4/bin/vi if /usr/xpg4/bin is RESP in $PATH before /usr/xpg6/bin and /usr/bin; and it should be RESP /usr/xpg6/bin/vi if /usr/xpg6/bin is in $PATH before RESP /usr/xpg4/bin and /usr/bin. (This is still a slight RESP oversimplification of the rules, but it should be sufficient for RESP what we're discussing here.) Is it really a standards violation when a utility is affected by the setting of a non-standard environment variable? RESP No. (And this is one reason we are not making any changes to RESP /usr/bin/crontab.) RESP In theory, we could also allow $VISUAL to affect RESP /usr/xpg[46]/bin/crontab and still conform to the standards, but RESP we haven't done that with the other utilities in RESP /usr/xpg[46]/bin. Since these two directories are intended to RESP provide POSIX.2-1992 and XCU4 (and their successors) RESP conformance, we decided long ago not to provide attractive RESP nuisances that would be likely to generate complaints from RESP application writers who inherited a dirty environment that RESP affects the way their applications behave. (We frequently RESP provide compatible options that are extensions to the standards; RESP but we believe that overriding environment variables cross the RESP line.) If so, how do we reconcile this with our handling of, e.g., all of our $LD_* environment variables? Alan Coopersmith #1 Date: Fri, 11 Nov 2005 15:50:12 -0800 I don't suppose changing the default editor to /usr/bin/vi in /usr/bin/crontab is part of the plan? That's a seriously annoying default, and I seem to remember was a call generator back when I worked in tech support in the Solaris 2.4 days. RESP No. This case is strictly about fixing a standards conformance RESP problem. RESP The fact that /usr/bin/crontab invokes /usr/bin/ed is a binary RESP compatibility issue; not a standards conformance issue. (SVID3 RESP says crontab -e invokes an editor, but doesn't say which RESP editor.) There was a bug report pointing out that RESP /usr/bin/crontab -e invokes ed rather than vi; but the man page RESP has been fixed to make the documentation align with the RESP implementation, rather than changing the implementation to match RESP the documentation. RESP As a separate case, we could change /usr/bin/crontab to invoke RESP /usr/bin/vi rather than /usr/bin/ed; but that would not get rid RESP of the need for the changes suggested by this case. We still RESP need /usr/xpg4/bin/crontab -e to invoke /usr/xpg4/bin/vi and RESP /usr/xpg6/bin/crontab -e to invoke /usr/xpg6/bin/vi. Jordan_Brown #2 Date: Fri, 11 Nov 2005 16:44:32 -0800 Could we change the default to be "the first vi on $PATH"? RESP No. If a user's $PATH contains a non-standards-conforming vi RESP before /usr/xpg[46]/bin/vi when /usr/xpg[46]/bin comes before RESP /usr/bin in $PATH, we would not meet standards requirements. Bill Sommerfeld #1 Date: Fri, 11 Nov 2005 19:41:36 -0800 On Fri, 2005-11-11 at 17:06, Don Cragun wrote: > > > >Eww. Maybe it's time for Solaris to get into the 1980s and default to a > > "full screen" editor. > > I don't disagree. ;-} That just isn't this case. ;-{ It should be. we make our system incredibly more uneven when these "standards conformance" changes come along and improve the rarely-used /usr/xpgN/bin versions without also making comparable improvements to the versions in /usr/bin please change the /usr/bin/crontab default editor as part of this case. RESP Adding /usr/xpg[46]/bin/crontab and making them invoke RESP /usr/xpg[46]/bin/vi, respectively, is a standards conformance RESP issue. Changing the default editor used by /usr/bin/crontab RESP from /usr/bin/ed to /usr/bin/vi is not a standards conformance RESP issue and should be addressed as a separate issue. Casper Dik #1 Date: Sat, 12 Nov 2005 19:39:49 +0100 >If I'm reading this right, the "violation" is that our crontab pays >attention to $VISUAL, which is not specified by SUSv3. Right? > >Is it really a standards violation when a utility is affected by the >setting of a non-standard environment variable? > >If so, how do we reconcile this with our handling of, e.g., all of our >$LD_* environment variables? > >I would think that the moment that you set any non-standard environment >variable, you've departed the bounds of the standard. > >(Granted, the environment variable namespace is an awfully murky one, >with standard-defined names, platform-defined names, and user-defined >names living indistinguishably in the same namespace.) I agree with this; I think that the xpg4 and xpg6 directories are ugly warts (and why doesn't xpg4/bin/awk use the POSIX shell for system()?) RESP /usr/xpg4/bin/awk does use /usr/xpg4/bin/sh for system(). (The RESP makefile links in values-xpg4.o which causes this and many other RESP things to happen under the covers.) RESP Although the xpg[46] directories may be "ugly warts", some of RESP our customers really appreciate the flexibility they provide. RESP A large part of the value of standards is stability. Customers RESP appreciate knowing that even if a later standard comes along and RESP changes interfaces, library and utility incompatibilities will RESP be hidden from conforming applications as long as they don't RESP depend on extensions to the standards. Our customers also RESP appreciate that applications conforming to one standard can RESP invoke utilities (for their own use or to process interactive RESP user requests) conforming to a different standard seamlessly. RESP This ability is significantly reduced if there is a single RESP version of a utility that keys off of the order of /usr/bin (or RESP /bin), /usr/xpg4/bin, and /usr/xpg6/bin in $PATH. RESP The standards(5) man page describes how to set up an application RESP to use all of the utilities conforming to a specific set of RESP standards. There is nothing there (nor in the standards) that RESP requires that standards conforming utilities only be used in RESP that environment. We support a smorgasbord of standards and RESP allow users to choose the specific versions of those utilities RESP that meet their needs for any particular use. I'm sure some creative thinking can get rid of most of its use.. RESP The project team is not sure which "it" you mean??? Darren J Moffat #1 Date: Mon, 14 Nov 2005 11:54:31 +0000 I couldn't understand from the case materials why we need xpg4 and xpg6 variants to fix this issue, why can't we just fix /usr/bin/crontab ? RESP /usr/bin/ed, /usr/bin/vi, /usr/xpg4/bin/vi, and /usr/xpg6/bin/vi RESP are all different. /usr/xpg4/bin/crontab -e has to use RESP /usr/xpg4/bin/vi. /usr/xpg6/bin/crontab -e has to use RESP /usr/xpg6/bin/vi. /usr/bin/crontab -e is currently documented RESP to invoke /usr/bin/ed (and has done so since Solaris 2.0). If RESP we change /usr/bin/crontab -e to invoke /usr/bin/vi rather than RESP /usr/bin/ed, we still need /usr/xpg[46]/bin/crontab -e to invoke RESP /usr/xpg[46]/bin/vi, respectively. Bill Sommerfeld #2 Date: Mon, 14 Nov 2005 20:45:34 -0500 On Mon, 2005-11-14 at 20:19, Don Cragun wrote: > This case merely proposes implementing the behavior documented > on our standards(5) man page: > "Utilities > If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or > SUSv2 conflicts with historical Solaris utility behavior, > the original Solaris version of the utility is unchanged; this seems to me to be an overly restrictive interpretation of "conflicts". when the standard proposes an improvement and the change is reasonable we should run with it where possible. RESP A change from the non-visual /usr/bin/ed used by RESP /usr/bin/crontab to /usr/xpg[46]/bin/vi is a significant RESP conflict in the opinion of the project team. This RESP interpretation is what was agreed to in PSARC/1994/161 and RESP extended in PSARC/2000/492. Joseph Kowalski #1 Date: Mon, 14 Nov 2005 16:35:35 -1000 (HST) > On Mon, 2005-11-14 at 20:19, Don Cragun wrote: > > > This case merely proposes implementing the behavior documented > > on our standards(5) man page: > > "Utilities > > If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or > > SUSv2 conflicts with historical Solaris utility behavior, > > the original Solaris version of the utility is unchanged; > > this seems to me to be an overly restrictive interpretation of > "conflicts". > > when the standard proposes an improvement and the change is reasonable > we should run with it where possible. > > - Bill If "when possible" == "doesn't conflict with our stable definition", then please hit delete now. We are all in agreement (I believe). For 15 years we've run with the model that the Stable meaning we've given utilities trumps what a standards body might decide. I can understand suggesting a different model and running it up through TAC (yea, TAC), but let's not try to do that in the context of a fast-track. RESP The project team agrees. Bill Sommerfeld #3 Date: Mon, 14 Nov 2005 21:40:11 -0500 On Mon, 2005-11-14 at 21:35, Joseph Kowalski wrote: > If "when possible" == "doesn't conflict with our stable definition", > then please hit delete now. We are all in agreement (I believe). crontab(1) has a documented stability level of Standard, not Stable Bill Sommerfeld #4 Date: Mon, 14 Nov 2005 21:50:11 -0500 On Mon, 2005-11-14 at 21:40, Bill Sommerfeld wrote: > On Mon, 2005-11-14 at 21:35, Joseph Kowalski wrote: > > If "when possible" == "doesn't conflict with our stable definition", > > then please hit delete now. We are all in agreement (I believe). > > crontab(1) has a documented stability level of Standard, not Stable .. what's more, the crontab(1) man page is self-inconsistent, stating elsewhere: EDITOR Determine the editor to be invoked when the -e option is specified. The default editor is vi(1). (I checked as far back as 5.9. if it's been that way for at least 5 years and nobody's noticed and filed a man page bug about the inconsistency, that's evidence that the default editor used by crontab is not an Interface). RESP This inconsistency in the man page was the subject of CR RESP 6306391. The fix removing the inconsistency was integrated RESP Qugust 5, 2005. The change made was to document that ed is the RESP default editor. The default editor in /usr/bin/crontab has been RESP ed (not vi) since May 12, 1989. Jordan_Brown #3 Date: Mon, 14 Nov 2005 19:06:41 -0800 Jordan Brown wrote: > With respect to changing the default from "ed" to "vi", one might also > mention "not being hopelessly mired in the 1970s". I think you'd be > pretty hard-pressed to find any user in the world who would say that > using "ed" as the default is the right thing to do. Sigh. Having said that, it occurs to me that one might semi-reasonably write a shell script around "crontab -e" using ed. I wouldn't personally do it that way, but it wouldn't be silly. I'd probably still do it, but it wouldn't be patch-appropriate and it might merit a "What's new" note. RESP This is why the project team is saying that changing the default RESP editor for /usr/bin/crontab is an orthogonal issue and is not RESP suitable for a patch. Crating /usr/xpg[46]/bin/crontab is a RESP standards conformance issue and is, therefore, suitable for a RESP patch release. Bill Sommerfeld #5 Date: Mon, 14 Nov 2005 22:11:42 -0500 (EST) On Mon, 2005-11-14 at 22:06, Jordan Brown wrote: > I'd probably still do it, but it wouldn't be patch-appropriate and it > might merit a "What's new" note. Perhaps. But that view would also make the original proposal (adding /usr/xpgN/bin/crontab) not patch-appropriate, either. RESP No. It has always been appropriate to fix standards conformance RESP bugs in patch releases if we are asked to do so by customers. I'd argue that a robust script using crontab -e would set EDITOR first given the confusion in the man page and the fact that a bunch of relevant standards say the default editor is vi. RESP A bug in a man page is not, in and of itself, sufficient reason RESP to change an interface that has not changed for over 15 years. Casper Dik #2 Date: Tue, 15 Nov 2005 10:32:40 +0100 >Jordan Brown wrote: >> With respect to changing the default from "ed" to "vi", one might also >> mention "not being hopelessly mired in the 1970s". I think you'd be >> pretty hard-pressed to find any user in the world who would say that >> using "ed" as the default is the right thing to do. > >Sigh. Having said that, it occurs to me that one might semi-reasonably >write a shell script around "crontab -e" using ed. I wouldn't >personally do it that way, but it wouldn't be silly. Generally, you would set $EDITOR for that (I remember doing something similar for "edquota"; the $EDITOR was a script which did the editing). RESP The edquota(1M) man page says that $EDITOR specifies the editor RESP to be invoked; not a script that is used as input to an unnamed RESP editor. Bill Sommerfeld #6 Date: Tue, 15 Nov 2005 13:22:09 -0500 On Tue, 2005-11-15 at 12:30, Don Cragun wrote: > If neither $EDITOR nor $VISUAL are set, /usr/bin/crontab has > historically and is intended to continue to invoke /usr/bin/ed on the > appropriate user's crontab file when the -e option is specified. I believe it is inappropriate to add new /usr/xpgN/bin/* commands without taking a close look at whether it's appropriate to add the standards-required behaivor to the /usr/bin version. Historically we have not done a very careful job of this, and this leads to many percieved annoyances when there is no evidence that the existing behavior is either well-considered or required by a competing standard.. RESP The reason for having /usr/bin/crontab -e use ed is because RESP existing customer shell scripts may be depending on that RESP behavior. The reason for adding /usr/xpg[46]/bin/crontab is RESP standards conformance. It's clearly appropriate to change the default editor for /usr/bin/crontab and changing the default editor in the XPG4 and XPG6 environments without also changing it in the default environment introduces an unreasonable variance in behavior. RESP It is an unreasonable variance only if breaking customer shell RESP scripts doesn't matter. It is even more of an issue since we RESP may be required to patch this fix back into earlier releases. Joseph Kowalski #2 Date: Tue, 15 Nov 2005 10:42:23 -1000 (HST) > From: Bill Sommerfeld ... > I believe it is inappropriate to add new /usr/xpgN/bin/* commands > without taking a close look at whether it's appropriate to add the > standards-required behaivor to the /usr/bin version. > > Historically we have not done a very careful job of this, and this leads > to many percieved annoyances when there is no evidence that the existing > behavior is either well-considered or required by a competing standard.. > > It's clearly appropriate to change the default editor for > /usr/bin/crontab and changing the default editor in the XPG4 and XPG6 > environments without also changing it in the default environment > introduces an unreasonable variance in behavior. All true. RESP The project team disagrees on at least two of the above three RESP points. It seems like the sticking point is that the customer who noted the failure is intitled to relief in a patch/update. I think there are branding issues behind this. Maybe they can be worked. Maybe not. RESP The non-conformance issue was found internally and has not yet RESP been reported by a customer. If a customer does report the RESP problem we are legally required to provide a patch or relinquish RESP our UNIX brand and pay fines. Since several government RESP contracts that have sold machines to the US (and other) RESP governments have support clauses in them, failure to comply may RESP also lead to jail time for some Sun employees. It also seems that the changes you propose are appropriate for a Minor binding (or at least that's my opinion). RESP The project team agrees that changing /usr/bin/crontab -e to use RESP /usr/bin/vi rather than /usr/bin/ed is not appropriate in a RESP patch release. The core issue here seems to be the conflict in appropriate binding levels. - jek3 Joseph Kowalski #3 Date: Tue, 15 Nov 2005 10:45:14 -1000 (HST) > From: Don Cragun ... > Having /usr/bin/crontab change in this way cannot be done in a patch. > Adding /usr/xpg[46]/bin/crontab will have to be done in a patch if we > get a customer complaint about standards non-compliance. Just probing... Would it be possible to do what Bill is suggesting (with a Minor binding) with the understanding that we will do something with a patch binding if the customer complaint referred to above should happen? RESP It isn't clear to the project team what Bill wants. It could RESP either be: RESP 1. Create /usr/xpg4/bin/crontab (which invokes RESP /usr/xpg4/bin/vi) and /usr/xpg6/bin/crontab (which invokes RESP /usr/xpg6/bin/vi), and change /usr/bin/crontab to invoke RESP /usr/bin/vi rather than /usr/bin/ed. RESP Or, it could be: RESP 2. Change /usr/bin/crontab to invoke /usr/bin/vi rather than RESP /usr/bin/ed and assume that this conforms to POSIX.2, XPG4, RESP SUS, SUSv2, and SUSv3 requirements without creating RESP /usr/xpg[46]/bin/crontab. RESP If what Bill wants is #1, the project team believes we can RESP create /usr/xpg[46]/bin/crontab and patch them back into earlier RESP releases, and that we can modify /usr/bin/crontab to invoke vi RESP rather than ed but cannot patch this change back into earlier RESP releases. RESP If what Bill wants is #2, it will not fix the problem. RESP /usr/bin/vi does not meet standards conformance requirements RESP (and still can't be patched into earlier releases due to binary RESP compatibility issues between ed and vi). Joseph Kowalski #4 Date: Tue, 15 Nov 2005 12:02:56 -1000 (HST) > From: Don Cragun ... > >Just probing... > > > >Would it be possible to do what Bill is suggesting (with a Minor binding) > >with the understanding that we will do something with a patch binding if > >the customer complaint referred to above should happen? > > I repeat. This case is about adding /usr/xpg4/bin/crontab and > /usr/xpg6/bin/crontab to align with standards requirements. The > standards (and our way of doing things since at least Solaris release > 2.5) force us to create /usr/xpg[46]/bin/crontab. I don't agree. The algorithm (since well before 2.5) is: if the base utility can compatibly be made standard conformant do so else implement /usr//... I'm trying to probe the "if" condition. RESP /usr/bin/crontab currently uses /usr/bin/ed. As has already RESP been noted, there may be customer scripts that invoke crontab RESP using ed commands that will be broken if /usr/bin/crontab starts RESP using /usr/bin/vi rather than /usr/bin/ed. Therefore, your if RESP condition fails. Changing ed to vi is not a compatible change. The interesting bit here seems to be a belief that the base utility can be made standard conformant, but only in a minor release (due to our assesment of the seriousness of the incompatibility). RESP No. /usr/bin/crontab already conforms to SVID3 and XPG3. We RESP can change /usr/bin/crontab to use vi rather than ed (an RESP incompatible change) in a minor release if we want to. Doing so RESP won't affect SVID3 or XPG3 conformance. Making an incompatible RESP change to a "standard" interface not required by a standards RESP conformance problem is not allowed in a patch release. RESP The problem this case is addressing is that /usr/bin/crontab RESP doesn't conform to POSIX.2-1992, XPG4, SUS, SUSv2, or SUSv3. We RESP need to add /usr/xpg4/bin/crontab to conform to POSIX.2-1992, RESP SVID3, SUS, and SUSv2. We need to add /usr/xpg6/bin/crontab to RESP conform to SUSv3. RESP After splitting out /usr/xpg[46]/bin/crontab, changing RESP /usr/bin/crontab is an orthogonal issue and is not a standards RESP conformance issue. But, there is a binary compatibility issue RESP that precludes a patch binding for this change to RESP /usr/bin/crontab. > The addition of /usr/xpg[46]/bin/crontab is contractually required to > be delivered in a patch if a customer request or test suite update > complains about our standards non-conformance. Yes. Hence my final clause on what I was probing. Have the causal events you mention above actually happened? RESP No. Which is why the intro to this case said: RESP "I am submitting this fasttrack for Carol Fields. Carol RESP is seeking a patch release binding. Current plans are RESP to implement this is ONNV, but since this is a fix for a RESP standards violation, we will have to patch it back into RESP earlier releases if customers complain about the current RESP behavior." > A case to change the behavior of /usr/bin/crontab is an orthogonal > issue with a completely different set of arguments and a different > release binding. Furthermore, even if we do later change > /usr/bin/crontab to use vi rather than ed, it would be to use > /usr/bin/vi; not /usr/xpg4/bin/vi or /usr/xpg6/bin/vi. So, > /usr/xpg[46]/bin/crontab would still be needed for standards > conformance. These are orthogonal issues! Not orthogonal, but if we are contrained to use the standard based vi (which I think you asserted have trivial differences), then I see a reason that the base version can't be made standard conformant. If true, it would seem to end this discussion. RESP The project team agrees that SOME of the differences are RESP trivial; the project team does not believe that all of the RESP differences are trivial. We know that a test suite can easily RESP determine that /usr/xpg4/bin/vi doesn't meet SUSv3 requirements RESP and that /usr/xpg6/bin/vi doesn't meet XPG4, SUS or SUSv2 RESP requirements (and that /usr/bin/vi doesn't meet XPG4, SUS, RESP SUSv2, or SUSv3 requirements). The test suites catch these RESP differences when testing vi; they don't currently catch the RESP second order effects of vi meeting conformance requirements when RESP invoked indirectly through crontab. But, as we all know being RESP 99% standards conformant doesn't count; it is an all or nothing RESP proposition (at least for the standards under discussion for RESP this case). (Uh, is xpg4/bin/vi actually different from xpg6/bin/vi? Yes or no is fine) RESP Yes. > The desire to change /usr/bin/crontab -e to use vi rather than ed is an > arbitrary (although perhaps desirable) change that may break existing > customer shell scripts. Yep, hence the assertion about Minor binding. RESP Yes. The Minor binding only applies to changing RESP /usr/bin/crontab's editor of choice; it does not apply to RESP splitting /usr/xpg[46]/bin/crontab out from /usr/bin/crontab and RESP having them invoke /usr/xpg[46]/bin/vi, respectively, as RESP required by standards approved during or after 1992. Casper Dik #3 Date: Wed, 16 Nov 2005 00:00:33 +0100 >/usr/bin/crontab currently uses /usr/bin/ed. As has already been noted >at least twice, there may be customer scripts that invoke crontab with >here-documents consisting of ed commands that will be broken if >/usr/bin/crontab starts using /usr/bin/vi rather than /usr/bin/ed. >Therefore, your if condition fails. Changing ed to vi is not a >compatible change. Furthermore, since XPG3 and SVID3 (the standards >specifying /usr/bin utility behavior) do not require an incompatible >change in behavior, I do not believe /usr/bin/crontab changes are the >subject of this case. I've only seen this noticed *once* that there *may* be scripts with *here* documents. RESP Scripts were mentioned in message numbers 23, 25, 28, and 40 RESP before the quote above from message number 42. They didn't RESP however explicitly mention here-documents. Whether the editor RESP input comes from a here-document or from input redirected from a RESP file doesn't matter for this discussion. It seems that we can easily fix that issue by using fairly simple logic like: editor = getenv("VISUAL"); if (editor == NULL) editor = getenv("EDITOR"); if (editor == NULL) editor = isatty(0) ? "vi" : "ed"; If stdin is a tty, then there's no here document.... RESP Yes, this meets the scripting requirement. Nonetheless, it RESP still changes the interactive user interface in a manner that is RESP not appropriate in a patch. David Robinson #1 Date: Tue, 15 Nov 2005 17:32:53 -0600 [from the wings...] On Nov 15, 2005, at 4:51 PM, Don Cragun wrote: > No. No! No!!! /usr/bin/crontab already conforms to SVID3 and XPG3. > We can change /usr/bin/crontab to use vi rather than ed (an > incompatible change) in a minor release if we want to. Doing so won't > affect SVID3 or XPG3 conformance. Making an incompatible change to a > "standard" interface not required by a standards conformance problem is > not allowed in a patch release. I may be wrong, but what I think I am hearing people say is: Yes, you are correct that making the change in a patch is not strictly allowed. But in this case, 'we' think it is OK and since 'we' are the ones that make the rules and exception can be made. Other than the fact that changing /usr/bin/crontab is against existing policy, I think I have heard anything that prevents the proposed changes from being be made in /usr/bin/crontab. The project team is rightfully not proposing that (probably in a futile attempt to avoid this whole discussion in the first place). So if I see things correctly it boils down to a simple decision tree: if (PSARC thinks this is worth an exception to the patch rule) put changes in /usr/bin/crontab else put changes in /usr/xpg*/crontab as proposed. RESP No. The project team has repeatedly stated that putting the RESP changes some members have requested in /usr/bin/crontab is not RESP sufficient to meet standards conformance requirements. RESP /usr/xpg[46]/bin/crontab still need to be added. In theory one could appeal PSARC's decision as well. RESP Understood. Bill Sommerfeld #7 Date: Tue, 15 Nov 2005 18:45:21 -0500 On Tue, 2005-11-15 at 18:25, Joseph Kowalski wrote: > Since you are stating that the proposed answer is wrong (for whatever > reason), could you state simply what you think the right answer is? > (in this specific case, not general terms) All instances of crontab delivered in solaris should invoke "the same" editor if VISUAL and EDITOR are not set. I've reviewed a sample of the #ifdef XPG*'s in the vi source and, based on that review, consider /usr/bin/vi, /usr/xpg4/bin/vi and /usr/xpg6/bin/vi to be "the same" -- the differences between them appear to largely consist of little fiddly details which are dwarfed by the large-scale differences between vi and ed. I'm willing to hold my nose and allow the specific change to /usr/bin/crontab to only be given Minor release binding even if the others are given Patch binding, particularly since there are no actual plans to backport. But, for consistency, I'd prefer to see the same release binding for both. RESP The project team doesn't understand "both" in the above. RESP You have said you only want /usr/bin/crontab (no RESP /usr/xpg4/bin/crontab nor /usr/xpg6/bin/crontab) and that RESP /usr/bin/crontab must invoke a single version of vi. RESP You have declared that "fiddly details" of differences between RESP /usr/bin/vi, /usr/xpg4/bin/vi, and /usr/xpg6/bin/vi don't RESP matter. The project team vehemently disagrees. We know that RESP test suites can and do detect the fiddly details of these RESP differences. Just because the test suites aren't currently RESP running those tests when vi is invoked by crontab doesn't mean RESP that they won't do so later. RESP Furthermore, the case law established by PSARC/1994/161 and RESP PSARC/2000/492 indicate that the proper fix for this standards RESP conformance issue is to create /usr/xpg4/bin/crontab and RESP /usr/xpg6/bin/crontab. James Carlson #1 Date: Tue, 15 Nov 2005 18:50:31 -0500 David Robinson writes: > So if I see things correctly it boils down to a simple > decision tree: > > if (PSARC thinks this is worth an exception to the patch rule) > put changes in /usr/bin/crontab > else > put changes in /usr/xpg*/crontab as proposed. > > In theory one could appeal PSARC's decision as well. > > So what does PSARC think? I don't know that PSARC thinks (or, if so, then what), but I think you've got that right. RESP No. This has already been commented on above. Especially with Casper's suggestion of checking isatty, the change seems fairly obviously acceptable (and welcome!) even in a patch, and since the standards also (essentially) dictate how $PATH must be constructed to maintain compliance, we end up killing several birds with one stone. I mostly agree with Bill that we ought to try harder to avoid letting base Solaris drift too far from the standards, and to avoid populating those /usr/xpg*/bin/ directories with excessive numbers of variants. Neither does us good in the long run. RESP There is a trade off between backwards compatibility and RESP maintaining as small a footprint as possible. The project team RESP would like to get more feedback from PSARC on where the line RESP should be drawn. Historically, backwards compatibility has been RESP a paramount concern. Bill Sommerfeld #8 Date: Tue, 15 Nov 2005 19:32:42 -0500 On Tue, 2005-11-15 at 18:56, Joseph Kowalski wrote: > I don't think standards bodies view those "fiddly details" in the same > light you do ... It depends on the standards body. The IETF expressly rejects conformance tests because (among other reasons), they cause a focus on details which causes implementors to lose sight of the big picture - you can pass a conformance test but still have an unusable implementation that won't talk to anything but the conformance tester. The big picture here is that divergence between different sub-environments on solaris is bad. This case proposed to introduce just such a divergence when there is, in my opinion at least, ample room to make the change in a way which doesn't create a divergence. RESP No. Unlike IETF, POSIX conformance and UNIX branding are based RESP on conformance tests as indicators of compliance. (Passing the RESP test suite doesn't mean the implementation conforms, but failing RESP the test suite does mean the implementation doesn't conform!) RESP Furthermore, since lots of government contracts require RESP conformance to a particular version of a standard (which may now RESP be 20 years old), having simultaneous conformance to several RESP versions of the standards is a valuable selling point in many RESP cases. > I was thinking down a similar path: Why can't /usr/xpg6/bin/vi be the > one "true" editor? (Other than I believe its in an optional package). > I believe that finding out that the xpg4 and xpg6 versions were different > harpooned that idea. What's even more bizarre is that, in a bunch of places, xpg4's vi diverges from solaris traditional behavior, while xpg6 doesn't: #ifdef XPG4ONLY setcount2(); donewline(); #else /* XPG6 and Solaris */ setCNL(); #endif /* XPG4ONLY */ (I'm not sure I want to know why this can't be handled as a bug in XPG4). RESP The main point is stability of the programming interface defined RESP by the standard. Fortunately for application writers, and RESP unfortunately for system implementors, once the next revision of RESP a POSIX or XPG standard is approved the prior version is pretty RESP much cast in concrete unless it can be shown that the old RESP standard enables a security hole. Bill Sommerfeld #9 Date: Tue, 15 Nov 2005 19:46:27 -0500 On Tue, 2005-11-15 at 19:41, Joseph Kowalski wrote: > I'm much less involved with this stuff now, but when I was involved > we made every effort for avoid gratuitous divergence. I have no reason > to think things are different now. I keep stumbling across places where the /usr/bin command complains of a syntax error for something accepted by the /usr/xpgN/bin version. RESP The basic philosophy is that if a new feature/option/behavior RESP can be implemented in the /usr/bin version without breaking RESP existing applications, it is added in the /usr/bin version. If RESP you find cases where this has not been done, file a bug. (Note, RESP however, that the commands and libraries team treats binary RESP compatibility and standards conformance as paramount; "fiddly RESP details" matter in this realm.) Jordan_Brown #1 Date: Tue, 15 Nov 2005 17:59:33 -0800 [ I'm trying to shut up and, as usual, failing. Sigh. ] Don Cragun wrote: > A case to change the behavior of /usr/bin/crontab is an orthogonal > issue with a completely different set of arguments and a different > release binding. Suppose for a moment we assume that it's acceptable to change the behavior of /usr/bin/crontab so that it runs vi by default. Can we enumerate the standards-compliance issues that would remain? I'm not sure, but I think the list is 1. *which* vi does it run? 2. It pays attention to $VISUAL, which the standard doesn't discuss. Anything else? RESP Not that the project team is aware of at this time. But, we RESP seem to disagree on whether it is appropriate to change the RESP default editor from ed to vi in /usr/bin/crontab in a patch RESP release. > Furthermore, even if we do later change > /usr/bin/crontab to use vi rather than ed, it would be to use > /usr/bin/vi; not /usr/xpg4/bin/vi or /usr/xpg6/bin/vi. So, > /usr/xpg[46]/bin/crontab would still be needed for standards > conformance. Is this really true? Suppose that the behavior would be much as it is today, that it runs system("vi") or equivalent and so gets the first vi in your $PATH. With our rules for $PATH settings for standards conformance, would that yield standards-acceptable behavior? Do the standards say anything about the behavior of standards-conformant applications when $PATH includes a different version of the application before the standard version? RESP Yes. it is really true! RESP If you find $HOME/bin/vi (or any other vi that doesn't conform RESP to the standard you're using at the moment) in your PATH before RESP /usr/bin, /usr/xpg4/bin, and /usr/xpg6/bin then crontab will not RESP conform to POSIX.2-1992, XPG4, SUS, SUSv2, nor POSIX.1-2001 if RESP crontab executes the first vi it finds in $PATH. If "the first one in $PATH" isn't acceptable, then I'm a bit concerned about the implications. It would seem that we would need /usr/xpg* versions of every single application that invokes an underlying application, because at some number of levels of invocation lower there might be an application where the /usr/xpg* version is different from the /usr/bin version. Suppose we have /usr/bin/xxx, which is standards conformant without requiring a /usr/xpg*/bin variant. It invokes yyy, which is also standards conformant without requiring a /usr/xpg*/bin variant. That in turn invokes zzz, for which /usr/bin/zzz is *not* standards conformant, and *does* need a /usr/xpg*/bin variant. In "XPG mode", yyy must somehow invoke /usr/xpg4/bin/zzz. If that's not through $PATH searching, how does it happen? It seems that it'd need a /usr/xpg*/bin/yyy. But then, in XPG mode, xxx must invoke /usr/xpg*/bin/yyy instead of /usr/bin/yyy. That in turn means that there must be a separate /usr/xpg*/bin/xxx. It seems like that way lies madness, and I think it's exactly what you're suggesting here. No one step would be insane, but the path to the Dark Side is a series of small steps, each reasonable in and of itself. (OK, I just watched SW3RotS again last night :-) RESP The "first one in $PATH" isn't acceptable. Although the twisty RESP passages you describe could happen in theory, it doesn't happen RESP much in practice. In practice the shell and the editors are the RESP only common issues. Less common are differences in the RESP underlying libc. (In fact, system() and popen() in libc choose RESP the appropriate shell based on compilation options which takes RESP care of a lot of this under the covers.) Casper Dik #4 Date: Wed, 16 Nov 2005 10:34:59 +0100 >Suppose for a moment we assume that it's acceptable to change the >behavior of /usr/bin/crontab so that it runs vi by default. Can we >enumerate the standards-compliance issues that would remain? > >I'm not sure, but I think the list is > >1. *which* vi does it run? The first one found in $PATH. If xpg4/6 compliance requires those to be first in the PATH it will find the "proper" vi. RESP Neither XPG4 nor XPG6 require that the user not include another RESP vi in $PATH to make crontab find the correct default editor. >2. It pays attention to $VISUAL, which the standard doesn't discuss. Which isn't a problem, as far as I can tell (as noted, all Solaris applications change their behaviour under non-standard environment variables) >Is this really true? Suppose that the behavior would be much as it is >today, that it runs system("vi") or equivalent and so gets the first vi >in your $PATH. With our rules for $PATH settings for standards >conformance, would that yield standards-acceptable behavior? Do the >standards say anything about the behavior of standards-conformant >applications when $PATH includes a different version of the application >before the standard version? I would think so. RESP No. /usr/xpg4/bin/crontab needs to default to /usr/xpg4/bin/vi RESP and /usr/xpg6/bin/crontab needs to default to /usr/xpg6/bin/vi RESP to conform to the standards no matter how $PATH is set when RESP crontab is invoked. Joseph Kowalski #5 Date: Wed, 16 Nov 2005 07:17:24 -1000 (HST) > From: Casper.Dik@Sun.COM ... > >1. *which* vi does it run? > > The first one found in $PATH. If xpg4/6 compliance requires those to > be first in the PATH it will find the "proper" vi. Don can comment, but I suspect the PATH setting isn't a requirement. Both of the following should work: /usr/xpg4/bin/crontab PATH=/usr/xpg4/bin:$PATH crontab I believe being able to pick an choose an individual xpg4 utility implementation is a requirement. If its not, it should be. RESP Joe is correct! Casper Dik #5 Date: Wed, 16 Nov 2005 18:22:05 +0100 > >> From: Casper.Dik@Sun.COM >... >> >1. *which* vi does it run? >> >> The first one found in $PATH. If xpg4/6 compliance requires those to >> be first in the PATH it will find the "proper" vi. > >Don can comment, but I suspect the PATH setting isn't a requirement. Both >of the following should work: > > /usr/xpg4/bin/crontab Surely such a call is *not* standards conformant? The standard does not prescribe these paths so standard conforming programs cannot use them. RESP Not true. You need a starting point to define $PATH. If you RESP set $PATH as specified by standards(5) and then invoke: RESP getconf PATH RESP you get back a $PATH that can be used to find utilities that RESP implement conformance to that standard. An application is then RESP free to parse that PATH setting to get the absolute pathname of RESP any utilility specified by the standard and invoke it directly. > PATH=/usr/xpg4/bin:$PATH crontab This, I think, looks like the only viable way to get standards conforming behaviour. RESP No!!! Putting /usr/xpg4/bin in front of your current $PATH does RESP not guarantee that you will find standards conforming versions RESP of any utility that we don't happen to put in /usr/xpg4/bin. >I believe being able to pick an choose an individual xpg4 utility implementation >is a requirement. If its not, it should be. Is that a requirement for standards conformance? RESP No. It has been a feature of Solaris 2.0 and later releases. James Carlson #2 Date: Wed, 16 Nov 2005 12:28:32 -0500 Joseph Kowalski writes: > > The first one found in $PATH. If xpg4/6 compliance requires those to > > be first in the PATH it will find the "proper" vi. > > Don can comment, but I suspect the PATH setting isn't a requirement. Both > of the following should work: [...] A snippet from standards(5): An application that wants to use standard-conforming utili- tues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) environment variable to specify the directories listed in the following table in the order specified to get the appropriate utilities: [...] POSIX.2, POSIX.2a, SUS, SUSv2, XPG4 1. /usr/xpg4/bin [...] POSIX.1-2001, SUSv3 1. /usr/xpg6/bin 2. /usr/xpg4/bin RESP Note that using csh is not specified by any of the standards we RESP are discussing. All this man page says is that if you set PATH RESP or path as specified here, the utilities you find will conform RESP to the corresponding standard for any utility specified by that RESP standard. There is no requirement that once you find a utility RESP on this path that PATH or path must be set this way for that RESP utility to behave as specified by the standards. Bill Sommerfeld #10 Date: Wed, 16 Nov 2005 13:11:07 -0500 On Wed, 2005-11-16 at 12:41, Jordan Brown wrote: > Joseph Kowalski wrote: > > Don can comment, but I suspect the PATH setting isn't a requirement. Both > > of the following should work: > > > > /usr/xpg4/bin/crontab > > > > PATH=/usr/xpg4/bin:$PATH crontab > > > > I believe being able to pick an choose an individual xpg4 utility implementation > > is a requirement. If its not, it should be. > > It seems a little hard to believe that the standards per se would have > such a requirement, since (I presume) they don't have a concept of the > existence of non-standard variants. *Solaris* might impose such a > requirement, as part of our mechanisms for supporting both the standards > and our own proprietary behavior. > > I'm concerned that this way lies madness, because then you'd have to > require that xpg* variants invoke only other xpg* variants. Like I said > in an earlier message, allowing an xpg* variant to invoke a /usr/bin > variant (even when that variant is xpg* compliant) could eventually lead > to executing a /usr/bin variant that's not xpg* compliant. We're seeing > exactly that concern here, a concern that even if /usr/bin/crontab was > itself xpg* compliant it would be broken because it wouldn't invoke the > xpg* version of vi. > > In fact, you'd have to require xpg* variants of every application that > invokes an underlying application, so that there's always a way to run > the application in "xpg*-compliant" mode. Plus, since the user > shouldn't know which applications can invoke underlying applications, > you'd need xpg* variants of *everything* listed in xpg*. Not to mention the need to do surgery on every single "portable" shell script to add #! /usr/xpg4/bin/sh at the top. RESP This is a red herring. Adding #! /usr/xpg4/bin/sh to the top RESP of a script means that that shell is to be run with a shell that RESP conforms to the requirements of POSIX.2-1992, XPG4, SUS, and RESP SUSv2. That doesn't indicate that the script is portable and RESP doesn't indicate that the commands executed by that shell (other RESP than shell built-ins) are expected to behave as documented in RESP that same set of standards. Joseph Kowalski #6 Date: Wed, 16 Nov 2005 08:24:53 -1000 (HST) > From: Casper.Dik@Sun.COM ... > >Don can comment, but I suspect the PATH setting isn't a requirement. Both > >of the following should work: > > > > /usr/xpg4/bin/crontab > > Surely such a call is *not* standards conformant? > > The standard does not prescribe these paths so standard conforming programs > cannot use them. Interesting point. We've now reach maximal velocity on my head spinning. My view is that such a call is not standard conformant, but that such a call would/should be supported by our implementation. Put another way, I think its a rather important feature, not to be done away with lightly. > > PATH=/usr/xpg4/bin:$PATH crontab > > This, I think, looks like the only viable way to get standards conforming > behaviour. > > >I believe being able to pick an choose an individual xpg4 utility implementation > >is a requirement. If its not, it should be. > > Is that a requirement for standards conformance? As above, **probably** not. I believe it is an obvious and benefical attribute of our current implementation (assuming it is, and bugs seem to indicate it might not be, but bug is the key word here). - jek3 Joseph Kowalski #7 Date: Wed, 16 Nov 2005 08:31:29 -1000 (HST) Well, that's pretty convincing.... 8^) > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Date: Wed, 16 Nov 2005 12:28:32 -0500 > From: James Carlson > To: Joseph Kowalski > Cc: Jordan.Brown@sun.com, Casper.Dik@sun.com, Don.Cragun@sun.com, Joseph.Kowalski@sun.com, Carol.Fields@sun.com, PSARC@sac.sfbay.sun.com > Subject: Re: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab [PSARC/2005/683 Timeout: 11/18/2005] > > Joseph Kowalski writes: > > > The first one found in $PATH. If xpg4/6 compliance requires those to > > > be first in the PATH it will find the "proper" vi. > > > > Don can comment, but I suspect the PATH setting isn't a requirement. Both > > of the following should work: > [...] > > A snippet from standards(5): > > An application that wants to use standard-conforming utili- > tues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) > environment variable to specify the directories listed in > the following table in the order specified to get the > appropriate utilities: > [...] > POSIX.2, POSIX.2a, > SUS, SUSv2, XPG4 1. /usr/xpg4/bin > [...] > POSIX.1-2001, SUSv3 > 1. /usr/xpg6/bin > > > 2. /usr/xpg4/bin > > > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Casper Dik #6 Date: Wed, 16 Nov 2005 19:59:00 +0100 >Joseph Kowalski writes: >> > The first one found in $PATH. If xpg4/6 compliance requires those to >> > be first in the PATH it will find the "proper" vi. >> >> Don can comment, but I suspect the PATH setting isn't a requirement. Both >> of the following should work: >[...] > >A snippet from standards(5): > > An application that wants to use standard-conforming utili- > tues must set the PATH (sh(1) or ksh(1)) or path (csh(1)) > environment variable to specify the directories listed in > the following table in the order specified to get the > appropriate utilities: >[...] > POSIX.2, POSIX.2a, > SUS, SUSv2, XPG4 1. /usr/xpg4/bin >[...] > POSIX.1-2001, SUSv3 > 1. /usr/xpg6/bin > > > 2. /usr/xpg4/bin > But not call: /usr/xpg4/bin/crontab As the PATH is explicitely required to be set here, I assume using fill pathnames is not supported. RESP No! James Carlson #3 Date: Wed, 16 Nov 2005 14:03:28 -0500 Casper.Dik@Sun.COM writes: > But not call: > > /usr/xpg4/bin/crontab > > As the PATH is explicitely required to be set here, I assume using > fill pathnames is not supported. I don't think anybody cares if you run /usr/xpg4/bin/crontab. The point is that Solaris itself (in standards(5)) *requires* you to set PATH in a particular way when you want to be in a standards-conformant environment. RESP No. Solaris requires that /bin, /usr/bin, /usr/xpg4/bin, RESP /usr/xpg6/bin, and /usr/ucb be set in $PATH (or for csh in RESP $path) before other directories that contain any utility name RESP specified by the standard you are using to choose your command RESP set in order to find the correct version of the utilities RESP specified by the appropriate standard. Once you have found the RESP utility you want, there is no requirement that $PATH (or $path) RESP be set in any particular way for that utility to work correctly. And that *required* PATH would certainly allow the implementor of crontab to do the equivalent of system("vi") without worry. It is guaranteed to pick up the right "vi" in all cases. RESP No. The libc system() uses /usr/bin/sh, /usr/xpg4/bin/sh, or RESP /usr/xpg6/bin/sh depending on how your application was linked. RESP But the choice of which vi to use is determined by which version RESP of crontab you invoke; not by the setting of $PATH. Thus, there's no need to differentiate among 'crontab' variants purely on the path of vi. The only reason to do it would be for the ed/vi split, and there are at least a few of us who feel that switching to vi (perhaps with your isatty(0) test first) would be something to consider. RESP The project team still believes that the ed/vi choice for RESP /usr/bin/crontab is an orthogonal issue, but for this discussion RESP it just doesn't matter. This particular 'ed' doesn't have a lot of friends. :-> RESP No comment. 8-> Casper Dik #7 Date: Wed, 16 Nov 2005 20:19:12 +0100 >As above, **probably** not. > >I believe it is an obvious and benefical attribute of our current implementation >(assuming it is, and bugs seem to indicate it might not be, but bug is the >key word here). You can't really have a standards compliant version by just running /usr/xpg4/bin/path. RESP If by "path" you mean "utility_name", yes, you can. E.g., awk will not run the proper system("vi") and such. RESP The awk utility has no option nor environment variables to RESP invoke an editor. /usr/xpg4/bin/awk's system() function, RESP however, will use /usr/xpg4/bin/sh to evaluate it's argument no RESP matter how $PATH is set when awk is invoked. I'm not sure what the meaning of these executables is without $PATH set. RESP The only meaning for $PATH when any standard utility is invoked RESP is to choose where to find user specified utilities invoked by RESP that utility. When the standard specifies a version of a RESP utility to be invoked, $PATH isn't used. Date: Wed, 16 Nov 2005 16:48:39 -0500 James Carlson #4 Don Cragun writes: > Yes, either of the forms Joe gave (deleted in this snippet) should > work. IBM, HP, and some of our customers believe that Solaris provides > the gold standard of simultaneous conformance to multiple utility and > system interface standards. I hate that some members of PSARC want to > dismantle these features. Furthermore, until we implement the LSB, [...] What? No, that's not it at all. Nobody here is suggesting dismantling any features. What we *are* suggesting is minimizing the number of artifacts we introduce. Fewer are better. Please don't confuse one for the other. Asking to make sure that the split is in fact _required_ in any particular case (and that there's no other way to comply) is not equivalent to a desire to "dismantle" the standards or our support for them. RESP The project team disagrees. We have had a way of RESP simultaneously conforming to POSIX.2-1992, SCD, SVID3, SUS, RESP SUSv2, SUSv3, XPG3, XPG4, the System V ABIs, etc. that involves RESP creating new versions of utilities in a different ``bin'' RESP directory when a standard comes along that conflicts with RESP previous compatible standards. This is how we got /usr/ucb, RESP /usr/xpg4/bin, and /usr/xpg6/bin. This case is a trivial RESP example where we need to create /usr/xpg4/bin and /usr/xpg6/bin RESP variants of /usr/bin/crontab to be compatible with the RESP standards and the way Solaris has supported conflicting utility RESP requirements for almost twenty years. But, some PSARC members RESP have decided that supporting multiple versions of standards is RESP bad and have declared that doing so creates "artifacts" and RESP that "artifacts" are bad. RESP If creating /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab is RESP bad, then everything in /usr/xpg4/bin and /usr/xpg6/bin should RESP be discarded and all of the differences implemented there RESP should be provided by the /usr/bin versions of these utilities RESP with the behavior governed only by the setting of $PATH. This RESP overturns the decisions previously approved by PSARC/1994/161 RESP and PSARC/2000/492. The project team wants to treat all RESP standards conforming utilities the same way. Having crontab RESP reside only in /usr/bin and key off of $PATH while having sh RESP reside in /usr/bin and /usr/xpg4/bin, and while having awk RESP reside in /usr/bin, /usr/xpg4/bin, and /usr/xpg6/bin and RESP disregarding $PATH presents an arbitrary inconsistency that RESP will be impossible to explain logically to customers. RESP Redoing all of the utilities in /usr/xpg[46]/bin and the RESP related documentation changes is a huge project for which there RESP is no funding. Creating a major inconsistency in behavior is RESP not a viable option. Changing direction like this is RESP dismantling a set of standards conformnce features that many of RESP our customers do depend upon. gw-0 5 line summary please. RESP The XPG4-conforming crontab -e needs default to an RESP XPG4-conforming vi. The XPG6-conforming crontab -e needs RESP default to an XPG6-conforming vi. This case proposes to do RESP both by creating /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab. wes-0 [RESPONSE] once again, *NOBODY* is requesting that we dismantle our standards compliance. I derailed this case not so much because of the *specific* issues in this case as in the growing sense our strategy for standards compliance has been problematic for developers. Over the past couple years I have had a number of conversations with open-source developers in which the primary gripe was about how many of the commands in /usr/bin yield syntax errors rather than accepting a particular well-known, standards-compliant syntax. RESP And those syntax errors would break scripts that depend on SVID3 RESP syntax. Our current ARC supported position is that our default RESP (/usr/bin) utility set conforms to SVID3 and provides upwards RESP compatible extensions. It invariably turns out that the version in /usr/xpg4/bin accepts this. But because the string "/usr/xpg4" is a solarisism, these developers are extremely reluctant to embed it into portable scripts and code. (I can expand on this at somewhat more length during the call..) Moreover, our observed behavior in all of these cases is that, once we have realized the need to "fork" a command between /usr/bin and an alternate path, some additional variation in behavior creeps in over time. RESP The stated goal of the Solaris KISS BU353 Utilities and RESP Libraries group is to provide compatible extensions to RESP /usr/bin, /usr/xpg4/bin, and /usr/xpg6/bin versions of any RESP utility when doing so does not break binary compatibility and RESP does not violate appropriate underlying standards. Please file RESP bugs if you believe this goal has not been followed. Any unnecessary divergence between /usr/xpgN/bin and /usr/bin is a recurring irritation for developers. In the discussion in this case so far, there does not seem to be anything resembling consensus on whether changing the default editor for /usr/bin/crontab should be part of this case or a separate issue. While the project team views changing the default editor for /usr/bin/crontab as a "significant conflict", this appears to be another case where the ARC is willing to be more flexible than the project team. RESP No. The project team believes that this case is about making RESP crontab -e conform to POSIX.2-1992, XPG4, SUS, SUSv2, and SUSv3 RESP requirements. The project team believes that changing the RESP default System V default behavior of using ed to use vi instead RESP is a perfectly reasonable, but separate case. Now, it may be the case that a change to the default system /usr/bin/crontab to exec "vi" is not compatible with a Patch binding, but that should not serve as a barrier to having *this* case integrate a change to /usr/bin/crontab to use "vi". RESP Standards conformance bug fixes by definition have patch RESP binding. Changing the 20+ year default behavior of RESP /usr/bin/crontab to use /usr/bin/vi rather than /usr/bin/ed RESP seems to the project team to require a minor binding. RESP Therefore, the project team believes making this change is a RESP separate issue that should not be bundled into this case. RESP Furthermore, changing /usr/bin/crontab to use /usr/bin/vi RESP doesn't address the POSIX.2-1992, XPG4, SUS, SUSv2, and SUSv3 RESP standards conformance issues. I have *not* seen significant objection to the notion that this sort of change is incompatible with a Minor release binding, and it's certainly much smaller than some of the other changes which have crept in under a Minor binding. RESP The project team agrees that changing the default editor for RESP /usr/bin/crontab -e from ed to vi is compatible with a Minor RESP release binding. It is clear that there is, at present, merely the possibility that this change may need to be backported. But should one emerge, and should the consensus of PSARC be that a change to the default editor of /usr/bin/crontab is incompatible with a Patch binding, I see no reason to block the delivery of /usr/xpgN/bin variants of crontab in a patch. wes-1 Does any standard to which we cite compliance require some variant of "ed" to be the default editor spawned by "crontab -e"? If so, which? RESP No. wes-2 Does any standard to which we cite compliance specify the use of "/usr/xpg4/bin" or "/usr/xpg6/bin", or is this merely the way we implement those standards in Solaris? RESP It is merely the way we implement those standards as approved in RESP PSARC cases 1994/161 [XCU4 Conformance (XPG4 Commands/Utilities RESP component)] and 2000/492 [Austin Group Common Revision of SUSv2 RESP and POSIX Standards]. wes-3 (response to "Joseph Kowalski #3"): "It isn't clear to the project team what Bill wants" My bottom line: Avoid unnecessary divergence between /usr/bin and XPGN variants. RESP The project team agrees comletely (although there may be some RESP discrepancy on the definition of unnecessary). More specifically, as part of this project, in the next Minor release, all variants of "crontab -e" should invoke some variant of "vi" in the absence of any environment variables suggesting a different editor. RESP The project team has no problem making /usr/bin/crontab -e RESP default to using /usr/bin/vi rather than /usr/bin/ed as a RESP separate RFE fix as long as this fix is done with a Minor RESP release binding. The project team doesn't understand why that RESP is part of this case. The intent of CR 6344121 was to fix a RESP standards conformance bug, not to change the historical default RESP editor. I'm flexible beyond this; I suspect your confusion stems from my attempts to explore what's actually required by standards vs. our practices so far of implementing standards compliance. RESP The project team's confusion is based on not understanding: RESP 1. why has a simple standards standards conformance bug fix for RESP CR 6344121 that aligns with decisions approved by PSARC RESP cases 1994/161 and 2000/492 was not approved without RESP discussion, RESP 2. why changing the default editor used by /usr/bin/crontab RESP (which is not a standards conformance issue) has been tied RESP onto this case, and RESP 3. why some members of PSARC argue that no one is talking about RESP dismantling standards conformance when mail in case has RESP requested that /usr/xpg4/bin and /usr/xpg6/bin be RESP eliminated. * BillS: There were questions about the standards and the default editor but they have been answered. * No single version of vi meets the standards, which has been stated quite a bit already. * EdG: I'm having problems understanding what standards conformance means at this point...what's the mechanism in which the right vi gets invoked in the standards today? - JimC: The standard requires when you run crontab that you get the right behavior. - DonC: I'm not too sure which one gets invoked - I would have to go and take a look at it. - Shudong: How do we tell people how to set up this standard conformance? As I see it, you're not required to split the binary. * This is set in standards 5 and it also states that you must set this as a standard. * Crucial Question: Do we want to follow prior standards all the way or do we want to say that crontab -e is different that all other prior standards? Do we want to systematically change everything or have everything be standards conformance? - Opinion fodder or advice - One option: Crontab case be the first step in minimizing things. We stick with the statement that is documented. If you seperately choose to invoke the standards binary and not invoke the standard enviornment, then you get what you get. - Full case or full project? First big issue --------------- * Do we need to deliver multiple deliverance of crontab? - For strict standards compliant, the answer is no. But for past practice the answer should be yes. - JimC: If we're going to go through all the trouble of splitting everything up, shouldn't we document it in the man pages? I don't think it has been documented enough or clear enough. ** Documentation is needed to be made extremely clear - the man pages should describe that a person can choose between standards. * Are there things in the standards that provide shell escapes? Staw vote: should we put advisory about documentation and everything else that was said? no - glenn, gary, shudong, jim, joe, bob, bill abstain - ed Second big issue ----------------- * In the next minor release binding, should the standards required behavior be changed from ed to vi? Should we patch this (the creation of ... which would invoke vi)? - Is the project team ready to expand their case? - Proposal: Project team changes ed to vi (in usr/bin) while invoking vi first on path...is the project team willing to modify the case this way? * This would be a minor release binding Straw vote: TCR - extend original spec (spec change), advisory and opinion fodder to add crontab and that vi is on the first inpath, with a minor binding VOTE ==== * Voting on: First vi inpath in crontab, yes - ed, bill, bob, joe, jim, gary, glenn, shudong no - abstain - NEXT STEP ========= * The spec will be updated and a draft opinion will be written to include all changes and what was said in today's meeting. * Case was approved - waiting need opinion =========================================================================== Commitment: Secure By Default, Phase I (2004/368) Submitter: Craig Payne Owner: Gary Winiger SUMMARY ======= * Micro release binding for S10 with a question * Minor release binding without a question and is dependent upon LSARC 2005/... and it converging * Updating the 20 questions * Spec update to take care of the nits * Best practices update ISSUES ====== gw-5 Nits: (hopefully the committee will agree ;-) Interface Tables * the entry for the SMF upgrade file should read: /var/svc/profile/upgrade Contracted Project Private P 2002/547 * the entry for cde-ttdbserver is duplicated. * the entries for meta, metamed, metah are unrelated to L 2004/811 and will be corrected. * the entry svc:/applications/graphical-login/dtlogin/config/request_port is an exported interface from this project and is not defined in L 2004/811 * authorizations don't seem to have a stated taxonomy and many authorization strings were never arced auth_attr(4) was introduced in PSARC/1997/332 as Evolving. Presumably the authorization strings are at lease Evolving. It seems reasonable that the help files would be internal. * guidelines: the astring for the value_authorization should read 'solaris.smf.value.myservice' gw-6 questionaire #4. What is meant by ``SSH: root only via PAM''? * The project team states that the question asks about authentication - root login is allowed on the console. `SSH: root only via PAM'' is supposed to be the other way around. This should be updated. jdc-6 Many of the FMRIs are Unstable and some (such as svc:/network/rpc/calendar-manager:udp) seem to be gone from the system. How will these interfaces be kept in sync? (Related: should we just establish a rule that such interfaces can never be Unstable in the first place?) * For the FMRI that is defined by this case, the project team doesn't see how they cannot make these evolving. The p-team could raise the stability level with some restrictions. - Gary: Look at the guidelines to make the changes to the interfaces. jdc-7 [wes-1 follow-up] Doesn't more need to be done here? A new Big Rule is needed to stop future projects (ARC cases) from enabling anything by default, or we'll just need to do this project again in the future when more on-by-default things integrate. * Yes, more should be done and there should be something here that will stop future cases. This is more of a "soon to be written" best practice that will be part of the Greenline project. - Future cases should not be allowed and 20 questions should also be updated. Bill and Gary will work offline on this. The security questionnaire should be re-worded to make it less overbearing. jdc-8 Minor failure mode: if you're using LOG_FROM_REMOTE and your preference gets uploaded to SMF on upgrade, then reimporting the manifest will have the surprising effect of deleting previously-requested syslogd configuration. (Perhaps no good way exists to avoid compatibility breaks as we SMF-ize existing configuration.) * This case is kind of unavoidable. The project team is not changing the behavior of syslogd but if it is a fresh install, then the default does change. * Gary: On an initial install will anything be different on the SE default file? - Default file itself does not change and remains the same. The comments in the file will be extended to reflect the new reality in the initial install case. gw-7 svc:/applications/graphical-login/dtlogin config/request_port doesn't exist. Should this project use dtlogin/args? Should it create a new property config/local_only for th service? * The project team will use the existing arg property. wes-6 my understanding is that the existing miniroot contains some (disabled by default) services which can be enabled when needed for debugging. will these still be present? could sshd be substituted? (Talk to Jan Setje-Eilers; he had some strong opinions about this). * This is disabled right now in the miniroot. There would be no services enabled during the miniroot install. The project team is not planning on enabling anything extra at this point. They will go back and talk with Jan about this issue. wes-7 anyone other than me have strong opinions on which box should be checked by default in the s10 update screen? handsoff jumpstart configs clearly should behave the same, but if we have to ask, user interaction is required either way... * The default setting of the checkbox should match the default behavior - meaning you should get the same result of the jumpstart install and the initial install as well. VOTE ===== yes - glenn, bill, ed, bob, jim, shudong, gary no - abstain - NP - NEXT STEP ========= * Case has been approved. * Waiting need spec =========================================================================== Discussion: Brainstorming OpenSolaris and the ARCs Submitter: John Plocher, Stephen Hahn * What _do_ the OpenSolaris charter, governance and development process proposals currently say about the ARCs; what _should_ they say? Charter: http://www.opensolaris.org/jive/thread.jspa?threadID=3186&tstart=0 Governance: http://www.opensolaris.org/jive/thread.jspa?threadID=1341&tstart=29 http://www.opensolaris.org/jive/thread.jspa?threadID=1393&tstart=30 Dev Proc: http://www.opensolaris.org/os/community/onnv/os_dev_process/ * Brainstorming and discussion of what works, what should be done, logistics and infrastructure, etc: * Getting started - self-reviews and fasttracks from the community * Getting serious - full reviews and community membership * Are there differences between "today", "while we are in a transition", and "when we are done"? * If ARC membership comes from the set of community leaders because they are the stewards of their shared source-code commons, how are you involved with the OpenSolaris community? SUMMARY ======= * There is a lot of discussion about Open Solaris and trying to get other external people to be a part of all this. UPDATE: * There is a draft/charter out there to trying to get the advsory board to accept this. * Draft Development Process: ARC would be the key step to get this started Please check audio file for more information about this discussion: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20051130.OpenSolaris.discussion.mp3 ISSUES ====== * Brainstorming and discussion of what works, what should be done, logistics and infrastructure, etc: * Getting started - self-reviews and fasttracks from the community * Getting serious - full reviews and community membership * Are there differences between "today", "while we are in a transition", and "when we are done"? * If ARC membership comes from the set of community leaders because they are the stewards of their shared source-code commons, how are you involved with the OpenSolaris community? NEXT STEP ========= * The next discussion will tentatively be at the beginning of the new year. --------------000103050302040106030606-- From sacadmin Mon Jan 30 11:21:41 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0UJLeIQ010327 for ; Mon, 30 Jan 2006 11:21:40 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0UJLZWa001655; Mon, 30 Jan 2006 14:21:35 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k0UJLZcn011575; Mon, 30 Jan 2006 14:21:35 -0500 (EST) Subject: 2005/683 crontab -e opinion for PSARC review. From: Bill Sommerfeld To: psarc@sac.eng.sun.com Cc: Carol Fields Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1138648894.10376.24.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.330 Date: Mon, 30 Jan 2006 14:21:35 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 11187 PSARC review timer expires 2/6/2006. - Bill sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab Submitted by: Carol Fields File: PSARC/2005/683/opinion.ms Date: November 30th, 2005 Committee: Bill Sommerfeld, Robert Berube Jr, James D Carlson, Ed Gould, Joseph Kowalski, Glenn Skinner, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac-opinion@Sun.COM 1. Summary This project proposed to deliver xpg4 and xpg6 variants of the "crontab" command which invoke the xpg4 and xpg6 vari- ants of "vi" as their default editors. In addition, the project will deliver a change to the /usr/bin variant of crontab to use "vi" rather than "ed" as the default editor. 2. Decision & Precedence Information This project is approved as specified in references [1] and [2]. The entirety of this project may be delivered in a Minor release of the Solaris OS. In addition, the two xpg vari- ants of crontab may be delivered in a Patch release of the Solaris OS. PSARC/2005/683 Copyright 2005 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. __________________________________________________________ | Interfaces Exported | |_____________________|________________|_________________| |Interface | Classification| Comments | |_____________________|________________|_________________| |/usr/xpg4/bin/crontab| Standard | XPG4 behavior | |/usr/xpg6/bin/crontab| Standard | XPG6 behavior | |/usr/bin/crontab | Standard | change default| | | | editor from ed| | | | to vi to paral-| | | | lel XPG| | | | behavior | |_____________________|________________|_________________| 4. Opinion 4.1. Background During the era of SunOS 4.1, our standards-compliance approach relied exclusively on the setting of $PATH. Based on customer feedback, we subsequently added the additional ability for users to "cherry-pick" specific commands from the variant directories. At present, we document a combined approach: setting $PATH as specified in standards(5) for a complete standards-compliant environment, and, in addition, variant forms of individual commands are documented by path- name in the individual command manpages. 4.2. Original Proposal The original proposal left the existing behavior of /usr/bin/crontab -e unchanged, using the first "ed" in $PATH as the default editor. 4.3. Amendment Several reviewers expressed concern with the divergence in behavor between /usr/bin and xpgN variants introduced by this case. The project team accepted a suggestion during the meeting to amend the spec to add, in addition to the delivery with Patch binding of the xpg4 and xpg6 variants of crontab, a change with Minor release binding to /usr/bin/crontab to use the first vi on $PATH as the default editor. 4.4. Standards Strategy Unclear To Many Additionally, several reviewers expressed concern with the PSARC/2005/683 Copyright 2005 Sun Microsystems - 3 - slowly growing proliferation of additional variant commands in the /usr/xpg4/bin and /usr/xpg6/bin directories, trig- gered solely by the behavior of a spawned subprocess. This concern was reinforced by the observed behavior that many of the variant commands in /usr/xpg4/bin support options which are simply rejected by the default variant; for instance, /usr/xpg4/bin/id supports a '-u' option; while /usr/bin/id rejects -u with an "illegal option" usage message. The heated discussion which followed made it clear that our strategy for standards compliance is not well understood among solaris developers as well as among solaris users & developers of applications for solaris. Selective cherry- picking is documented, but there is additionally a signifi- cant concern among a number of members of the Committee that the cherry-picking of complex commands which invoke other commands is of very limited applicability. Both ability to cherrypick and the limitations on this are not well expressed in our documentation, including the standards(5) man page. This led to the advice given in section 6.1. While conformance with the letter of the standards could be satisfied by changing /usr/bin/crontab's default editor to the first "vi" in $PATH, precedent as defined by [3] and [4] among other cases leads us to also deliver xpg4 and xpg6 variants to allow for cherry-picking. Several reviewers felt that this takes cherry-picking too far but there was no consensus among the committee to break with past precedent; a median view among the Committee is that any change to this strategy needs to involve significant review and considera- tion. 4.5. Gratuitous Divergence Obscures The Architecture The discussion also exposed significant divergence between our standards compliance architecture and its implementa- tion. In many cases, once a decision to "fork" a command was made, many new non-conflicting behaviors were integrated only into the xpgN variants. However, as a general rule, there should be no cases where a particular command feature, option, or the like accepted by a /usr/xpgN/bin variant should generate a syntax error when fed to the default sys- tem (/usr/bin) variant. This divergence has created both confusion about the overall architecture, and also substantially increases the need to cherry-pick specific commands in scripts. This degree of confusion is harmful to Solaris and to our users. When members of the community encounter such diver- gence, they should file bugs against the commands in ques- tion, and should flag those bugs with the "missing-std- feature" keyword. PSARC/2005/683 Copyright 2005 Sun Microsystems - 4 - 4.6. Examples Of Divergence Specific examples of divergence, where options and syntax are supported by an xpgN variant of a command and are rejected as syntax errors by the /usr/bin variant: 4.6.1. id -u, -g, -G, -n, and -r 4521640 *id* /usr/bin/id missing options from /usr/xpg4/bin/id 4.6.2. grep -e, -f, -q, -x, -E, and -F 4843344 *grep* should have -q, -e, -f, -x, -E, and -F options 4.6.3. tail -n and possibly -c 6231496 *tail* non-XPG4 tail could support -n and pos- sibly -c 4.6.4. du -x 6269516 *du* should always accept -x 4.6.5. sh's lack of support for "export env=expr", $(cmd) syntax, and other non-conflicting POSIX syntax.[1] 6378708 *sh* could implement non-conflicting posix syn- tax This is by no means a comprehensive list. Fixing these bugs, and identifying other inconsistencies is outside the scope of the case, but resulted in the advice given in section 6.2. _________________________ [1] One early reviewer of this opinion questioned the appropriateness of including this point, as the existing "/bin/sh" implementation is largely unrelated to the codebase used for the /usr/xpgN/bin shells. This is true, and will be a significant obstacle to fixing this problem, but it is a matter of resource allocation, not architecture. It is also the case that the limitations of the existing "sh" are a recurring source of irritation to newcomers to solaris and barrier to adoption by some. Finding the proper approach and balance here will be difficult. PSARC/2005/683 Copyright 2005 Sun Microsystems - 5 - 4.7. Heroic Compatibility Measures Unnecessary A proposal was made to suggest that any potential issue of script compatibility could be addressed by having crontab invoke "ed" if isatty(0) returned zero and "vi" if it returned nonzero. However, as there was no consensus that a patch binding was otherwise compatible with a change to the default editor spawned by the crontab command, these heroic measures were deemed unnecessary in a change with Minor release binding. 4.8. Proliferation of additional setuid commands Subsequent to the meeting, concern was expressed regarding the delivery of additional setuid variant commands; this concern was underscored by prior incidents where XPG4 vari- ants which were setuid had security holes not found in the default system variant. The specific problem was caused by linking with values-xpg4.o and values-xpg6.o, exposing dif- ferent interfaces in the variant executables. The current implementation plan is to deliver three setuid executables, none of which will be linked with values- xpg?.o, mitigating this risk. Whether or not any specific crontab executable is setuid is best thought of as an imple- mentation detail, not any sort of Public interface. 5. Minority Opinion(s) No members voted to deny; however, several members of the Committee believe that the xpgN variants of the crontab push variant cherry-picking beyond its actual usefulness. 6. Advisory Information 6.1. Improve standards(5) documentation relating to cherry-picking. The PAC should ensure that both our user-facing and our developer-facing process documentation relating to standards-related command variants is reviewed for clarity and approchability. 6.2. Repair Existing Gratuitous Divergence Unnecessarily divergent behavior between standards-compliant and default variants of the commands we ship in Solaris is a recurring source of irritation, confusion, and dissatisfac- tion. While each individual instance of divergence is minor, the cumulative impact is akin to that of a thousand paper cuts. Many of these fixes are likely to be small "starter" bugs appropriate for new developers, though subtleties requiring review from experienced engineers will PSARC/2005/683 Copyright 2005 Sun Microsystems - 6 - abound. Engineers should be encouraged to fix these and other "irritant" bugs as they are found. 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/2005/683. 1. Amended specification. File: final.spec 2. crontab(1) man page. File: final/crontab.1 3. PSARC 1994/161 XCU4 Conformance 4. PSARC 2000/492 Austin Group Common Revision of SUSv2 and POSIX Standards. PSARC/2005/683 Copyright 2005 Sun Microsystems From sacadmin Fri Feb 3 17:24:25 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k141OOIQ005872 for ; Fri, 3 Feb 2006 17:24:24 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k141ONH0015166; Fri, 3 Feb 2006 20:24:23 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k141ONn5003782; Fri, 3 Feb 2006 20:24:23 -0500 (EST) Subject: Re: 2005/683 crontab -e opinion for PSARC review. From: Bill Sommerfeld To: psarc@sac.eng.sun.com Cc: Carol Fields In-Reply-To: <1138648894.10376.24.camel@thunk> References: <1138648894.10376.24.camel@thunk> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1139016262.1761.358.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.330 Date: Fri, 03 Feb 2006 20:24:23 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3027 On Mon, 2006-01-30 at 14:21, Bill Sommerfeld wrote: > PSARC review timer expires 2/6/2006. I posted a relevant short excerpt of the draft opinion to several of the opensolaris.org lists and received one comment from Peter Tribble: > From: Peter Tribble > Subject: Re: [approach-discuss] Re: [arc-discuss] Re: Two (hopefully) minor > suggestions > In-reply-to: <1138650086.10376.40.camel@thunk> > To: Bill Sommerfeld > Cc: Alan Coopersmith , arc-discuss@opensolaris.org, Eric Boutilier , approach-discuss@opensolaris.org > >> However, as a general rule, there should be no cases where a >> particular command feature, option, or the like accepted by a >> /usr/xpgN/bin variant should generate a syntax error when fed to the >> default system (/usr/bin) variant. > > What about the other way round? Suppose a useful option were > added to the /usr/bin version, should I expect it to always > work with the /usr/xpgN/bin variant? > > Take, as an example, du: > > /usr/xpg4/bin/du: illegal option -- j > usage: du [-a] [-h|-k] [-r] [-s] [-x] [-H|-L] [file ...] > > /usr/bin/du: illegal option -- j > usage: du [-a] [-d] [-h|-k] [-r] [-o|-s] [-H|-L] [file ...] > > Now, one has -x, the other -d. They both mean the same thing. > The above rule means that -x should be added to /usr/bin/du. > (I've done this once, and need to follow up on it.) But should > -d be added to the xpg4 variant? Should -o? What if I wanted > to add an extra flag? > > Certainly having everything both ways would be a great advantage, > as it would reduce the barriers to using the xpg4 variants. > -- > -Peter Tribble > L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ I agree with his point and made the following change to the .ms source: *** /tmp/sccs.wBaaAl Fri Feb 3 17:21:31 2006 --- opinion.ms Fri Feb 3 17:15:48 2006 *************** *** 324,330 **** However, as a general rule, there should be no cases where a particular command feature, option, or the like accepted by a /usr/xpgN/bin variant should generate a syntax error when fed to the ! default system (/usr/bin) variant. .LP This divergence has created both confusion about the overall architecture, and also substantially increases the need to cherry-pick --- 324,333 ---- However, as a general rule, there should be no cases where a particular command feature, option, or the like accepted by a /usr/xpgN/bin variant should generate a syntax error when fed to the ! default system (/usr/bin) variant; similarly, non-conflicting features ! found in the default system variant should generally be present in any ! /usr/xpgN/bin variant unless they conflict with the requirements of ! the relevant standards. .LP This divergence has created both confusion about the overall architecture, and also substantially increases the need to cherry-pick - Bill From sac-owner Thu Feb 9 15:35:00 2006 Received: from localhost.SFBay.Sun.COM (d-mpk17-109-10.SFBay.Sun.COM [129.146.109.10]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k19NZ0IQ007039 for ; Thu, 9 Feb 2006 15:35:00 -0800 (PST) Received: from localhost.SFBay.Sun.COM (localhost [127.0.0.1]) by localhost.SFBay.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id k19NXtRo002449; Thu, 9 Feb 2006 15:33:55 -0800 (PST) Received: (from sommerfeld@localhost) by localhost.SFBay.Sun.COM (8.13.4+Sun/8.13.4/Submit) id k19NXtp8002448; Thu, 9 Feb 2006 15:33:55 -0800 (PST) X-Authentication-Warning: localhost.SFBay.Sun.COM: sommerfeld set sender to sommerfeld@sun.com using -f Subject: PSARC 2005/683 crontab -e opinion for SAC review. From: Bill Sommerfeld To: sac-review@sac.eng.sun.com Cc: Carol.Fields@sun.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 09 Feb 2006 15:33:55 -0800 Message-Id: <1139528035.2028.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Status: RO Content-Length: 11647 SAC review timer expires 2/16/2006. sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab Submitted by: Carol Fields File: PSARC/2005/683/opinion.ms Date: November 30th, 2005 Committee: Bill Sommerfeld, Robert Berube Jr, James D Carlson, Ed Gould, Joseph Kowalski, Glenn Skinner, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac-opinion@Sun.COM 1. Summary This project proposed to deliver xpg4 and xpg6 variants of the "crontab" command which invoke the xpg4 and xpg6 vari- ants of "vi" as their default editors. In addition, the project will deliver a change to the /usr/bin variant of crontab to use "vi" rather than "ed" as the default editor. 2. Decision & Precedence Information This project is approved as specified in references [1] and [2]. The entirety of this project may be delivered in a Minor release of the Solaris OS. In addition, the two xpg vari- ants of crontab may be delivered in a Patch release of the Solaris OS. PSARC/2005/683 Copyright 2005 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. __________________________________________________________ | Interfaces Exported | |_____________________|________________|_________________| |Interface | Classification| Comments | |_____________________|________________|_________________| |/usr/xpg4/bin/crontab| Standard | XPG4 behavior | |/usr/xpg6/bin/crontab| Standard | XPG6 behavior | |/usr/bin/crontab | Standard | change default| | | | editor from ed| | | | to vi to paral-| | | | lel XPG| | | | behavior | |_____________________|________________|_________________| 4. Opinion 4.1. Background During the era of SunOS 4.1, our standards-compliance approach relied exclusively on the setting of $PATH. Based on customer feedback, we subsequently added the additional ability for users to "cherry-pick" specific commands from the variant directories. At present, we document a combined approach: setting $PATH as specified in standards(5) for a complete standards-compliant environment, and, in addition, variant forms of individual commands are documented by path- name in the individual command manpages. 4.2. Original Proposal The original proposal left the existing behavior of /usr/bin/crontab -e unchanged, using the first "ed" in $PATH as the default editor. 4.3. Amendment Several reviewers expressed concern with the divergence in behavor between /usr/bin and xpgN variants introduced by this case. The project team accepted a suggestion during the meeting to amend the spec to add, in addition to the delivery with Patch binding of the xpg4 and xpg6 variants of crontab, a change with Minor release binding to /usr/bin/crontab to use the first vi on $PATH as the default editor. 4.4. Standards Strategy Unclear To Many Additionally, several reviewers expressed concern with the PSARC/2005/683 Copyright 2005 Sun Microsystems - 3 - slowly growing proliferation of additional variant commands in the /usr/xpg4/bin and /usr/xpg6/bin directories, trig- gered solely by the behavior of a spawned subprocess. This concern was reinforced by the observed behavior that many of the variant commands in /usr/xpg4/bin support options which are simply rejected by the default variant; for instance, /usr/xpg4/bin/id supports a '-u' option; while /usr/bin/id rejects -u with an "illegal option" usage message. The heated discussion which followed made it clear that our strategy for standards compliance is not well understood among solaris developers as well as among solaris users & developers of applications for solaris. Selective cherry- picking is documented, but there is additionally a signifi- cant concern among a number of members of the Committee that the cherry-picking of complex commands which invoke other commands is of very limited applicability. Both ability to cherrypick and the limitations on this are not well expressed in our documentation, including the standards(5) man page. This led to the advice given in section 6.1. While conformance with the letter of the standards could be satisfied by changing /usr/bin/crontab's default editor to the first "vi" in $PATH, precedent as defined by [3] and [4] among other cases leads us to also deliver xpg4 and xpg6 variants to allow for cherry-picking. Several reviewers felt that this takes cherry-picking too far but there was no consensus among the committee to break with past precedent; a median view among the Committee is that any change to this strategy needs to involve significant review and considera- tion. 4.5. Gratuitous Divergence Obscures The Architecture The discussion also exposed significant divergence between our standards compliance architecture and its implementa- tion. In many cases, once a decision to "fork" a command was made, many new non-conflicting behaviors were integrated only into the xpgN variants. However, as a general rule, there should be no cases where a particular command feature, option, or the like accepted by a /usr/xpgN/bin variant should generate a syntax error when fed to the default sys- tem (/usr/bin) variant; similarly, non-conflicting features found in the default system variant should generally be present in any /usr/xpgN/bin variant unless they conflict with the requirements of the relevant standards.[1] _________________________ [1] Whenever possible we should also attempt to head off future unresolvable divergence by avoiding new changes to the default system variant of a command which are known to conflict with a relevant standard. PSARC/2005/683 Copyright 2005 Sun Microsystems - 4 - This divergence has created both confusion about the overall architecture, and also substantially increases the need to cherry-pick specific command variants in scripts. This degree of confusion is harmful to Solaris and to our users. When members of the community encounter such diver- gence, they should file bugs against the commands in ques- tion, and should flag those bugs with the "missing-std- feature" keyword. 4.6. Examples Of Divergence Specific examples of divergence, where options and syntax are supported by an xpgN variant of a command and are rejected as syntax errors by the /usr/bin variant: 4.6.1. id -u, -g, -G, -n, and -r 4521640 *id* /usr/bin/id missing options from /usr/xpg4/bin/id 4.6.2. grep -e, -f, -q, -x, -E, and -F 4843344 *grep* should have -q, -e, -f, -x, -E, and -F options 4.6.3. tail -n and possibly -c 6231496 *tail* non-XPG4 tail could support -n and pos- sibly -c 4.6.4. du -x 6269516 *du* should always accept -x 4.6.5. sh's lack of support for "export env=expr", $(cmd) syntax, and other non-conflicting POSIX syntax.[2] 6378708 *sh* could implement non-conflicting posix syn- tax _________________________ [2] One early reviewer of this opinion questioned the appropriateness of including this point, as the existing "/bin/sh" implementation is largely unrelated to the codebase used for the /usr/xpgN/bin shells. This is true, and will be a significant obstacle to fixing this problem, but it is a matter of resource allocation, not architecture. It is also the case that the limitations of the existing "sh" are a recurring source of irritation to newcomers to solaris and barrier to adoption by some. Finding the proper approach and balance here will be difficult. PSARC/2005/683 Copyright 2005 Sun Microsystems - 5 - This is by no means a comprehensive list. Fixing these bugs, and identifying other inconsistencies is outside the scope of the case, but resulted in the advice given in section 6.2. 4.7. Heroic Compatibility Measures Unnecessary A proposal was made to suggest that any potential issue of script compatibility could be addressed by having crontab invoke "ed" if isatty(0) returned zero and "vi" if it returned nonzero. However, as there was no consensus that a patch binding was otherwise compatible with a change to the default editor spawned by the crontab command, these heroic measures were deemed unnecessary in a change with Minor release binding. 4.8. Proliferation of additional setuid commands Subsequent to the meeting, concern was expressed regarding the delivery of additional setuid variant commands; this concern was underscored by prior incidents where XPG4 vari- ants which were setuid had security holes not found in the default system variant. The specific problem was caused by linking with values-xpg4.o and values-xpg6.o, exposing dif- ferent interfaces in the variant executables. The current implementation plan is to deliver three setuid executables, none of which will be linked with values- xpg?.o, mitigating this risk. Whether or not any specific crontab executable is setuid is best thought of as an imple- mentation detail, not any sort of Public interface. 5. Minority Opinion(s) No members voted to deny; however, several members of the Committee believe that the xpgN variants of the crontab push variant cherry-picking beyond its actual usefulness. 6. Advisory Information 6.1. Improve standards(5) documentation relating to cherry-picking. The PAC should ensure that both our user-facing and our developer-facing process documentation relating to standards-related command variants is reviewed for clarity and approchability. 6.2. Repair Existing Gratuitous Divergence Unnecessarily divergent behavior between standards-compliant PSARC/2005/683 Copyright 2005 Sun Microsystems - 6 - and default variants of the commands we ship in Solaris is a recurring source of irritation, confusion, and dissatisfac- tion. While each individual instance of divergence is minor, the cumulative impact is akin to that of a thousand paper cuts. Many of these fixes are likely to be small "starter" bugs appropriate for new developers, though subtleties requiring review from experienced engineers will abound. Engineers should be encouraged to fix these and other "irritant" bugs as they are found. 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/2005/683. 1. Amended specification. File: final.spec 2. crontab(1) man page. File: final/crontab.1 3. PSARC 1994/161 XCU4 Conformance 4. PSARC 2000/492 Austin Group Common Revision of SUSv2 and POSIX Standards. PSARC/2005/683 Copyright 2005 Sun Microsystems From sac-owner Thu Mar 16 13:24:08 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2GLO8IQ027704 for ; Thu, 16 Mar 2006 13:24:08 -0800 (PST) Received: (from noaccess@localhost) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) id k2GLO7H07338 for sac-opinion-not-2b-used-directly; Thu, 16 Mar 2006 14:24:07 -0700 (MST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2GLO7m07329; Thu, 16 Mar 2006 14:24:07 -0700 (MST) 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 <0IW800007OS7KO00@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Mar 2006 13:24:07 -0800 (PST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IW800HYUOS6WAF0@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Mar 2006 13:24:06 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2GLO5bB026262; Thu, 16 Mar 2006 16:24:05 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2GLO580027096; Thu, 16 Mar 2006 16:24:05 -0500 (EST) Date: Thu, 16 Mar 2006 16:24:05 -0500 From: Bill Sommerfeld Subject: PSARC 2005/683 Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab To: sac-opinion@sun.com Message-id: <1142544245.26152.238.camel@thunk> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 11873 [resend #2 with corrected address. my brain is not working today] For opinion archival. (N.B.: this case clarifies and restates precedent regarding the relationship between XPGn command variants and the default system version found in /usr/bin) --------- sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab Submitted by: Carol Fields File: PSARC/2005/683/opinion.ms Date: November 30th, 2005 Committee: Bill Sommerfeld, Robert Berube Jr, James D Carlson, Ed Gould, Joseph Kowalski, Glenn Skinner, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac-opinion@Sun.COM 1. Summary This project proposed to deliver xpg4 and xpg6 variants of the "crontab" command which invoke the xpg4 and xpg6 vari- ants of "vi" as their default editors. In addition, the project will deliver a change to the /usr/bin variant of crontab to use "vi" rather than "ed" as the default editor. 2. Decision & Precedence Information This project is approved as specified in references [1] and [2]. The entirety of this project may be delivered in a Minor release of the Solaris OS. In addition, the two xpg vari- ants of crontab may be delivered in a Patch release of the Solaris OS. PSARC/2005/683 Copyright 2005 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. __________________________________________________________ | Interfaces Exported | |_____________________|________________|_________________| |Interface | Classification| Comments | |_____________________|________________|_________________| |/usr/xpg4/bin/crontab| Standard | XPG4 behavior | |/usr/xpg6/bin/crontab| Standard | XPG6 behavior | |/usr/bin/crontab | Standard | change default| | | | editor from ed| | | | to vi to paral-| | | | lel XPG| | | | behavior | |_____________________|________________|_________________| 4. Opinion 4.1. Background During the era of SunOS 4.1, our standards-compliance approach relied exclusively on the setting of $PATH. Based on customer feedback, we subsequently added the additional ability for users to "cherry-pick" specific commands from the variant directories. At present, we document a combined approach: setting $PATH as specified in standards(5) for a complete standards-compliant environment, and, in addition, variant forms of individual commands are documented by path- name in the individual command manpages. 4.2. Original Proposal The original proposal left the existing behavior of /usr/bin/crontab -e unchanged, using the first "ed" in $PATH as the default editor. 4.3. Amendment Several reviewers expressed concern with the divergence in behavor between /usr/bin and xpgN variants introduced by this case. The project team accepted a suggestion during the meeting to amend the spec to add, in addition to the delivery with Patch binding of the xpg4 and xpg6 variants of crontab, a change with Minor release binding to /usr/bin/crontab to use the first vi on $PATH as the default editor. 4.4. Standards Strategy Unclear To Many Additionally, several reviewers expressed concern with the PSARC/2005/683 Copyright 2005 Sun Microsystems - 3 - slowly growing proliferation of additional variant commands in the /usr/xpg4/bin and /usr/xpg6/bin directories, trig- gered solely by the behavior of a spawned subprocess. This concern was reinforced by the observed behavior that many of the variant commands in /usr/xpg4/bin support options which are simply rejected by the default variant; for instance, /usr/xpg4/bin/id supports a '-u' option; while /usr/bin/id rejects -u with an "illegal option" usage message. The heated discussion which followed made it clear that our strategy for standards compliance is not well understood among solaris developers as well as among solaris users & developers of applications for solaris. Selective cherry- picking is documented, but there is additionally a signifi- cant concern among a number of members of the Committee that the cherry-picking of complex commands which invoke other commands is of very limited applicability. Both ability to cherrypick and the limitations on this are not well expressed in our documentation, including the standards(5) man page. This led to the advice given in section 6.1. While conformance with the letter of the standards could be satisfied by changing /usr/bin/crontab's default editor to the first "vi" in $PATH, precedent as defined by [3] and [4] among other cases leads us to also deliver xpg4 and xpg6 variants to allow for cherry-picking. Several reviewers felt that this takes cherry-picking too far but there was no consensus among the committee to break with past precedent; a median view among the Committee is that any change to this strategy needs to involve significant review and considera- tion. 4.5. Gratuitous Divergence Obscures The Architecture The discussion also exposed significant divergence between our standards compliance architecture and its implementa- tion. In many cases, once a decision to "fork" a command was made, many new non-conflicting behaviors were integrated only into the xpgN variants. However, as a general rule, there should be no cases where a particular command feature, option, or the like accepted by a /usr/xpgN/bin variant should generate a syntax error when fed to the default sys- tem (/usr/bin) variant; similarly, non-conflicting features found in the default system variant should generally be present in any /usr/xpgN/bin variant unless they conflict with the requirements of the relevant standards.[1] _________________________ [1] Whenever possible we should also attempt to head off future unresolvable divergence by avoiding new changes to the default system variant of a command which are known to conflict with a relevant standard. PSARC/2005/683 Copyright 2005 Sun Microsystems - 4 - This divergence has created both confusion about the overall architecture, and also substantially increases the need to cherry-pick specific command variants in scripts. This degree of confusion is harmful to Solaris and to our users. When members of the community encounter such diver- gence, they should file bugs against the commands in ques- tion, and should flag those bugs with the "missing-std- feature" keyword. 4.6. Examples Of Divergence Specific examples of divergence, where options and syntax are supported by an xpgN variant of a command and are rejected as syntax errors by the /usr/bin variant: 4.6.1. id -u, -g, -G, -n, and -r 4521640 *id* /usr/bin/id missing options from /usr/xpg4/bin/id 4.6.2. grep -e, -f, -q, -x, -E, and -F 4843344 *grep* should have -q, -e, -f, -x, -E, and -F options 4.6.3. tail -n and possibly -c 6231496 *tail* non-XPG4 tail could support -n and pos- sibly -c 4.6.4. du -x 6269516 *du* should always accept -x 4.6.5. sh's lack of support for "export env=expr", $(cmd) syntax, and other non-conflicting POSIX syntax.[2] 6378708 *sh* could implement non-conflicting posix syn- tax _________________________ [2] One early reviewer of this opinion questioned the appropriateness of including this point, as the existing "/bin/sh" implementation is largely unrelated to the codebase used for the /usr/xpgN/bin shells. This is true, and will be a significant obstacle to fixing this problem, but it is a matter of resource allocation, not architecture. It is also the case that the limitations of the existing "sh" are a recurring source of irritation to newcomers to solaris and barrier to adoption by some. Finding the proper approach and balance here will be difficult. PSARC/2005/683 Copyright 2005 Sun Microsystems - 5 - This is by no means a comprehensive list. Fixing these bugs, and identifying other inconsistencies is outside the scope of the case, but resulted in the advice given in section 6.2. 4.7. Heroic Compatibility Measures Unnecessary A proposal was made to suggest that any potential issue of script compatibility could be addressed by having crontab invoke "ed" if isatty(0) returned zero and "vi" if it returned nonzero. However, as there was no consensus that a patch binding was otherwise compatible with a change to the default editor spawned by the crontab command, these heroic measures were deemed unnecessary in a change with Minor release binding. 4.8. Proliferation of additional setuid commands Subsequent to the meeting, concern was expressed regarding the delivery of additional setuid variant commands; this concern was underscored by prior incidents where XPG4 vari- ants which were setuid had security holes not found in the default system variant. The specific problem was caused by linking with values-xpg4.o and values-xpg6.o, exposing dif- ferent interfaces in the variant executables. The current implementation plan is to deliver three setuid executables, none of which will be linked with values- xpg?.o, mitigating this risk. Whether or not any specific crontab executable is setuid is best thought of as an imple- mentation detail, not any sort of Public interface. 5. Minority Opinion(s) No members voted to deny; however, several members of the Committee believe that the xpgN variants of the crontab push variant cherry-picking beyond its actual usefulness. 6. Advisory Information 6.1. Improve standards(5) documentation relating to cherry-picking. The PAC should ensure that both our user-facing and our developer-facing process documentation relating to standards-related command variants is reviewed for clarity and approchability. 6.2. Repair Existing Gratuitous Divergence Unnecessarily divergent behavior between standards-compliant PSARC/2005/683 Copyright 2005 Sun Microsystems - 6 - and default variants of the commands we ship in Solaris is a recurring source of irritation, confusion, and dissatisfac- tion. While each individual instance of divergence is minor, the cumulative impact is akin to that of a thousand paper cuts. Many of these fixes are likely to be small "starter" bugs appropriate for new developers, though subtleties requiring review from experienced engineers will abound. Engineers should be encouraged to fix these and other "irritant" bugs as they are found. 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/2005/683. 1. Amended specification. File: final.spec 2. crontab(1) man page. File: final/crontab.1 3. PSARC 1994/161 XCU4 Conformance 4. PSARC 2000/492 Austin Group Common Revision of SUSv2 and POSIX Standards. PSARC/2005/683 Copyright 2005 Sun Microsystems