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 ===========================================================================