On Jul 7, 2010, at 6:20 AM, Rich Burridge wrote: After some discussion on this case during this morning's ARC meeting, I'm responding to this message and Alan's message. This is to record several man page problems (most, if not all, being problems for well over a decade) and to note a single remaining architectural issue.
> > On 07/05/10 22:14, Don Cragun wrote: > > > On Jul 3, 2010, at 2:47 AM, Alan Burlison wrote: > > > >> ... > > > > OK. I'm sorry. I have gotten lost on what the current proposal is. > > The comments in this message are based on the text in this message and the > > contents of the current Solaris 10 expr(1) man page as modified by the > > man-pages-changes.txt file in the materials directory for this case. > > Note that this is the OpenSolaris expr(1) man page that is being modified, > not the Solaris 10 one. There should not be any difference between the Solaris 10 man page and the OpenSolaris man page. This case is talking about changes that will be integrated into the ON gate of Solaris next and then propogated from there into the OpenSolaris gates. > > > There is no mention of the SYSV3 environment variable on the current > > expr(1) man page. So, I assume you are now saying that the current man > > page is wrong and that the statement there: > > "Compatibility Operators (x86 only) > > The following operators are included for compatibility with > > INTERACTIVE UNIX System only and are not intended to be used > > by non- INTERACTIVE UNIX System scripts:" > > only actually applied when SYSV3 was present in the environment when expr > > is invoked. Is that correct? > > Those three operators currently are only available when the SYSV3 > environment variable is set and only on x86 platforms > > See: > > http://cvs.opensolaris.org/source/xref/vnm/ILB/usr/src/cmd/expr/expr.c I'm looking at the source now and running some experiments of my own. Three is an additional operator ("match") which is present in the source that is not mentioned on the man page. This operator needs to be added to the man page. The "index", "length", and "substr" operators are always in the yacc grammar on x86. If SYSV3 is not in the environment, expr always reports "syntax error" when these operators are specified; it should have treated them as string operands instead of as operators in this case. You are changing expr to always treat them as operators, so this shortcoming is no longer an issue. > > and its Makefile: > > http://cvs.opensolaris.org/source/xref/vnm/ILB/usr/src/cmd/expr/Makefile > > > And, am I correct in understanding that > > this is also only true on /usr/bin/expr and is not true on any SPARC > > version of expr? > > Correct. > > > No. The current contents of man-pages-changes.txt says that all of the > > operators are CSI enabled. It has notes saying that index, length, and > > substr are not available in /usr/xpg[46]/bin/expr, but says nothing > > about them not being available on SPARC and nothing about them not > > being CSI enabled. > > I've now changed the proposed NOTES section to: > > NOTES > > The following three operators are not CSI enabled. They are also > not available in /usr/xpg4/bin/expr and /usr/xpg6/bin/expr > > index string character-list > > length string > > substr string integer-1 integer-2 > > They will now be available on SPARC as well as x86 so I don't believe > there is a need for a special note for that. > > > No. It decreases GNU compatibility by making three of the four > > additional operators that are present in GNU expr available with > > behavior that is incompatible with their behavior in GNU expr. > > Those three operators are not multi-byte aware in GNU expr. If this is true, the GNU expr man pages I've seen also incorrectly state the behavior of these operators (although they do correct state the behavior of "match"). Note that I am not doubting your review of the GNU source; GNU man pages are notoriously inaccurate in documenting the difference between bytes and characters. > > > Since you are changing index, length, and substr from "included for > > compatibility with INTERACTIVE UNIX System only" to "Interface > > Stability" "Standard" (i.e., Committed), you are also saying that any > > followup case to address the GNU incompatibility issues creatred by this > > change in behavior must have a major release binding. > > We are not aware of any GNU incompatibility issues here. > > > Note also that the operator precedence for index, length, and substr > > isn't clear on the current expr(1) man page. You are now declaring > > clearly that substr is the highest precedence operator, length is the > > second highest, index is the third hightest, and all of the operators > > mandated by the standards have lower precedence. Is this the > > intended behavior? > > Looking at the expr.c source code (line 114 ) at: > > http://cvs.opensolaris.org/source/xref/vnm/ILB/usr/src/cmd/expr/expr.c > > the precedence order is SUBSTR, LENGTH, INDEX so that means the > order in the man-page-changes.txt file needs to be reversed. I've > made this change to .../materials/man-page-changes.txt No. The MATCH, SUBSTR, LENGTH, and INDEX operators all have precedence 7. You will also note that the other operators are given precedence levels that meet the requirements in the standards (with several sets of operators having the same precedence). These sets of operators with the same precedence are correctly documented for all of the operators except for the index, length, and substr (and the missing match) operators. OK. Please add the description of the match operator along with the description of the index, length, and substr operators (noting that they all have the same precedence). > >> You said in an earlier message that this change would not affect any >> current expr script that didn't run with set SYSV3 set in the >> environment. But, that isn't true either. The command: >> expr index >> without SYSV3 in the environment would have printed: >> index >> with "index" recognized as a string operand whereas with these >> changes, it will yield a syntax error because the index operator is >> missing two operands. (This, however, would not affect a strictly >> conforming POSIX or UNIX shell application. But, it would be a >> noticeable change in behavior.) > > This is not what I'm seeing. Using the attached script, I get the following: > > $ ./expr-index-test.sh > + EXPR=/usr/bin/expr.orig > + print 'Testing current version of expr' > Testing current version of expr > + /usr/bin/expr.orig index > expr: syntax error > + /usr/bin/expr.orig index 'Hello world' H > expr: syntax error > + print 'Testing proposed new version of expr' > Testing proposed new version of expr > + /usr/bin/expr index > expr: syntax error > + /usr/bin/expr index 'Hello world' H > 1 > > In this case, /usr/bin/expr.orig is the current version of expr in OpenSolaris > and /usr/bin/expr is the proposed new version of expr. Yes, this is what I mentioned earlier. Everything you say above is correct on x86. On SPARC, however, the command: /usr/bin/expr index would print: index instead of: expr: syntax error If it were true that the x86 implementation didn't recognize index, length, and substr as operators when SYSV3 was not present in the environment, /usr/bin/expr index would also have printed: index on x86. - Don _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
