From sacadmin Wed Jun 23 08:23:48 2010 Received: from stard.SFBay.Sun.COM (stard.SFBay.Sun.COM [129.146.228.20]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5NFNmxR021825; Wed, 23 Jun 2010 08:23:48 -0700 (PDT) Received: from stard.SFBay.Sun.COM (localhost [127.0.0.1]) by stard.SFBay.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o5NFQWUS002561; Wed, 23 Jun 2010 08:26:32 -0700 (PDT) Received: (from richb@localhost) by stard.SFBay.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o5NFQWUP002559; Wed, 23 Jun 2010 08:26:32 -0700 (PDT) Date: Wed, 23 Jun 2010 08:26:32 -0700 (PDT) From: Rich Burridge Message-Id: <201006231526.o5NFQWUP002559@stard.SFBay.Sun.COM> To: PSARC-record@sac.sfbay.sun.com Subject: EOF SYSV3 SCO compatibility environment variable [PSARC/2010/233 FastTrack timeout 06/30/2010] Status: RO Content-Length: 621 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: EOF SYSV3 SCO compatibility environment variable 1.2. Name of Document Author/Supplier: Author: Rich Burridge 1.3 Date of This Document: 23 June, 2010 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From rich.burridge@oracle.com Wed Jun 23 08:28:56 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5NFSuR6021998 for ; Wed, 23 Jun 2010 08:28:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5NFSj94029347 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Jun 2010 08:28:56 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4H00J1J4C59200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Jun 2010 08:28:53 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4H00C984C48BE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Jun 2010 08:28:52 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5NFSqjE006477 for ; Wed, 23 Jun 2010 15:28:52 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5NFSnK7008772 for ; Wed, 23 Jun 2010 15:28:50 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 350651141277306928; Wed, 23 Jun 2010 08:28:48 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Jun 2010 08:28:47 -0700 Date: Wed, 23 Jun 2010 08:31:31 -0700 From: Rich Burridge Subject: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] To: PSARC-ext@sun.com Cc: Alan Burlison Message-id: <4C2228D3.1040308@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C222834.0014:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 7536 I am sponsoring this case on behalf of the Solaris modernization team. The timeout is set for 30th June, 2010. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI 1. Introduction 1.1. Project/Component Working Name: EOF SYSV3 SCO compatibility environment variable 1.2. Name of Document Author/Supplier: Author: Rich Burridge 1.3 Date of This Document: 23rd June, 2010 4. Technical Description This case requests EOF of some of the SCO iBSC2 functionality that was previously approved in PSARC/1995/067 and PSARC/1996/259. A minor release binding is requested. This functionality was only available on the x86 platform, and only then if the SYSV3 environment variable was set. The minority opinion for PSARC/1995/067 states: Many of these features are generally useful extensions, and the fact that they came from SCO UNIX is an accident of history. Useful features should, whenever possible, be supported on all architectures. A check was made to see which of the features are available in the equivalent GNU commands, and where present, the same feature will be kept and made available to both x86 and SPARC platforms, without the need to set the SYSV3 environment variable. (A check was also made of the latest ON, SFW, X and JDS workspaces to ensure that the SYSV3 environment variable wasn't being used.) Commands affected: df du echo expr sh tar uname In more detail: df If the SYSV3 environment variable is defined, /bin/df gives different output. Specifically it uses "i-nodes" instead of "files" in the default output and the output of the "-t" option, or when the "-e" and "-b" options are used together. This functionality will be removed. du PSARC/1995/067 mentions adding a -L switch to /bin/du which is described in PSARC/1996/259: du -L If the "du" command is specified with the name of a symbolic link, the -L argument tells "du" to follow the symbolic link and report information for the file system to which it points. This functionality is already available to both SPARC and x86 without having to use the SYSV3 environment variable, and will be retained. echo If the SYSV3 environment variable is set, echo uses SCO style -n option parsing. This functionality will be removed. expr Three new options were added to this command to provide SCO compatibility: len string Return the length (eg. number of characters) of string. index str charlist Report the first position in string at which any of the characters in charlist matches a character in str. substr str start len Extract the substring of str starting at start with a length of len. This functionality is present in the GNU expr command, and will now be made available to x86 and SPARC users without needing the SYSV3 environment variable set. sh If the SYSV3 environment variable is set, echo uses SCO style -n option parsing. This functionality will be removed. (This is /usr/has/bin/sh on OpenSolaris systems). tar The following three options will be removed: -e Prevents files from being split across volumes. If there is not enough room on a volume, tar prompts for a new volume. This differs from standard Solaris behavior. -k Cause tar to use the next arg as the size of an archive in kilobytes. This is useful when the archive is intended for a fixed size device such as floppy disk. Large files are then split across volumes. This option used to be in Solaris but was removed because it isn't defined in SVID. -q Stop after extracting the first occurance of the named files. This option is a performance enhancement to enable the system administration tool to run much faster. The issue was that tar normally continues to read the entire volume even after it has found the desired file (there may be a second occurance of the file in the tar file so it keeps reading until finished). (Note that this functionality was never implemented, even though tar happily accepted the command line option.) The following option will be modified to remove this functionality that was present when SYSV3 was set: -F read command line switches from a specified file (name in next argument). This differs from standard Solaris behavior. The current behaviour of the -F flag when SYSV3 is unset is as follows: -F With one F argument, tar excludes all directories named SCCS and RCS from the tarfile. With two arguments, FF, tar excludes all directories named SCCS and RCS, all files with .o as their suffix, and all files named errs, core, and a.out. This behaviour will be unaltered. The following option (which is also present in GNU tar), will be available to both x86 and SPARC users without having to set the SYSV3 environment variable: -n the file being read is a non-tape device so listing and extracting files is sped since tar can seek over files it wishes to skip. This had been in Solaris but was removed because it isn't defined in SVID. uname Setting SYSV3 to an empty string will make uname print the following default values: nodename nodename 3.2 2 i386 The individual elements that uname displays can also be modified by setting SYSV3 in the following format: os,sysname,node,rel,ver,mach os Operating system (IUS or SCO). sysname System name. node Nodename as displayed by the -n option. rel Release level as displayed by the -r option. ver Version number as displayed by the -v option. mach Machine name as displayed by -m option. Do not put spaces between the elements. If an element is omitted, the current system value will be used. This functionality will be removed. The manual pages for these commands will be updated as described in materials/man-page-changes.txt 5. References: CR #6961744 Removal of iBCS2 #ifdef'ed code from ON PSARC/1995/067 iBCS2 compatibility PSARC/1996/259 SCO Compatibility 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From dcragun@sonic.net Thu Jun 24 18:01:54 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5P11sQE007002 for ; Thu, 24 Jun 2010 18:01:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5P11rGQ028423 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 24 Jun 2010 18:01:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4J00901PJ5DU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 24 Jun 2010 18:01:53 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4J00MWKPJ5GC70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 24 Jun 2010 18:01:53 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o5P0miHu029923 for ; Fri, 25 Jun 2010 01:01:53 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay42i.sun.com with ESMTP id BT-MMP-87313 for PSARC-ext@sun.com; Fri, 25 Jun 2010 01:01:52 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-20181474 for PSARC-ext@sun.com; Fri, 25 Jun 2010 01:01:52 +0000 (Z) Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay4i.sun.com with ESMTP id BT-MMP-4205385 for PSARC-ext@sun.com; Fri, 25 Jun 2010 01:01:52 +0000 (Z) Received: from [10.0.0.4] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o5P11n1Q002986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jun 2010 18:01:49 -0700 Date: Thu, 24 Jun 2010 18:01:50 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: To: Alan.Burlison@oracle.com Cc: PSARC-ext@sun.com Message-id: <49855070-20B2-41F0-9BFB-5B40D58BDC2B@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.109sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: Status: RO Content-Length: 2092 On Jun 23, 2010, at 08:31:31 -0700, rich.burridge@oracle.com wrote: ... ... ... > 4. Technical Description ... ... ... > In more detail: ... ... ... > expr > > Three new options were added to this command to provide SCO > compatibility: The following descriptions do not match what I see in the expr(1) man page I found at http://docs.sun.com/app/docs/doc/817-5441/6mkt8ktnn?l=en&a=view&q=expr and no changes are shown in the man pages changes document in the case directory. So, ... > > len string Return the length (eg. number of > characters) > of string. Do you mean "len" or "length". The standards allow an operator named "length" without specifying what it does. But "len" has to be interpreted as a string; not as an operator. Assuming you did mean "length", does it return the number of characters in string or the number of bytes in string (they are different in a locale using multi-byte characters). And, the "eg." should be dropped or changed to "i.e.,". You should also specify whether the value includes the terminating nul character. > > index str charlist Report the first position in string at > which > any of the characters in charlist > matches a > character in str. Is the position counted in bytes or characters? Does the count start at zero or one? > > substr str start len Extract the substring of str starting at > start with a length of len. Does "start" start at zero or at one? Does start count bytes or characters? Does len count bytes or characters? If either of the last two is bytes, what happens if the starting or ending point is in the middle of a multi-byte character? What happens if start+len is beyond the end of str? - Don > > This functionality is present in the GNU expr command, and will now > be made available to x86 and SPARC users without needing the SYSV3 > environment variable set. ... ... ... From rich.burridge@oracle.com Wed Jun 30 10:57:31 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5UHvUog004979 for ; Wed, 30 Jun 2010 10:57:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o5UHvTRq029030 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 30 Jun 2010 11:57:30 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4U0011J9VTZ500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 10:57:29 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4U00JPT9VSLS60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 10:57:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5UHvSjH023855 for ; Wed, 30 Jun 2010 17:57:28 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5U0KB7X017645; Wed, 30 Jun 2010 17:57:23 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 370798881277920627; Wed, 30 Jun 2010 10:57:07 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Jun 2010 10:57:06 -0700 Date: Wed, 30 Jun 2010 10:59:55 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] To: dcragun@sonic.net Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C2B861B.5020605@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_u6vECfafxRpjW3rfT/xaoQ)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C2B8585.017F:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 12185 This is a multi-part message in MIME format. --Boundary_(ID_u6vECfafxRpjW3rfT/xaoQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Don Cragun wrote: >> 4. Technical Description >> ... ... ... >> In more detail: >> >> ... ... ... >> expr >> >> Three new options were added to this command to provide SCO >> compatibility: > The following descriptions do not match what I see in the expr(1) > man page I found at > http://docs.sun.com/app/docs/doc/817-5441/6mkt8ktnn?l=en&a=view&q=expr That's a Solaris 8 man page for expr. I was working off the one that's in my OpenSolaris release. I've attached a copy of that. The OpenSolaris man page bundle can also be found at: http://dlc.sun.com/osol/man/downloads/current/ The file in question is .../man/man1/expr.1 > and no changes are shown in the man pages changes document in the case > directory. So, ... .../materials/man-page-changes.txt had the following: ----------------------------------------------------------------------------- expr(1) The following text will be removed from the "DESCRIPTION" section: 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: ----------------------------------------------------------------------------- That should have been "OPERANDS" not "DESCRIPTION", so I've adjusted it accordingly. >> >> len string Return the length (eg. number of >> characters) >> of string. > > Do you mean "len" or "length". length. I took this from the text in PSARC 1996/259, which is incorrect. > The standards allow an operator named > "length" without specifying what it does. But "len" has to be > interpreted as a string; not as an operator. Assuming you did mean > "length", does it return the number of characters in string or the > number of bytes in string (they are different in a locale using > multi-byte characters). And, the "eg." should be dropped or changed > to "i.e.,". You should also specify whether the value includes the > terminating nul character. The expr(1) man page has: length string Return the length (that is, the number of bytes) of string. The length does not include the terminating nul character. >> >> index str charlist Report the first position in string at >> which >> any of the characters in charlist >> matches a >> character in str. > > Is the position counted in bytes or characters? bytes. > Does the count start at zero or one? 0 The expr(1) man page has: index string character-list Report the first position in which any one of the bytes in character-list matches a byte in string. >> >> substr str start len Extract the substring of str starting at >> start with a length of len. > > Does "start" start at zero or at one? 0 > Does start count bytes or characters? bytes. > Does len count bytes or characters? bytes. > If either of the last two is bytes, what happens if the starting or ending point is > in the middle of a multi-byte character? It returns just the sequence of bytes that you specified; in other words, only a part of the multi-byte character. > What happens if start+len is beyond the end of str? See below. The expr(1) man page has: substr string integer-1 integer-2 Extract the substring of string starting at position integer-1 and of length integer-2 bytes. If integer-1 has a value greater than the number of bytes in string, expr returns a null string. If you try to extract more bytes than there are in string, expr returns all the remaining bytes from string. Results are unspecified if either integer-1 or integer-2 is a negative value. I've adjusted the proposal.txt file in the case directory to match the three entries in the expr(1) manual pages. --Boundary_(ID_u6vECfafxRpjW3rfT/xaoQ) Content-type: text/plain; name=expr-manpage.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=expr-manpage.txt User Commands expr(1) NAME expr - evaluate arguments as an expression SYNOPSIS /usr/bin/expr argument... /usr/xpg4/bin/expr argument... /usr/xpg6/bin/expr argument... DESCRIPTION /usr/bin/expr, /usr/xpg4/bin/expr The expr utility evaluates the expression and writes the result to standard output. The character 0 is written to indicate a zero value and nothing is written to indicate a null string. /usr/xpg6/bin/expr The expr utility evaluates the expression and writes the result to standard output followed by a NEWLINE. If there is no result from expr processing, a NEWLINE is written to standard output. OPERANDS The argument operand is evaluated as an expression. Terms of the expression must be separated by blanks. Characters spe- cial to the shell must be escaped (see sh(1)). Strings con- taining blanks or other special characters should be quoted. The length of the expression is limited to LINE_MAX (2048 characters). The operators and keywords are listed below. The list is in order of increasing precedence, with equal precedence opera- tors grouped within {} symbols. All of the operators are left-associative. expr \| expr Returns the evaluation of the first expr if it is nei- ther NULL nor 0; otherwise, returns the evaluation of the second expr if it is not NULL; otherwise, 0. expr \& expr Returns the first expr if neither expr is NULL or 0, otherwise returns 0. SunOS 5.11 Last change: 29 Aug 2003 1 User Commands expr(1) expr{ =, \>, \>=, \<, \<=, !=} expr Returns the result of an integer comparison if both arguments are integers, otherwise returns the result of a string comparison using the locale-specific coalition sequence. The result of each comparison will be 1 if the specified relationship is TRUE, 0 if the relationship is FALSE. expr { +, - } expr Addition or subtraction of integer-valued arguments. expr { \*, /, %} expr Multiplication, division, or remainder of the integer- valued arguments. expr : expr The matching operator : (colon) compares the first argu- ment with the second argument, which must be an interna- tionalized basic regular expression (BRE), except that all patterns are anchored to the beginning of the string. That is, only sequences starting at the first character of a string are matched by the regular expres- sion. See regex(5) and NOTES. Normally, the /usr/bin/expr matching operator returns the number of bytes matched and the /usr/xpg4/bin/expr matching opera- tor returns the number of characters matched (0 on failure). If the second argument contains at least one BRE sub-expression [\(...\)], the matching operator returns the string corresponding to \1. integer An argument consisting only of an (optional) unary minus followed by digits. string A string argument that cannot be identified as an integer argument or as one of the expression operator symbols. SunOS 5.11 Last change: 29 Aug 2003 2 User Commands expr(1) 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: index string character-list Report the first position in which any one of the bytes in character-list matches a byte in string. length string Return the length (that is, the number of bytes) of string. substr string integer-1 integer-2 Extract the substring of string starting at position integer-1 and of length integer-2 bytes. If integer-1 has a value greater than the number of bytes in string, expr returns a null string. If you try to extract more bytes than there are in string, expr returns all the remaining bytes from string. Results are unspecified if either integer-1 or integer-2 is a negative value. EXAMPLES Example 1 Adding an integer to a shell variable Add 1 to the shell variable a: example$ a=`expr $a + 1` Example 2 Returning a path name segment The following example emulates basename(1), returning the last segment of the path name $a. For $a equal to either /usr/abc/file or just file, the example returns file. (Watch out for / alone as an argument: expr takes it as the divi- sion operator. See NOTES below.) example$ expr $a : '.*/\(.*\)' \| $a SunOS 5.11 Last change: 29 Aug 2003 3 User Commands expr(1) Example 3 Using // characters to simplify the expression Here is a better version of the previous example. The addi- tion of the // characters eliminates any ambiguity about the division operator and simplifies the whole expression. example$ expr //$a : '.*/\(.*\)' /usr/bin/expr Example 4 Returning the number of bytes in a variable example$ expr "$VAR" : '.*' /usr/xpg4/bin/expr Example 5 Returning the number of characters in a variable example$ expr "$VAR" : '.*' ENVIRONMENT VARIABLES See environ(5) for descriptions of the following environment variables that affect the execution of expr: LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, and NLSPATH. EXIT STATUS As a side effect of expression evaluation, expr returns the following exit values: 0 If the expression is neither NULL nor 0. 1 If the expression is either NULL or 0. 2 For invalid expressions. >2 An error occurred. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: SunOS 5.11 Last change: 29 Aug 2003 4 User Commands expr(1) ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcs | |_____________________________|_____________________________| | CSI | enabled | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | Standard | See standards(5). | |_____________________________|_____________________________| SEE ALSO basename(1), ed(1), sh(1), Intro(3), attributes(5), environ(5), regex(5), standards(5) DIAGNOSTICS syntax error Operator and operand errors. non-numeric argument Arithmetic is attempted on such a string. NOTES After argument processing by the shell, expr cannot tell the difference between an operator and an operand except by the value. If $a is an =, the command: example$ expr $a = '=' looks like: example$ expr = = = as the arguments are passed to expr (and they are all taken as the = operator). The following works: example$ expr X$a = X= Regular Expressions Unlike some previous versions, expr uses Internationalized Basic Regular Expressions for all system-provided locales. SunOS 5.11 Last change: 29 Aug 2003 5 User Commands expr(1) Internationalized Regular Expressions are explained on the regex(5) manual page. SunOS 5.11 Last change: 29 Aug 2003 6 --Boundary_(ID_u6vECfafxRpjW3rfT/xaoQ)-- From rich.burridge@oracle.com Wed Jun 30 13:09:25 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5UK9PNG009645 for ; Wed, 30 Jun 2010 13:09:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5UK9Npt018345 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 30 Jun 2010 15:09:24 -0500 (CDT) 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 <0L4U0080JFZOIL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 13:09:24 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4U00J1SFZNLRD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 13:09:24 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5UK9N7v001533 for ; Wed, 30 Jun 2010 20:09:23 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5UK9MJx027864 for ; Wed, 30 Jun 2010 20:09:22 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 371225431277928507; Wed, 30 Jun 2010 13:08:27 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Jun 2010 13:08:26 -0700 Date: Wed, 30 Jun 2010 13:11:15 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233, FastTrack timeout, 06/30/2010] To: PSARC-ext@sun.com Cc: Alan Burlison Message-id: <4C2BA4E3.7010907@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C2BA472.01D4:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 235 I've hopefully responded to Don's questions. I've reset the timer to 7th July 2010. If the case can be approved before that date, it would be very much appreciated, as I still have the C-Team and P-Team "paperwork" to do. Thanks. From johnf@sac.sfbay.sun.com Wed Jun 30 14:39:24 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5ULdOUe012233 for ; Wed, 30 Jun 2010 14:39:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5ULdOra010580 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 30 Jun 2010 14:39:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4U00F03K5O5B00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 15:39:24 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4U000FZK5N3A70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 15:39:23 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5ULdN1A027087; Wed, 30 Jun 2010 14:39:23 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5ULdMkN012230; Wed, 30 Jun 2010 14:39:22 -0700 (PDT) Received: (from johnf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o5ULdMST012229; Wed, 30 Jun 2010 14:39:22 -0700 (PDT) Date: Wed, 30 Jun 2010 14:39:22 -0700 (PDT) From: John Fischer Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233, FastTrack timeout, 06/30/2010] To: PSARC-ext@sun.com, rich.burridge@oracle.com Cc: Alan.Burlison@oracle.com Message-id: <201006302139.o5ULdMST012229@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 194 Rich, What sort of announcement will be made in a Patch release of Solaris? Will this be release noted? Will the man pages be updated to include a warning? Other? Other then that +1. John From dcragun@sonic.net Wed Jun 30 15:59:42 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5UMxgZN014682 for ; Wed, 30 Jun 2010 15:59:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5UMxcQB003695 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 30 Jun 2010 17:59:39 -0500 (CDT) 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 <0L4U00H0HNVEIQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 15:59:38 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4U00AFANVD6YC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jun 2010 15:59:37 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5UMiY7O023498 for ; Wed, 30 Jun 2010 22:59:37 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-169519 for PSARC-ext@sun.com; Wed, 30 Jun 2010 22:59:30 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-892455 for PSARC-ext@sun.com; Wed, 30 Jun 2010 22:59:29 +0000 (Z) Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay1i.sun.com with ESMTP id BT-MMP-15594842 for PSARC-ext@sun.com; Wed, 30 Jun 2010 22:59:29 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o5UMxQcj000676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jun 2010 15:59:26 -0700 Date: Wed, 30 Jun 2010 15:59:26 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C2B861B.5020605@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.115sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> Status: RO Content-Length: 5975 On Jun 30, 2010, at 10:59 AM, Rich Burridge wrote: > Don Cragun wrote: > >> 4. Technical Description > >> ... ... ... > >> In more detail: > >> > >> ... ... ... > >> expr > >> > >> Three new options were added to this command to provide SCO > >> compatibility: > > > The following descriptions do not match what I see in the expr(1) > > man page I found at > > http://docs.sun.com/app/docs/doc/817-5441/6mkt8ktnn?l=en&a=view&q=expr > > That's a Solaris 8 man page for expr. I was working off the one that's > in my OpenSolaris release. I've attached a copy of that. Sorry. I used the Solaris 10 Reference Manual Collection page http://docs.sun.com/app/docs/coll/40.10 and searched for expr(1), but I must have forgotten to check "Search only this collection". > > The OpenSolaris man page bundle can also be found at: > > http://dlc.sun.com/osol/man/downloads/current/ > > The file in question is .../man/man1/expr.1 > > > and no changes are shown in the man pages changes document in the case > > directory. So, ... > > .../materials/man-page-changes.txt had the following: > > ----------------------------------------------------------------------------- > > expr(1) > > The following text will be removed from the "DESCRIPTION" section: > > 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: > > ----------------------------------------------------------------------------- > > That should have been "OPERANDS" not "DESCRIPTION", so I've adjusted it accordingly. Yes, this matched what I found on the man page I listed above and what was on the man page you attached below. > > > > >> > >> len string Return the length (eg. number of > >> characters) > >> of string. > > > > Do you mean "len" or "length". > > length. I took this from the text in PSARC 1996/259, which is incorrect. OK. Good. I was just confused because it didn't match any of the Solaris man pages I'd ever seen. > > > The standards allow an operator named > > "length" without specifying what it does. But "len" has to be > > interpreted as a string; not as an operator. Assuming you did mean > > "length", does it return the number of characters in string or the > > number of bytes in string (they are different in a locale using > > multi-byte characters). And, the "eg." should be dropped or changed > > to "i.e.,". You should also specify whether the value includes the > > terminating nul character. > > The expr(1) man page has: > > length string > > Return the length (that is, the number of bytes) of > string. > > The length does not include the terminating nul character. The original case materials for this case said: len string Return the length (eg. number of characters) of string. which conflicted with all of the Solaris man pages I'd seen since at least Solaris 2.4. I would be nice if you would update the man page to explicitly state that the terminating nul character is not counted in the returned value. > > >> > >> index str charlist Report the first position in string at > >> which > >> any of the characters in charlist > >> matches a > >> character in str. > > > > Is the position counted in bytes or characters? > > bytes. Good. > > > Does the count start at zero or one? > > 0 Good. Please update the man page to indicate both of these facts. > > The expr(1) man page has: > > index string character-list > > Report the first position in which any one of the bytes > in character-list matches a byte in string. This is terrible! The man page you included below says that expr is CSI enabled. With a UTF-8 codeset, any multi-byte character in a given code plane will match any other character in the same code plane. This does not meet the definition of CSI enabled. It should be something a lot more like: index string character-list Report the first byte in "string" (counting from zero) where a character from "character-list" matches a character from "string". If no character in "character-list" appears in "string", XXX specify what happens in this case XXX. > > >> > >> substr str start len Extract the substring of str starting at > >> start with a length of len. > > > > Does "start" start at zero or at one? > > 0 > > > Does start count bytes or characters? > > bytes. > > > Does len count bytes or characters? > > bytes. > > > If either of the last two is bytes, what happens if the starting or ending point is > > in the middle of a multi-byte character? > > It returns just the sequence of bytes that you specified; in other words, > only a part of the multi-byte character. > > > What happens if start+len is beyond the end of str? > > See below. > > > The expr(1) man page has: > > substr string integer-1 integer-2 > > Extract the substring of string starting at position > integer-1 and of length integer-2 bytes. If integer-1 > has a value greater than the number of bytes in string, > expr returns a null string. If you try to extract more > bytes than there are in string, expr returns all the > remaining bytes from string. Results are unspecified if > either integer-1 or integer-2 is a negative value. In a CSI enabled utility, a "substring" should consist of zero or more "characters". If this is really what substr does, you should change "substring of" in the first line of the description to "sequence of bytes from". - Don > > I've adjusted the proposal.txt file in the case directory to match the > three entries in the expr(1) manual pages. > > From rich.burridge@oracle.com Thu Jul 1 07:04:12 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o61E4CKb025507 for ; Thu, 1 Jul 2010 07:04:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o61E4BQu019880 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Jul 2010 09:04:12 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4V00607TR0T000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 07:04:12 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4V003ZQTQYCJ30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 07:04:10 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o61E4A0u027718 for ; Thu, 01 Jul 2010 14:04:10 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6149HUQ008284; Thu, 01 Jul 2010 14:04:06 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 373998681277993009; Thu, 01 Jul 2010 07:03:29 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 07:03:28 -0700 Date: Thu, 01 Jul 2010 07:06:17 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> To: Don Cragun Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C2CA0D9.6000102@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C2CA058.025E:SCFMA4539814,ss=1,fgs=0 References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 3320 > Don Cragun wrote: > ... > >> The expr(1) man page has: >> >> length string >> >> Return the length (that is, the number of bytes) of >> string. >> >> The length does not include the terminating nul character. > The original case materials for this case said: > len string Return the length (eg. number of characters) > of string. > which conflicted with all of the Solaris man pages I'd seen since at > least Solaris 2.4. I would be nice if you would update the man page > to explicitly state that the terminating nul character is not > counted in the returned value. I've added wording to this effect to the expr(1) section of .../materials/man-page-changes.txt >>>> index str charlist Report the first position in string at >>>> which >>>> any of the characters in charlist >>>> matches a >>>> character in str. >>> Is the position counted in bytes or characters? >> bytes. > Good. > > >>> Does the count start at zero or one? >> 0 > Good. Please update the man page to indicate both of these facts. So changed (in .../materials/man-page-changes.txt). >> The expr(1) man page has: >> >> index string character-list >> >> Report the first position in which any one of the bytes >> in character-list matches a byte in string. > This is terrible! The man page you included below says that expr > is CSI enabled. That's not correct. I've added a note to .../materials/man-page-changes.txt to say that that line in the ATTRIBUTES section should be adjusted to "Not enabled". > With a UTF-8 codeset, any multi-byte character > in a given code plane will match any other character in the same > code plane. This does not meet the definition of CSI enabled. > It should be something a lot more like: > > index string character-list > Report the first byte in "string" (counting from > zero) where a character from "character-list" > matches a character from "string". If no > character in "character-list" appears in "string", > XXX specify what happens in this case XXX. So changed (and adjusting the XXX part accordingly) in .../materials/man-page-changes.txt. >>>> substr str start len Extract the substring of str starting at >>>> start with a length of len. >> >> The expr(1) man page has: >> >> substr string integer-1 integer-2 >> >> Extract the substring of string starting at position >> integer-1 and of length integer-2 bytes. If integer-1 >> has a value greater than the number of bytes in string, >> expr returns a null string. If you try to extract more >> bytes than there are in string, expr returns all the >> remaining bytes from string. Results are unspecified if >> either integer-1 or integer-2 is a negative value. > In a CSI enabled utility, a "substring" should consist of zero or > more "characters". If this is really what substr does, you should > change "substring of" in the first line of the description to > "sequence of bytes from". So changed (in .../materials/man-page-changes.txt). Thanks. From dcragun@sonic.net Thu Jul 1 07:51:39 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o61EpcGT025838 for ; Thu, 1 Jul 2010 07:51:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o61Epcsa017311 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Jul 2010 08:51:38 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4V00G07VY25600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 07:51:38 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4V003B5VY1CJE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 07:51:38 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o61EpbwC025347 for ; Thu, 01 Jul 2010 14:51:37 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-4062949 for PSARC-ext@sun.com; Thu, 01 Jul 2010 14:49:37 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-594059 for PSARC-ext@sun.com; Thu, 01 Jul 2010 14:49:37 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-45610730 for PSARC-ext@sun.com; Thu, 01 Jul 2010 14:49:36 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o61EnWnF008077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 01 Jul 2010 07:49:32 -0700 Date: Thu, 01 Jul 2010 07:49:32 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C2CA0D9.6000102@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.087sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> Status: RO Content-Length: 3935 On Jul 1, 2010, at 7:06 AM, Rich Burridge wrote: Hi Rich, Please find comments in-ilne below... > > > Don Cragun wrote: > > ... > > > >> The expr(1) man page has: > >> > >> length string > >> > >> Return the length (that is, the number of bytes) of > >> string. > >> > >> The length does not include the terminating nul character. > > The original case materials for this case said: > > len string Return the length (eg. number of characters) > > of string. > > which conflicted with all of the Solaris man pages I'd seen since at > > least Solaris 2.4. I would be nice if you would update the man page > > to explicitly state that the terminating nul character is not > > counted in the returned value. > > I've added wording to this effect to the expr(1) section of > .../materials/man-page-changes.txt OK. > > > >>>> index str charlist Report the first position in string at > >>>> which > >>>> any of the characters in charlist > >>>> matches a > >>>> character in str. > >>> Is the position counted in bytes or characters? > >> bytes. > > Good. > > > > > >>> Does the count start at zero or one? > >> 0 > > Good. Please update the man page to indicate both of these facts. > > So changed (in .../materials/man-page-changes.txt). > > > >> The expr(1) man page has: > >> > >> index string character-list > >> > >> Report the first position in which any one of the bytes > >> in character-list matches a byte in string. > > This is terrible! The man page you included below says that expr > > is CSI enabled. > > That's not correct. I've added a note to .../materials/man-page-changes.txt > to say that that line in the ATTRIBUTES section should be adjusted to > "Not enabled". The test suite may not catch you, but if expr is not CSI enabled, you don't conform to the standards. Since you have changed index to look for a matching character (instead of just matching bytes), why is it not CSI enabled? > > > With a UTF-8 codeset, any multi-byte character > > in a given code plane will match any other character in the same > > code plane. This does not meet the definition of CSI enabled. > > It should be something a lot more like: > > > > index string character-list > > Report the first byte in "string" (counting from > > zero) where a character from "character-list" > > matches a character from "string". If no > > character in "character-list" appears in "string", > > XXX specify what happens in this case XXX. > > So changed (and adjusting the XXX part accordingly) in > .../materials/man-page-changes.txt. Since you say that zero is returned if there is no match and zero is returned if the first character matches, how does a user know if a match was found? > > > >>>> substr str start len Extract the substring of str starting at > >>>> start with a length of len. > >> > >> The expr(1) man page has: > >> > >> substr string integer-1 integer-2 > >> > >> Extract the substring of string starting at position > >> integer-1 and of length integer-2 bytes. If integer-1 > >> has a value greater than the number of bytes in string, > >> expr returns a null string. If you try to extract more > >> bytes than there are in string, expr returns all the > >> remaining bytes from string. Results are unspecified if > >> either integer-1 or integer-2 is a negative value. > > In a CSI enabled utility, a "substring" should consist of zero or > > more "characters". If this is really what substr does, you should > > change "substring of" in the first line of the description to > > "sequence of bytes from". > > So changed (in .../materials/man-page-changes.txt). OK. - Don > > Thanks. From rich.burridge@oracle.com Thu Jul 1 08:30:28 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o61FUSgr026701 for ; Thu, 1 Jul 2010 08:30:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o61FURss008451 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Jul 2010 08:30:27 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4V00I05XQRGW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 09:30:27 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4V009S5XQR7R90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 09:30:27 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o61FUQxU014168 for ; Thu, 01 Jul 2010 15:30:26 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o61FUN3K013050; Thu, 01 Jul 2010 15:30:23 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 374356601277998207; Thu, 01 Jul 2010 08:30:07 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 08:30:06 -0700 Date: Thu, 01 Jul 2010 08:32:55 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> To: Don Cragun Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C2CB527.8090305@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_DPzHhNhh93xJqBycEn835A)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C2CB490.023A:SCFMA4539814,ss=1,fgs=0 References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 2902 This is a multi-part message in MIME format. --Boundary_(ID_DPzHhNhh93xJqBycEn835A) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT > Don Cragun wrote: >>>> The expr(1) man page has: >>>> >>>> index string character-list >>>> >>>> Report the first position in which any one of the bytes >>>> in character-list matches a byte in string. >>>> >>> This is terrible! The man page you included below says that expr >>> is CSI enabled. >>> >> That's not correct. I've added a note to .../materials/man-page-changes.txt >> to say that that line in the ATTRIBUTES section should be adjusted to >> "Not enabled". >> > The test suite may not catch you, but if expr is not CSI enabled, you > don't conform to the standards. Since you have changed index to look > for a matching character (instead of just matching bytes), why is it > not CSI enabled? > This might be ignorance on my part, but shouldn't the code be using wchar instead of char in order to be CSI enabled? The latest version of expr.c is at: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/expr/expr.c There is no use of wchar. (The index() routine is at lines 363-376). >>> With a UTF-8 codeset, any multi-byte character >>> in a given code plane will match any other character in the same >>> code plane. This does not meet the definition of CSI enabled. >>> It should be something a lot more like: >>> >>> index string character-list >>> Report the first byte in "string" (counting from >>> zero) where a character from "character-list" >>> matches a character from "string". If no >>> character in "character-list" appears in "string", >>> XXX specify what happens in this case XXX. >>> >> So changed (and adjusting the XXX part accordingly) in >> .../materials/man-page-changes.txt. >> > Since you say that zero is returned if there is no match and > zero is returned if the first character matches, how does a > user know if a match was found? > I incorrectly answered your previous question. Same for the "substr str start len" operator. Both of these count from 1. I've updated .../materials/man-page-changes.txt to reflect this. Tested with the attached script: --Boundary_(ID_DPzHhNhh93xJqBycEn835A) Content-type: application/x-shellscript; name=expr-test.sh Content-transfer-encoding: base64 Content-disposition: attachment; filename=expr-test.sh IyEvYmluL2tzaCAteApFWFBSPS91c3IvYmluL2V4cHIKCmV4cG9ydCBTWVNWMz0xCgpwcmlu dCAiVGVzdGluZyAnaW5kZXggc3RyIGNoYXJsaXN0JyIKJEVYUFIgaW5kZXggJ0hlbGxvIHdv cmxkJyAiSCIgCiRFWFBSIGluZGV4ICdIZWxsbyB3b3JsZCcgIlkiIAoKcHJpbnQgIlRlc3Rp bmcgJ3N1YnN0ciBzdHIgc3RhcnQgbGVuJyIKJEVYUFIgc3Vic3RyICdIZWxsbyB3b3JsZCcg MSA1IAokRVhQUiBzdWJzdHIgJ0hlbGxvIHdvcmxkJyAwIDQgCg== --Boundary_(ID_DPzHhNhh93xJqBycEn835A)-- From rich.burridge@oracle.com Thu Jul 1 08:36:36 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o61Faahw026824 for ; Thu, 1 Jul 2010 08:36:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o61FaYOm010912 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Jul 2010 08:36:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4V00I1LY0ZYA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 09:36:35 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4V009GPY0Y7G90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 09:36:34 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o61FaXKv010190; Thu, 01 Jul 2010 15:36:34 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o61EjpJ8024911; Thu, 01 Jul 2010 15:36:29 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 388884221277998575; Thu, 01 Jul 2010 08:36:15 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 08:36:14 -0700 Date: Thu, 01 Jul 2010 08:39:03 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233, FastTrack timeout, 06/30/2010] In-reply-to: <201006302139.o5ULdMST012229@sac.sfbay.sun.com> To: John Fischer Cc: PSARC-ext@sun.com, Alan.Burlison@oracle.com Message-id: <4C2CB697.9020208@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C2CB600.0133:SCFMA4539814,ss=1,fgs=0 References: <201006302139.o5ULdMST012229@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 683 > > What sort of announcement will be made in a Patch release > of Solaris? Will this be release noted? Will the man pages > be updated to include a warning? Other? > It will be documented via a release note in a Patch release of Solaris. The P-Team and marketing will help craft the wording. It will also be announced to engineering in a flag day announcement Unless otherwise directed by either the C-Team or the P-Team, we are not planning to put a warning into the manual pages, because this functionality was only available on x86 and not SPARC, and because you typically had to set the SYSV3 environment variable to enable it. > Other then that +1. > Thanks. From john.fischer@oracle.com Thu Jul 1 09:55:24 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o61GtOF1028186 for ; Thu, 1 Jul 2010 09:55:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o61GtNBr016012 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Jul 2010 09:55:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4W00I031OB7K00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 09:55:23 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4W008VS1OBWNB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 09:55:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o61GtMXg008356 for ; Thu, 01 Jul 2010 16:55:22 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o61GtJ7i024503 for ; Thu, 01 Jul 2010 16:55:19 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 389126301278003286; Thu, 01 Jul 2010 09:54:46 -0700 Received: from [10.7.250.84] (/10.7.250.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 09:54:45 -0700 Date: Thu, 01 Jul 2010 09:54:44 -0700 From: John Fischer Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233, FastTrack timeout, 06/30/2010] In-reply-to: <4C2CB697.9020208@oracle.com> To: Rich Burridge Cc: PSARC-ext@sun.com, Alan.Burlison@oracle.com Message-id: <4C2CC854.6030008@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C2CC87A.0119:SCFMA4539814,ss=1,fgs=0 References: <201006302139.o5ULdMST012229@sac.sfbay.sun.com> <4C2CB697.9020208@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100524 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 909 Rich, Sounds good. You still have my +1. John On 07/ 1/10 08:39 AM, Rich Burridge wrote: >> >> What sort of announcement will be made in a Patch release >> of Solaris? Will this be release noted? Will the man pages >> be updated to include a warning? Other? > > It will be documented via a release note in a Patch release of Solaris. > The P-Team and marketing will help craft the wording. It will also be > announced to engineering in a flag day announcement > > Unless otherwise directed by either the C-Team or the P-Team, we > are not planning to put a warning into the manual pages, because > this functionality was only available on x86 and not SPARC, and > because you typically had to set the SYSV3 environment variable > to enable it. > > >> Other then that +1. > > Thanks. > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From dcragun@sonic.net Thu Jul 1 10:40:23 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o61HeNOR029129 for ; Thu, 1 Jul 2010 10:40:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o61HeLSw011554 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Jul 2010 12:40:22 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4W0040L3R99U00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 10:40:21 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4W00MH33R7HB50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 10:40:20 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o61HTLX3022234 for ; Thu, 01 Jul 2010 17:40:19 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-6147821 for PSARC-ext@sun.com; Thu, 01 Jul 2010 17:40:19 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-2541301 for PSARC-ext@sun.com; Thu, 01 Jul 2010 17:40:19 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-3017182 for PSARC-ext@sun.com; Thu, 01 Jul 2010 17:40:18 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o61HeFRw021611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 01 Jul 2010 10:40:15 -0700 Date: Thu, 01 Jul 2010 10:40:15 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C2CB527.8090305@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.249sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> Status: RO Content-Length: 3107 On Jul 1, 2010, at 8:32 AM, Rich Burridge wrote: Please find comments in-line below... >> Don Cragun wrote: >>>>> The expr(1) man page has: >>>>> >>>>> index string character-list >>>>> >>>>> Report the first position in which any one of the bytes >>>>> in character-list matches a byte in string. >>>>> >>>> This is terrible! The man page you included below says that expr >>>> is CSI enabled. >>>> >>> That's not correct. I've added a note to .../materials/man-page-changes.txt >>> to say that that line in the ATTRIBUTES section should be adjusted to >>> "Not enabled". >>> >> The test suite may not catch you, but if expr is not CSI enabled, you >> don't conform to the standards. Since you have changed index to look >> for a matching character (instead of just matching bytes), why is it >> not CSI enabled? >> > > This might be ignorance on my part, but shouldn't the code be > using wchar instead of char in order to be CSI enabled? > > The latest version of expr.c is at: > > http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/expr/expr.c > > There is no use of wchar. If you look at the code for match(), you will note that it calls ematch() which uses mbstowcs() to perform wide character processing for /usr/xpg[46]/bin/expr and counts characters matched while /usr/bin/expr doesn't use mbstowcs() and, therefore, counts bytes. This is stated in the description and noted in the last two examples on the man page you attached earlier. Most of the real multi-byte character stuff is hidden in the regexpr(3GEN) routines called by expr. > > (The index() routine is at lines 363-376). > The nested for loops in index() on L369-374 don't deal with characters; only bytes. If you're going to add these new operators to /usr/xpg[46]/bin/expr, I would think you would want them to process characters there instead of bytes to be consistent with the rest of the operators in those utilities. - Don > >>>> With a UTF-8 codeset, any multi-byte character >>>> in a given code plane will match any other character in the same >>>> code plane. This does not meet the definition of CSI enabled. >>>> It should be something a lot more like: >>>> >>>> index string character-list >>>> Report the first byte in "string" (counting from >>>> zero) where a character from "character-list" >>>> matches a character from "string". If no >>>> character in "character-list" appears in "string", >>>> XXX specify what happens in this case XXX. >>>> >>> So changed (and adjusting the XXX part accordingly) in >>> .../materials/man-page-changes.txt. >>> >> Since you say that zero is returned if there is no match and >> zero is returned if the first character matches, how does a >> user know if a match was found? >> > > I incorrectly answered your previous question. Same for > the "substr str start len" operator. Both of these count from 1. > > I've updated .../materials/man-page-changes.txt to reflect this. > > Tested with the attached script: > > > From rich.burridge@oracle.com Thu Jul 1 11:27:03 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o61IR3Ak000193 for ; Thu, 1 Jul 2010 11:27:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o61IR0rC014318 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Jul 2010 12:27:02 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4W007055X1G000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 11:27:01 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4W00I1M5X1WLE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Jul 2010 11:27:01 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o61IR0Ji027710 for ; Thu, 01 Jul 2010 18:27:00 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o618dEbW026375; Thu, 01 Jul 2010 18:26:55 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 389333431278008732; Thu, 01 Jul 2010 11:25:32 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 11:25:31 -0700 Date: Thu, 01 Jul 2010 11:28:19 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> To: Don Cragun Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C2CDE43.30605@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C2CDDF2.01D1:SCFMA4539814,ss=1,fgs=0 References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 1830 Don Cragun wrote: > This might be ignorance on my part, but shouldn't the code be > using wchar instead of char in order to be CSI enabled? > > The latest version of expr.c is at: > > http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/expr/expr.c > > There is no use of wchar. > > If you look at the code for match(), you will note that it calls > ematch() which uses mbstowcs() to perform wide character processing > for /usr/xpg[46]/bin/expr and counts characters matched while > /usr/bin/expr doesn't use mbstowcs() and, therefore, counts bytes. > This is stated in the description and noted in the last two examples > on the man page you attached earlier. Most of the real multi-byte > character stuff is hidden in the regexpr(3GEN) routines called by expr. > Ah. Thanks for the edification. > >> (The index() routine is at lines 363-376). >> >> > The nested for loops in index() on L369-374 don't deal with characters; > only bytes. > > If you're going to add these new operators to /usr/xpg[46]/bin/expr, > I would think you would want them to process characters there instead > of bytes to be consistent with the rest of the operators in those > utilities. > We are not planning on adding these three operators to /usr/xpg[46]/bin/expr. To that end, I've made the following changes to the expr(1) section of .../materials/man-page-changes.txt: In the ATTRIBUTES section, the CSI attribute line will be changed to: | CSI | Enabled. See NOTES. | and a new NOTES section added, which will contain: NOTES The following three operators are not available in /usr/xpg4/bin/expr and /usr/xpg6/bin/expr index string character-list length string substr string integer-1 integer-2 Thanks. From dcragun@sonic.net Fri Jul 2 12:17:51 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o62JHpG7019758 for ; Fri, 2 Jul 2010 12:17:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o62JHpgp022382 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Jul 2010 12:17:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4Y00I012XR7X00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 02 Jul 2010 12:17:51 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4Y00ERS2XRMV10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 02 Jul 2010 12:17:51 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o62JBePq002422 for ; Fri, 02 Jul 2010 19:17:50 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-4131484 for PSARC-ext@Sun.COM; Fri, 02 Jul 2010 19:17:50 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-4556969 for PSARC-ext@Sun.COM; Fri, 02 Jul 2010 19:17:50 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-11399573 for PSARC-ext@Sun.COM; Fri, 02 Jul 2010 19:17:49 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o62JHk6w006289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 02 Jul 2010 12:17:47 -0700 Date: Fri, 02 Jul 2010 12:17:47 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C2CDE43.30605@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.400sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> Status: RO Content-Length: 2965 On Jul 1, 2010, at 11:28 AM, Rich Burridge wrote: > > Don Cragun wrote: >> This might be ignorance on my part, but shouldn't the code be >> using wchar instead of char in order to be CSI enabled? >> >> The latest version of expr.c is at: >> >> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/expr/expr.c >> >> There is no use of wchar. >> If you look at the code for match(), you will note that it calls >> ematch() which uses mbstowcs() to perform wide character processing >> for /usr/xpg[46]/bin/expr and counts characters matched while >> /usr/bin/expr doesn't use mbstowcs() and, therefore, counts bytes. >> This is stated in the description and noted in the last two examples >> on the man page you attached earlier. Most of the real multi-byte >> character stuff is hidden in the regexpr(3GEN) routines called by expr. >> > > Ah. Thanks for the edification. Glad to help. > >> >>> (The index() routine is at lines 363-376). >>> >>> >> The nested for loops in index() on L369-374 don't deal with characters; >> only bytes. >> >> If you're going to add these new operators to /usr/xpg[46]/bin/expr, >> I would think you would want them to process characters there instead >> of bytes to be consistent with the rest of the operators in those >> utilities. >> > > We are not planning on adding these three operators to /usr/xpg[46]/bin/expr. > > To that end, I've made the following changes to the expr(1) section of > .../materials/man-page-changes.txt: > > In the ATTRIBUTES section, the CSI attribute line will be changed to: > > | CSI | Enabled. See NOTES. | > > and a new NOTES section added, which will contain: > > > NOTES > > The following three operators are not available in > /usr/xpg4/bin/expr and /usr/xpg6/bin/expr > > index string character-list > > length string > > substr string integer-1 integer-2 Have you checked to see whether this is the way GNU expr handles index, length, and substr when dealing with multi-byte characters? I see that OpenBSD has dropped these operators. I would have expected that GNU expr would have made changes to support I18N in these operators when it changed to support I18N in the match (another POSIX extension) and the ":" (required by POSIX) operators. I thought the purpose of this case was to support the index, length, and substr extensions to the required set of expr operators in a manner matching current practice. It looks like what you are doing is taking obsolete (1970s and 1980s era) uninternationalized behavior and making it available without requiring use of the environment variable that clearly marked it as a request for obsolete behavior. If this doesn't match current GNU behavior, I think it would be much better to remove these operators completely, or to add them (and the match operator) to behave as they work in GNU expr. - Don > > Thanks. From Alan.Burlison@oracle.com Sat Jul 3 02:48:00 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o639m0uM003321 for ; Sat, 3 Jul 2010 02:48:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o639m0MW016501 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Sat, 3 Jul 2010 02:48:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4Z00601780W700@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 03 Jul 2010 03:48:00 -0600 (MDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4Z008U177ZSP60@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 03 Jul 2010 03:47:59 -0600 (MDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o639lvGS010303; Sat, 03 Jul 2010 10:47:57 +0100 (BST) Received: from vpn-129-150-121-66.uk.sun.com ([129.150.121.66]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1OUzKH-00068S-0f; Sat, 03 Jul 2010 10:47:57 +0100 Date: Sat, 03 Jul 2010 10:47:56 +0100 From: Alan Burlison Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: To: Don Cragun Cc: Rich Burridge , PSARC-ext@sun.com Message-id: <4C2F074C.8020803@oracle.com> Organization: Oracle MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Thunderbird/3.0.3 Status: RO Content-Length: 1930 On 02/07/2010 20:17, Don Cragun wrote: > I thought the purpose of this case was to support the index, length, and > substr extensions to the required set of expr operators in a manner > matching current practice. It looks like what you are doing is taking > obsolete (1970s and 1980s era) uninternationalized behavior and making > it available without requiring use of the environment variable that > clearly marked it as a request for obsolete behavior. If this doesn't > match current GNU behavior, I think it would be much better to remove > these operators completely, or to add them (and the match operator) to > behave as they work in GNU expr. The purpose of this case is as per the title - to remove the SYSV3 environment variable. One consequence of that goal is we have to decide what to do with the non-conflicting old behaviour that the SYSV3 environment variable enabled. In the case of expr it seemed that it was better to retain the behaviour - if people aren't using it they won't notice a change in behaviour and if people are setting SYSV3 they won't notice any difference either, for although the envvar will be ignored, the behaviour will still be available. As has already been discussed, expr is not CSI enabled (despite what the manpage says). so adding CSI versions of index, length and substr whilst leaving everything else non-CSI clearly isn't a good idea. I agree that providing an internationalised version of expr is a worthy goal, but it is not the goal of this particular case. The focus here is to remove the SYSV3 envvar whilst causing the minimum of backwards compatibility issues, and on that basis I believe the proposed changes are the best solution. Yes, that has the side-effect of increasing GNU compatibility, but that wasn't the primary motivation. I expect there will be a followup case to address the GNU compatibility and i18n issues. -- Alan Burlison -- From dcragun@sonic.net Mon Jul 5 22:14:41 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o665Eeuw008182 for ; Mon, 5 Jul 2010 22:14:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o665Ee8c013582 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 5 Jul 2010 22:14:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5400K05EKGHI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 05 Jul 2010 23:14:40 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5400FEWEKGOQ60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 05 Jul 2010 23:14:40 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o665EdLs006717 for ; Tue, 06 Jul 2010 05:14:39 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-4250166 for PSARC-ext@Sun.COM; Tue, 06 Jul 2010 05:14:39 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-11313845 for PSARC-ext@Sun.COM; Tue, 06 Jul 2010 05:14:39 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-18969580 for PSARC-ext@Sun.COM; Tue, 06 Jul 2010 05:14:38 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o665EXRv021447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 05 Jul 2010 22:14:33 -0700 Date: Mon, 05 Jul 2010 22:14:33 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C2F074C.8020803@oracle.com> To: Alan Burlison Cc: Rich Burridge , PSARC-ext@sun.com Message-id: <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.275sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> <4C2F074C.8020803@oracle.com> Status: RO Content-Length: 4663 On Jul 3, 2010, at 2:47 AM, Alan Burlison wrote: > On 02/07/2010 20:17, Don Cragun wrote: > >> I thought the purpose of this case was to support the index, length, and >> substr extensions to the required set of expr operators in a manner >> matching current practice. It looks like what you are doing is taking >> obsolete (1970s and 1980s era) uninternationalized behavior and making >> it available without requiring use of the environment variable that >> clearly marked it as a request for obsolete behavior. If this doesn't >> match current GNU behavior, I think it would be much better to remove >> these operators completely, or to add them (and the match operator) to >> behave as they work in GNU expr. > > The purpose of this case is as per the title - to remove the SYSV3 environment variable. One consequence of that goal is we have to decide what to do with the non-conflicting old behaviour that the SYSV3 environment variable enabled. In the case of expr it seemed that it was better to retain the behaviour - if people aren't using it they won't notice a change in behaviour and if people are setting SYSV3 they won't notice any difference either, for although the envvar will be ignored, the behaviour will still be available. 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. 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? 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? > > As has already been discussed, expr is not CSI enabled (despite what the manpage says). so adding CSI versions of index, length and substr whilst leaving everything else non-CSI clearly isn't a good idea. 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 agree that providing an internationalised version of expr is a worthy goal, but it is not the goal of this particular case. The focus here is to remove the SYSV3 envvar whilst causing the minimum of backwards compatibility issues, and on that basis I believe the proposed changes are the best solution. Yes, that has the side-effect of increasing GNU compatibility, but that wasn't the primary motivation. 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. > > I expect there will be a followup case to address the GNU compatibility and i18n issues. 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. 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? 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.) - Don > > -- > Alan Burlison From rich.burridge@oracle.com Wed Jul 7 06:18:29 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67DITlR007642 for ; Wed, 7 Jul 2010 06:18:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67DITM4018902 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Jul 2010 06:18:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5600801VMTF900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 06:18:29 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5600F5FVMS0HD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 06:18:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o67DISue002642 for ; Wed, 07 Jul 2010 13:18:28 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o67Cjmo8003414; Wed, 07 Jul 2010 13:18:20 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 405826931278508695; Wed, 07 Jul 2010 06:18:15 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jul 2010 06:18:03 -0700 Date: Wed, 07 Jul 2010 06:20:54 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] To: Don Cragun Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C347F36.408@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_VYwV4vtgWpRgVT/0+UnG7w)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C347EA1.01A6:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 5629 This is a multi-part message in MIME format. --Boundary_(ID_VYwV4vtgWpRgVT/0+UnG7w) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT 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 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 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. > 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 > 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. --Boundary_(ID_VYwV4vtgWpRgVT/0+UnG7w) Content-type: application/x-shellscript; name=expr-index-test.sh Content-transfer-encoding: base64 Content-disposition: attachment; filename=expr-index-test.sh IyEvYmluL2tzaCAteApFWFBSPS91c3IvYmluL2V4cHIub3JpZwoKcHJpbnQgIlRlc3Rpbmcg Y3VycmVudCB2ZXJzaW9uIG9mIGV4cHIiCi91c3IvYmluL2V4cHIub3JpZyBpbmRleAovdXNy L2Jpbi9leHByLm9yaWcgaW5kZXggJ0hlbGxvIHdvcmxkJyAiSCIKCnByaW50ICJUZXN0aW5n IHByb3Bvc2VkIG5ldyB2ZXJzaW9uIG9mIGV4cHIiCi91c3IvYmluL2V4cHIgaW5kZXgKL3Vz ci9iaW4vZXhwciBpbmRleCAnSGVsbG8gd29ybGQnICJIIgo= --Boundary_(ID_VYwV4vtgWpRgVT/0+UnG7w)-- From Alan.Burlison@oracle.com Wed Jul 7 06:52:49 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67Dqn4O008037 for ; Wed, 7 Jul 2010 06:52:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67DqnT1013287 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 7 Jul 2010 06:52:49 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L560090BX81Z200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 06:52:49 -0700 (PDT) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5600FEXX7Z07F0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 06:52:48 -0700 (PDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67DqkPa003563; Wed, 07 Jul 2010 14:52:46 +0100 (BST) Received: from vpn-129-150-121-66.uk.sun.com ([129.150.121.66]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1OW41f-0000Tq-9T; Tue, 06 Jul 2010 10:01:11 +0100 Date: Tue, 06 Jul 2010 10:07:26 +0100 From: Alan Burlison Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> To: Don Cragun Cc: Rich Burridge , PSARC-ext@sun.com Message-id: <4C32F24E.8070402@oracle.com> Organization: Oracle MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> <4C2F074C.8020803@oracle.com> <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Thunderbird/3.0.3 Status: RO Content-Length: 3735 On 06/07/2010 06:14, Don Cragun wrote: > 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? 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? expr.c contains: #ifdef _iBCS2 sysv3_set = getenv("SYSV3"); #endif /* _iBCS2 */ so despite the manpage, expr does take note of the SYSV3 envvar. >> As has already been discussed, expr is not CSI enabled (despite what the manpage says). so adding CSI versions of index, length and substr whilst leaving everything else non-CSI clearly isn't a good idea. > > 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'm confused here - from a previous exchange you had with Rich: |>> This is terrible! The man page you included below says that expr |>> is CSI enabled. |> |> That's not correct. I've added a note to .../materials/man-page-changes.txt |> to say that that line in the ATTRIBUTES section should be adjusted to |> "Not enabled". >> I agree that providing an internationalised version of expr is a worthy goal, but it is not the goal of this particular case. The focus here is to remove the SYSV3 envvar whilst causing the minimum of backwards compatibility issues, and on that basis I believe the proposed changes are the best solution. Yes, that has the side-effect of increasing GNU compatibility, but that wasn't the primary motivation. > > 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. I'm not clear exactly what you are referring to when you say 'incompatible', are you referring to the CSI behaviour? I had a very quick look at the GNU implementation and as far as I can tell, the operators in question are all byte-level, not char-level. > 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? That will need to be checked - thanks. > 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.) That's true, but it isn't possible to add any operators without changing behaviour, by definition - or at least I'm not aware of any way of doing it. -- Alan Burlison -- From dcragun@sonic.net Wed Jul 7 11:28:20 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67ISKS5011911 for ; Wed, 7 Jul 2010 11:28:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67ISJKU021027 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Jul 2010 11:28:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L57006039Z7B400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 11:28:19 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L57001849Z7NX80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 11:28:19 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o67I0nYk009524 for ; Wed, 07 Jul 2010 18:28:19 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-533693 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 18:28:18 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-416902 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 18:28:18 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-31208410 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 18:28:17 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o67ISErT029072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 07 Jul 2010 11:28:15 -0700 Date: Wed, 07 Jul 2010 11:28:14 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C347F36.408@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <21CBB01F-C075-46C3-B90B-C32C89E3E23B@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.390sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C347F36.408@oracle.com> Status: RO Content-Length: 7522 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 From dcragun@sonic.net Wed Jul 7 11:37:07 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67Ib7cU012159 for ; Wed, 7 Jul 2010 11:37:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67Ib74c013716 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Jul 2010 11:37:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5700K03ADU4N00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 12:37:06 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L57006B9ADUYR60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 12:37:06 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o67Ib5Rc000316 for ; Wed, 07 Jul 2010 18:37:05 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-344490 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 18:37:05 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-12669097 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 18:37:05 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay4i.sun.com with ESMTP id BT-MMP-2760186 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 18:37:04 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o67Ib15t002960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 07 Jul 2010 11:37:01 -0700 Date: Wed, 07 Jul 2010 11:37:01 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C32F24E.8070402@oracle.com> To: Alan Burlison Cc: Rich Burridge , PSARC-ext@sun.com Message-id: <3EEC2730-1E8A-4489-B250-75692F7E7338@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.111sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> <4C2F074C.8020803@oracle.com> <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> <4C32F24E.8070402@oracle.com> Status: RO Content-Length: 5322 On Jul 6, 2010, at 2:07 AM, Alan Burlison wrote: > On 06/07/2010 06:14, Don Cragun wrote: > >> 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? 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? > > expr.c contains: > > #ifdef _iBCS2 > sysv3_set = getenv("SYSV3"); > #endif /* _iBCS2 */ > > so despite the manpage, expr does take note of the SYSV3 envvar. Partially. On x86 INDEX, LENGTH, and SUBSTR are always recognized by the expr yacc grammar. After the grammar recognizes that it has found one of these operators, it reports a syntax error instead of treating them as a "string" operator when SYSV3 is not in the environment. > >>> As has already been discussed, expr is not CSI enabled (despite what the manpage says). so adding CSI versions of index, length and substr whilst leaving everything else non-CSI clearly isn't a good idea. >> >> 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'm confused here - from a previous exchange you had with Rich: > > |>> This is terrible! The man page you included below says that expr > |>> is CSI enabled. > |> > |> That's not correct. I've added a note to .../materials/man-page-changes.txt > |> to say that that line in the ATTRIBUTES section should be adjusted to > |> "Not enabled". > >>> I agree that providing an internationalised version of expr is a worthy goal, but it is not the goal of this particular case. The focus here is to remove the SYSV3 envvar whilst causing the minimum of backwards compatibility issues, and on that basis I believe the proposed changes are the best solution. Yes, that has the side-effect of increasing GNU compatibility, but that wasn't the primary motivation. >> >> 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. > > I'm not clear exactly what you are referring to when you say 'incompatible', are you referring to the CSI behaviour? I had a very quick look at the GNU implementation and as far as I can tell, the operators in question are all byte-level, not char-level. I'll take your word for it. The Linux expr man pages I have found that describe the behavior of index, length, and substr all say they handle characters; not bytes. The architectural issue that is left here is that you are now promoting the index, length, and substr operators from "included only for compatibility with INTERACTIVE UNIX System only and are not intended to be used by non-INTERACTIVE UNIX System scripts" to falling into the Interface Stability for the rest of the operators with is committed. If GNU expr actually changes to make index, length, and substr work on characters (instead of bytes) as documented in their man pages; a future case will not be able to align with the "fixed" GNU behavior without a major release binding. To get around this, I believe that the Interface Stability level for the index, length, match, and substr operators should be made to be uncommitted. > >> 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? > > That will need to be checked - thanks. Rich already responded to this. And I noted a correction in the response I sent a few mintues ago. > >> 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.) > > That's true, but it isn't possible to add any operators without changing behaviour, by definition - or at least I'm not aware of any way of doing it. On x86 this has been a problem for well over a decade. You are now spreading the problem to SPARC. I'm not sure if this is an architectural issue or not. - Don > -- > Alan Burlison From rich.burridge@oracle.com Wed Jul 7 13:34:51 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67KYoY0016289 for ; Wed, 7 Jul 2010 13:34:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67KYoes010409 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Jul 2010 15:34:50 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5700A0NFU23R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 13:34:50 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L57004GNFU1ZS20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 13:34:50 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o67KYnGR029502 for ; Wed, 07 Jul 2010 20:34:49 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o67Jg4Ls031955; Wed, 07 Jul 2010 20:34:47 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 407195391278534861; Wed, 07 Jul 2010 13:34:21 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jul 2010 13:34:20 -0700 Date: Wed, 07 Jul 2010 13:37:13 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <21CBB01F-C075-46C3-B90B-C32C89E3E23B@sonic.net> To: Don Cragun Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C34E579.2040709@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C34E4E7.023A:SCFMA4539814,ss=1,fgs=0 References: <4C347F36.408@oracle.com> <21CBB01F-C075-46C3-B90B-C32C89E3E23B@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 1160 On 07/07/10 11:28, Don Cragun wrote: > ... > 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. > > ... > 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). > Okay. So changed (see .../materials/man-page-changes.txt). If the wording is insufficient or incorrect, please suggest alternative text to be used. I'll let Alan respond to the concerns your raised in your reply to his email. Thanks. From dcragun@sonic.net Wed Jul 7 14:35:44 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67LZiDD017378 for ; Wed, 7 Jul 2010 14:35:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o67LZhl3048104 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Jul 2010 15:35:43 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5700007INJ5J00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 14:35:43 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L57004KTINIZQ70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 14:35:43 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o67LV6ih025226 for ; Wed, 07 Jul 2010 21:35:42 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-542651 for PSARC-ext@sun.com; Wed, 07 Jul 2010 21:35:37 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-15238156 for PSARC-ext@sun.com; Wed, 07 Jul 2010 21:35:36 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-31609625 for PSARC-ext@sun.com; Wed, 07 Jul 2010 21:35:36 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o67LZXhM018167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 07 Jul 2010 14:35:33 -0700 Date: Wed, 07 Jul 2010 14:35:33 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C34E579.2040709@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.253sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C347F36.408@oracle.com> <21CBB01F-C075-46C3-B90B-C32C89E3E23B@sonic.net> <4C34E579.2040709@oracle.com> Status: RO Content-Length: 2305 On Jul 7, 2010, at 1:37 PM, Rich Burridge wrote: > On 07/07/10 11:28, Don Cragun wrote: >> ... >> 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. >> ... >> 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). >> > > Okay. So changed (see .../materials/man-page-changes.txt). > If the wording is insufficient or incorrect, please suggest > alternative text to be used. I waited for the external reposter to update: http://arc.opensolaris.org/caselog/PSARC/2010/233/materials/man-page-changes.txt to reflect your changes. The parent directory listing shows that this file was updated 07-Jul-2010 @ 20:29 (UTC) which is 13:29 PDT (less than 10 minutes ago), but there is still no mention of the match operator and no mention of the fact that index, length, match, and substr all have the same precedence. In addition to that the description of index: Report the first byte in "string" (counting from one) where a character from "character-list" matches a character from "string". If no character in "character-list" appears in "string", "0" is returned. should be something more like: Report the first byte in "string" (counting from one) where a byte from "character-list" matches a byte from "string". If no byte in "character-list" appears in "string", "0" is returned. since it is looking for a byte match; not a character match. - Don > > I'll let Alan respond to the concerns your raised in your reply > to his email. > > Thanks. > From rich.burridge@oracle.com Wed Jul 7 14:51:08 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67Lp8Xc017806 for ; Wed, 7 Jul 2010 14:51:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67Lp8fp027301 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Jul 2010 14:51:08 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5700F05JD83D00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 15:51:08 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L57006VVJD7YWD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Jul 2010 15:51:07 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o67Lp6uR008165 for ; Wed, 07 Jul 2010 21:51:06 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o673bnIT029550; Wed, 07 Jul 2010 21:51:03 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 387214391278539391; Wed, 07 Jul 2010 14:49:51 -0700 Received: from [10.0.1.16] (/71.204.170.13) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jul 2010 14:49:51 -0700 Date: Wed, 07 Jul 2010 14:49:54 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: To: Don Cragun Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C34F682.1090607@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C34F6C7.027B:SCFMA4539814,ss=1,fgs=0 References: <4C347F36.408@oracle.com> <21CBB01F-C075-46C3-B90B-C32C89E3E23B@sonic.net> <4C34E579.2040709@oracle.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 Status: RO Content-Length: 1670 On 07/07/2010 02:35 PM, Don Cragun wrote: > ... >> Okay. So changed (see .../materials/man-page-changes.txt). >> If the wording is insufficient or incorrect, please suggest >> alternative text to be used. >> > I waited for the external reposter to update: > http://arc.opensolaris.org/caselog/PSARC/2010/233/materials/man-page-changes.txt > to reflect your changes. The parent directory listing shows that this > file was updated 07-Jul-2010 @ 20:29 (UTC) which is 13:29 PDT (less than > 10 minutes ago), but there is still no mention of the match operator It seems to be there for me at that URL: The following new operator will be added just before the entry for: "substr string integer-1 integer-2" match string regular-expression Synonymous with the 'expr : expr' matching operator. > and > no mention of the fact that index, length, match, and substr all have the > same precedence. > Okay. I'll make that change tomorrow. > In addition to that the description of index: > Report the first byte in "string" (counting from > one) where a character from "character-list" > matches a character from "string". If no > character in "character-list" appears in "string", > "0" is returned. > should be something more like: > Report the first byte in "string" (counting from > one) where a byte from "character-list" > matches a byte from "string". If no > byte in "character-list" appears in "string", > "0" is returned. > since it is looking for a byte match; not a character match. > Okay. I'll make that change tomorrow too. From dcragun@sonic.net Wed Jul 7 15:14:44 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o67MEiYl018902 for ; Wed, 7 Jul 2010 15:14:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o67MEhrp005069 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Jul 2010 15:14:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5700C0JKGJMF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 15:14:43 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L57005U7KGI8M40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 07 Jul 2010 15:14:42 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o67MD7xX015622 for ; Wed, 07 Jul 2010 22:14:41 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay44i.sun.com with ESMTP id BT-MMP-26008 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 22:14:41 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-12975897 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 22:14:40 +0000 (Z) Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay4i.sun.com with ESMTP id BT-MMP-215729 for PSARC-ext@Sun.COM; Wed, 07 Jul 2010 22:14:40 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o67MEZsc012757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 07 Jul 2010 15:14:37 -0700 Date: Wed, 07 Jul 2010 15:14:35 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C34F682.1090607@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.229sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C347F36.408@oracle.com> <21CBB01F-C075-46C3-B90B-C32C89E3E23B@sonic.net> <4C34E579.2040709@oracle.com> <4C34F682.1090607@oracle.com> Status: RO Content-Length: 1808 On Jul 7, 2010, at 2:49 PM, Rich Burridge wrote: > On 07/07/2010 02:35 PM, Don Cragun wrote: >> ... >>> Okay. So changed (see .../materials/man-page-changes.txt). >>> If the wording is insufficient or incorrect, please suggest >>> alternative text to be used. >>> >> I waited for the external reposter to update: >> http://arc.opensolaris.org/caselog/PSARC/2010/233/materials/man-page-changes.txt >> to reflect your changes. The parent directory listing shows that this >> file was updated 07-Jul-2010 @ 20:29 (UTC) which is 13:29 PDT (less than >> 10 minutes ago), but there is still no mention of the match operator > > It seems to be there for me at that URL: > > The following new operator will be added just before the entry for: > "substr string integer-1 integer-2" > > match string regular-expression > > Synonymous with the 'expr : expr' matching operator. OK. This looks good. > > >> and >> no mention of the fact that index, length, match, and substr all have the >> same precedence. >> > > Okay. I'll make that change tomorrow. Good. > >> In addition to that the description of index: >> Report the first byte in "string" (counting from >> one) where a character from "character-list" >> matches a character from "string". If no >> character in "character-list" appears in "string", >> "0" is returned. >> should be something more like: >> Report the first byte in "string" (counting from >> one) where a byte from "character-list" >> matches a byte from "string". If no >> byte in "character-list" appears in "string", >> "0" is returned. >> since it is looking for a byte match; not a character match. >> > > Okay. I'll make that change tomorrow too. Good. - Don From Alan.Burlison@oracle.com Thu Jul 8 01:41:28 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o688fSHP025909 for ; Thu, 8 Jul 2010 01:41:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o688fSWc017093 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Thu, 8 Jul 2010 01:41:28 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5800805DH4PC00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Jul 2010 02:41:28 -0600 (MDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5800GNPDH2W160@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Jul 2010 02:41:27 -0600 (MDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o688fPNH020963; Thu, 08 Jul 2010 09:41:25 +0100 (BST) Received: from vpn-129-150-121-66.uk.sun.com ([129.150.121.66]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1OWmZY-00055Z-DI; Thu, 08 Jul 2010 09:35:08 +0100 Date: Thu, 08 Jul 2010 09:41:25 +0100 From: Alan Burlison Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <3EEC2730-1E8A-4489-B250-75692F7E7338@sonic.net> To: Don Cragun Cc: Rich Burridge , PSARC-ext@sun.com Message-id: <4C358F35.9000808@oracle.com> Organization: Oracle MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> <4C2F074C.8020803@oracle.com> <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> <4C32F24E.8070402@oracle.com> <3EEC2730-1E8A-4489-B250-75692F7E7338@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Thunderbird/3.0.3 Status: RO Content-Length: 243 On 07/07/2010 19:37, Don Cragun wrote: > To get around this, I believe that the Interface Stability level for > the index, length, match, and substr operators should be made to be > uncommitted. That sounds reasonable. -- Alan Burlison -- From dcragun@sonic.net Thu Jul 8 06:16:09 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o68DG9l3000772 for ; Thu, 8 Jul 2010 06:16:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o68DG86r057993 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Jul 2010 07:16:09 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5800A3TQ6WR800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Jul 2010 07:16:08 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L58002T1Q6VJ740@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Jul 2010 07:16:08 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o68DAN0o004901 for ; Thu, 08 Jul 2010 13:16:07 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-4425323 for PSARC-ext@Sun.COM; Thu, 08 Jul 2010 13:16:06 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-16660755 for PSARC-ext@Sun.COM; Thu, 08 Jul 2010 13:16:06 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-24961686 for PSARC-ext@Sun.COM; Thu, 08 Jul 2010 13:16:06 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o68DG3p5006160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Jul 2010 06:16:03 -0700 Date: Thu, 08 Jul 2010 06:16:01 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C358F35.9000808@oracle.com> To: Alan Burlison Cc: Rich Burridge , PSARC-ext@sun.com Message-id: <0BB72BC3-1266-4470-8BC4-67D75FF7CF1F@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.072sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> <4C2F074C.8020803@oracle.com> <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> <4C32F24E.8070402@oracle.com> <3EEC2730-1E8A-4489-B250-75692F7E7338@sonic.net> <4C358F35.9000808@oracle.com> Status: RO Content-Length: 480 On Jul 8, 2010, at 1:41 AM, Alan Burlison wrote: > On 07/07/2010 19:37, Don Cragun wrote: > >> To get around this, I believe that the Interface Stability level for >> the index, length, match, and substr operators should be made to be >> uncommitted. > > That sounds reasonable. OK. If this change can be added to the changes Rich has already promised to make today to man-page-changes.txt, I believe that all of my issues have been resolved. - Don > -- > Alan Burlison From rich.burridge@oracle.com Thu Jul 8 06:52:23 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o68DqMjX000989 for ; Thu, 8 Jul 2010 06:52:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o68DqK36020246 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Jul 2010 08:52:22 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5800017RVA7B00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Jul 2010 06:52:22 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5800FB2RV9M840@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Jul 2010 06:52:21 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o68DqLUi024335 for ; Thu, 08 Jul 2010 13:52:21 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o68CvQO0000780; Thu, 08 Jul 2010 13:52:18 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 409478631278597069; Thu, 08 Jul 2010 06:51:09 -0700 Received: from [129.146.228.20] (/129.146.228.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Jul 2010 06:51:08 -0700 Date: Thu, 08 Jul 2010 06:54:00 -0700 From: Rich Burridge Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <0BB72BC3-1266-4470-8BC4-67D75FF7CF1F@sonic.net> To: Don Cragun Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <4C35D878.6060800@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Q/WCqE0gtGpQ2cf3ZMOlLg)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C35D812.0166:SCFMA4539814,ss=1,fgs=0 References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> <4C2F074C.8020803@oracle.com> <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> <4C32F24E.8070402@oracle.com> <3EEC2730-1E8A-4489-B250-75692F7E7338@sonic.net> <4C358F35.9000808@oracle.com> <0BB72BC3-1266-4470-8BC4-67D75FF7CF1F@sonic.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 Status: RO Content-Length: 8534 This is a multi-part message in MIME format. --Boundary_(ID_Q/WCqE0gtGpQ2cf3ZMOlLg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT On 07/08/10 06:16, Don Cragun wrote: > ... > OK. If this change can be added to the changes Rich has already promised > to make today to man-page-changes.txt, I believe that all of my issues > have been resolved. > Done (and attached). If there are any other tweaks, you think should be made, please let us know. Thanks. --Boundary_(ID_Q/WCqE0gtGpQ2cf3ZMOlLg) Content-type: text/plain; name=man-page-changes.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=man-page-changes.txt The following changes will be made when this EOF is implemented: ----------------------------------------------------------------------------- df(1M) The following text will be removed from the "ENVIRONMENT VARIABLES" section: SYSV3 This variable is used to override the default behavior of df and provide compatibility with INTERACTIVE UNIX System and SCO UNIX installation scripts. As the SYSV3 variable is provided for compatibility purposes only, it should not be used in new scripts. ----------------------------------------------------------------------------- echo(1) The following text will be removed from the "DESCRIPTION" section: sh's echo and /usr/bin/echo have an -n option if the SYSV3 environment variable is set (see ENVIRONMENT VARIABLES below). The following text will be removed from the "ENVIRONMENT VARIABLES" section: SYSV3 This environment variable is used to provide compa- tibility with INTERACTIVE UNIX System and SCO UNIX installation scripts. It is intended for compati- bility only and should not be used in new scripts. This variable is applicable only for Solaris x86 platforms, not Solaris SPARC systems. ----------------------------------------------------------------------------- expr(1) The following text will be removed from the "OPERANDS" section: 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: The following new operator will be added just before the entry for: "substr string integer-1 integer-2" match string regular-expression Synonymous with the 'expr : expr' matching operator. The following changes will be made to these three operators: substr string integer-1 integer-2 Extract the sequence of bytes from string (counting from one) starting at position integer-1 and of length integer-2 bytes. If integer-1 has a value greater than the number of bytes in string, expr returns a null string. If you try to extract more bytes than there are in string, expr returns all the remaining bytes from string. Results are unspecified if either integer-1 or integer-2 is a negative value. length string Return the length (that is, the number of bytes) of string. The terminating nul character is not included in that count. index string character-list Report the first byte in "string" (counting from one) where a byte from "character-list" matches a byte from "string". If no bytes in "character-list" appears in "string", "0" is returned. A sentence will be added to indicate that these four operators (match, substr, length and index) are all at the same precedence. In the ATTRIBUTES section, the CSI attribute line will be changed to: _____________________________ _____________________________ | CSI | Enabled. See NOTES. | |_____________________________|_____________________________| and a new NOTES section added, which will contain: 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 The Interface Stability entry in the ATTRIBUTES table will be adjusted to contain: _____________________________ _____________________________ | | Committed except for the | | | following operators which | | Interface Stability | are Uncommitted: match, | | | substr, length and index | |_____________________________|_____________________________| ----------------------------------------------------------------------------- tar(1) The "SYNOPSIS" section will be adjusted to remove references to the "e", "k" and "q" options. The "OPERANDS" section will have the following entries removed: e The SYSV3 environment vari- able overrides the default behavior. (See ENVIRONMENT VARIABLES section below.) k size Requires tar to use the size argument as the size of an archive in kilobytes. This is useful when the archive is intended for a fixed size device such as floppy disks. Large files are then split across volumes if they do not fit in the specified size. q Stop after extracting the first occurrence of the named file. tar normally continues reading the archive after finding an occurrence of a file. and the following text will be removed from the 'F" entry: The SYSV3 environment variable over- rides the default behavior. (See ENVIRONMENT VARIABLES section below.) The following text will be removed from the "ENVIRONMENT VARIABLES" section: SYSV3 This variable is used to override the default behavior of tar, provide compatibility with INTERACTIVE UNIX Sys- tems and SCO UNIX installation scripts, and should not be used in new scripts. (It is intended for compatibil- ity purposes only.) When set, the following function modifiers behave differently: F filename Uses filename to obtain a list of command line switches and files on which to operate. e Prevents files from being split across volumes. If there is insufficient room on one volume, tar prompts for a new volume. If the file does not fit on the new volume, tar exits with an error. ----------------------------------------------------------------------------- uname(1) The following text will be removed from the "ENVIRONMENT VARIABLES" section: SYSV3 This variable is used to override the default behavior of uname. This is necessary to make it possible for some INTERACTIVE UNIX Systems and SCO UNIX programs and scripts to work properly. Many scripts use uname to determine the SYSV3 type or the version of the OS to ensure software is compa- tible with that OS. Setting SYSV3 to an empty string will make uname print the following default values: nodename nodename 3.2 2 i386 The individual elements that uname displays can also be modified by setting SYSV3 in the following format: os,sysname,node,rel,ver,mach os Operating system (IUS or SCO). sysname System name. node Nodename as displayed by the -n option. rel Release level as displayed by the -r option. ver Version number as displayed by the -v option. mach Machine name as displayed by -m option. Do not put spaces between the elements. If an element is omitted, the current system value will be used. ----------------------------------------------------------------------------- --Boundary_(ID_Q/WCqE0gtGpQ2cf3ZMOlLg)-- From dcragun@sonic.net Thu Jul 8 09:04:14 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o68G4DKR008371 for ; Thu, 8 Jul 2010 09:04:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o68G4Bk3028410 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Jul 2010 11:04:13 -0500 (CDT) 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 <0L580000HXZ0R100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Jul 2010 09:04:12 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5800JCJXYZLC40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Jul 2010 09:04:11 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o68G4Ape013477 for ; Thu, 08 Jul 2010 16:04:11 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay42i.sun.com with ESMTP id BT-MMP-13006 for PSARC-ext@Sun.COM; Thu, 08 Jul 2010 16:02:10 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-14460639 for PSARC-ext@Sun.COM; Thu, 08 Jul 2010 16:02:10 +0000 (Z) Received: from a.mail.sonic.net ([64.142.16.245] [64.142.16.245]) by relay4i.sun.com with ESMTP id BT-MMP-352704 for PSARC-ext@Sun.COM; Thu, 08 Jul 2010 16:02:09 +0000 (Z) Received: from [10.0.0.5] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id o68G27tU029803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Jul 2010 09:02:07 -0700 Date: Thu, 08 Jul 2010 09:02:06 -0700 From: Don Cragun Subject: Re: EOF SYSV3 SCO compatibility environment variable [PSARC 2010/233 FastTrack timeout, 06/30/2010] In-reply-to: <4C35D878.6060800@oracle.com> To: Rich Burridge Cc: Alan Burlison , PSARC-ext@sun.com Message-id: <5CD4554C-7B6F-4986-B4DD-4331A02F7B17@sonic.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.216sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C2B861B.5020605@oracle.com> <93FC8D54-B9BD-4133-AA14-F78360BBD6B8@sonic.net> <4C2CA0D9.6000102@oracle.com> <9578D5F4-6B52-44FA-B7F0-E9607DF04D1A@sonic.net> <4C2CB527.8090305@oracle.com> <4523E8C9-B76D-4C16-B431-2932A45A3AF8@sonic.net> <4C2CDE43.30605@oracle.com> <4C2F074C.8020803@oracle.com> <6DAC59D6-8618-4EF3-9CB4-0D5919A7B9EC@sonic.net> <4C32F24E.8070402@oracle.com> <3EEC2730-1E8A-4489-B250-75692F7E7338@sonic.net> <4C358F35.9000808@oracle.com> <0BB72BC3-1266-4470-8BC4-67D75FF7CF1F@sonic.net> <4C35D878.6060800@oracle.com> Status: RO Content-Length: 436 On Jul 8, 2010, at 6:54 AM, Rich Burridge wrote: > On 07/08/10 06:16, Don Cragun wrote: >> ... >> OK. If this change can be added to the changes Rich has already promised >> to make today to man-page-changes.txt, I believe that all of my issues >> have been resolved. >> > > Done (and attached). > > If there are any other tweaks, you think should be made, > please let us know. Hi Rich, Looks good. Thanks, Don > > Thanks.