NOTICE: This is an unapproved draft, it is a work in progress, subject to change. Updated Jan 31 2003, added in ERNs 2 and 3 Updated 7 Feb 2003, updated after telcon Updated 19 Feb 2003, add new inbound rdvk Updated 14 Mar 2003,add new rdvk Updated 31 Mar 2003, new rdvk added Update 11 Apr 2003, after telcon Update 23 Apr 2003, new rdvk added Updated 21 May 2003, add new rdvk Updated 3 June, add new rdvk Updated 10 June, add new rdvk Updated 20 June, update after meeting and add new rdvk Updated 22 June, update after feedback to minutes and add missing rdvk Updated 14 July, update after meeting and add new rdvk Updated 18 July, update after meeting and add new rdvk Updated 28 July, after meeting. Updated 31 July, add new rdvk Updated 6 August, add new rdvk Updated 8 August, after meeting. Updated 15 August, add final inbound rdvk for TC2 Updated 29 August, after telco Updated 3 Sep, after telco Updated 12 Sep, after telco Updated 19 Sep, after telco _____________________________________________________________________________ COMMENT Enhancement Request Number 1 gwc@opengroup.org Defect in XCU locale (rdvk# 1) [gwc locale -k lists] Mon, 25 Nov 2002 15:26:17 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We disagreed with the conclusion given in PASC interpretation 1003.2-1992 #146, and believe that the standard is clear . However since existing practise is divided we would recommend that the following be considered change the second sentence on 21167 from "If a value is non-numeric, it shall be written in the following format:" to "If a value is non-numeric and is not a compound keyword value, it shall be written in the following format: " Then add an additional para: "If a value is a non-numeric compound keyword value, it shall either be written in the format: "%s=\"%s\"\n", , where the is a single string of values separated by semi-colons, or it shall be written in the format "%s=%s\n", , where the keyword value is encoded as a set of strings, each enclosed in double-quotation marks, separated by semi-colons." (interps track, standard is clear but concerns fwd) _____________________________________________________________________________ Page: 552 Line: 21180 Section: locale Problem: Defect code : 3. Clarification required PASC interpretation #146 for P1003.2-1992 identified an ambiguity in the description of the locale utility. No change was made in XCU6 related to this, so I assume the intention was to continue to allow either of the possible behaviours. It would be better if this is stated explicitly. Action: After "Compound keyword values (list entries) shall be separated in the output by semicolons." insert "For non-numeric values it is unspecified whether the output contains quoted strings separated by semicolons, or semicolon-separated values within one quoted string." _____________________________________________________________________________ objection Enhancement Request Number 2 bmark@us.ibm.com Defect in XCU expr (rdvk# 2) {IBM-011502} Wed, 15 Jan 2003 17:35:39 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (this intent is correct but not necessary matches historic practise) The CONSEQUENCE OF ERRORS section in 1.11 states that utilities may terminate prematurely if they encounter an invalid argument, therefore a conforming implementation of the expr utility need not write the result to STDOUT. (interps track) _____________________________________________________________________________ Page: 427 Line: 16543 Section: expr Problem: Defect code : 1. Error For expr _invalid_expression_, the standard appears to require that a newline is required to be output, even though there is no result. This is not historical practice. Action: Change lines 16543 to read: "The expr utility shall evaluate the expression and upon success write the result, followed by a ,...." _____________________________________________________________________________ objection Enhancement Request Number 3 bmark@us.ibm.com Defect in XCU find -prune (rdvk# 3) {IBM-011501} Wed, 15 Jan 2003 17:29:41 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Withdrawn by submitter _____________________________________________________________________________ Page: 450 Line: 17344 Section: find Problem: Defect code : 3. Clarification required When using -prune, is the special filename "." to be treated as a directory or as a 'special filename' as per XBD Sec 4.11? On all the UNIX implementations I have tried (and Linux as well), I get $ find /tmp -name '*' -prune /tmp But, if you run this, you get the contents of /tmp: $ cd /tmp $ find . -name '*' -prune ./foo ./bar ./(and so on) Where I would have expected: $ find . -name '*' -prune . Which is the correct behavior? Action: Clarify the action of the . and .. filenames either in XBD 4.11 or in the -prune section of find. _____________________________________________________________________________ COMMENT Enhancement Request Number 4 gwc@opengroup.org Defect in XCU find (rdvk# 4) [gwc find atime rationale] Tue, 11 Feb 2003 17:29:26 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 455 Line: 17573,17576 Section: find Problem: Defect code : 1. Error The rationale for -atime/-mtime/-ctime needs updating to match changes made in the normative text since POSIX.2-1992. Action: Change: "of n ``days'' to ``24-hour periods''" to: "of n ``days'' to n being the result of the integer division of the time difference in seconds by 86400". Change: "For example, -atime 3 is true" to: "For example, -atime 2 is true" _____________________________________________________________________________ COMMENT Enhancement Request Number 5 john.beck@sun.com Defect in XCU rm (rdvk# 5) {JTB-1} Tue, 11 Mar 2003 18:14:31 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: 1. We treat the original change request as an interpretation request (IR); not as a change to go into TC2 of the current standard. 2. We respond to the IR saying: A. the standard is clear (and therefore you can't do this and still conform), B. this issue will be forwarded to the sponsor for consideration in the next revision (code words for the standard is wrong), and C. have the sponsor indicate a future direction specifying that the next revision of the standard should change XCU6, P820, L31681-31683 from: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component), rm shall write a diagnostic message to standard error and do nothing more with such operands." to something like: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands." The standard is clear/standard is wrong wording should allow implementations to make this change if and when they choose to do so sometime in the next five or so years. No change would be required until we start making changes to implement SUSv4, IEEE Std 1003.1-20xx (xx >= 05), and ISO/IEC 9945-[1234]:20xx (xx >= 05). I would like to have this interpretation apply to XCU3, XCU4, XCU4v2, XCU5, and POSIX.2-1992 as well but I'm not sure how to make that happen at this point. _____________________________________________________________________________ Page: 820 Line: 31681-31683 Section: rm Problem: Defect code : 3. Clarification required An occasional user mistake, with devastating consequences, is to write a shell script with a line such as: rm -rf $VARIABLE1/$VARIABLE2 or rm -rf /$VARIABLE1 without verifying that either variable is set, which can lead to rm -rf / being the resulting command. Since there is no plausible circumstance under which this is the desired behavior, it seems reasonable to disallow this. Such a safeguard would, however, violate the current specification. Action: Either extend the exceptions for . and .. on the noted lines to list / as well, or specify that the behavior of rm if an operand resolves to / is undefined. _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 bmark@us.ibm.com Defect in XCU pax (rdvk# 6) {IBM-03190302} Wed, 19 Mar 2003 17:49:10 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: No requirement to do this , but an allowance of either implementation _____________________________________________________________________________ Page: 700 Line: 26980 Section: pax Problem: Defect code : 3. Clarification required The specification for the pax command (the -l option) implies that under certain circumstances that a hard link to a symbolic link be created. There's not actually any mechanism to create a hard link to a symlink is there? link() is required to resolve the path arguments, so it can't be used.... Action: remove the requirement for a "hard link to the symbolic link". or add the mechanism to be used for such a link "as if foo() were called". _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 joannaf@sun.com Defect in XCU pax (rdvk# 7) {sunw-jf03-ce1} Fri, 28 Mar 2003 11:12:41 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 705 Line: 27230 Section: pax Problem: Defect code : 2. Omission The two options (-H and -L) added to pax do not have a paragraph as seen in other cmds (e.g., chown, chgrp, ...) that says specifying more than one of the mutually-exclusive options shall not be considered an error and that the last option specified shall determine the behavior of the utility. This should be added. Action: In XCU6 on page 705 at line 27230 add the following paragraph: "Specifying more than one of the mutually-exclusive options -H and -L shall not be considered an error and that the last option specified shall determine the behavior of the utility." _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 bmark@us.ibm.com Defect in XCU pax (rdvk# 8) {IBM-03190301} Wed, 19 Mar 2003 16:54:33 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject____ Rationale for rejected or partial changes: TC There is no way to set ctime,so remove the ctime keyword _____________________________________________________________________________ Page: 712 Line: 27484 Section: pax Problem: Defect code : 1. Error There is a contradiction in the definition of the ctime keyword for pax's extended header: Definition of ctime extended header keyword: The file creation for the following file(s), equivalent to the value of the st_ctime member of the stat structure for a file, as described by the stat() function. The creation time shall be restored if the process has the appropriate privilege to do so. The trouble is that the st_ctime member of the stat structure does not refer to a file creation time. No field in the standard stat structure from includes a file creation time. Given the definition of st_ctime in as the time of the last status change and the lack of a direct mechanism to set the st_ctime field via the utime() interface, it seems like an error in the pax definition to allow a ctime keyword. In any case, there is at least an error in the description of the ctime keyword, since st_ctime does not indicate a file creation time. Action: Best Answer: remove the ctime keyword. Second best: redefine to "file status" time and give a hint on how to set it. _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 joannaf@sun.com Defect in XCU pax (rdvk# 9) {jf-kd-pax-140403-1} Mon, 14 Apr 2003 19:39:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Make the change below, the rationale for the change is as follows: "The text currently written in the standard allows the pax utility to truncate pathnames of files being extracted from an archive or copied from one place to another in arbitrary ways, even if this action overwrites existing files. We agree that translation may cause this to occur, but the pax utility should should not truncate file names on its own. It should be capable of restoring files even if the pathname in the archive is longer than {PATH_MAX}. (This may require the pax utility to perform one or more change directory operations to get to a point where the file being extracted can created using a pathname shorter than {PATH_MAX}.) If the underlying file system performs filename truncation (which is not allowed on file systems conforming to this standard), the pax utility need not attempt to prevent or detect the action. But, the pax utility itself should never truncate a pathname component." _____________________________________________________________________________ Page: 703 Line: 27097-27100 Section: pax Problem: Edition of Specification (Year): 2001 Defect code : 1. Error (1) lines 27097-27100: 27107 write In read or copy mode, pax shall write the file, translating or 27108 truncating the name, regardless of whether this may overwrite 27109 an existing file with a valid name. In list mode, pax shall behave 27110 identically to the bypass action. There is an error here as there is no meaningful interpretation which can be given to "truncating" the filename. The specification should specify the file should be extracted in place and this reference to truncating be removed. This could be implemented in pax by extracting as much of the path as will fit being created normally, up to some some subdirectory level. Then, the equivalent of a chdir should be performed to that directory, and as much of the path as will fit will be created from that point, repeatedly, until finally all of the path fits. Then the file should be created normally. Action: Change lines 27107 - 27110 from: "In read or copy mode, pax shall write the file, translating or truncating the name, regardless of whether this may overwrite an existing file with a valid name. In list mode, pax shall behave identically to the bypass action." to "In read or copy mode, pax shall write the file, translating the name, regardless of whether this may overwrite an existing file with a valid name. In list mode, pax shall behave identically to the bypass action." _____________________________________________________________________________ OBJECTION Enhancement Request Number 10 joannaf@sun.com Defect in XCU pax (rdvk# 10) {jf-kd-pax-140403-2} Mon, 14 Apr 2003 19:53:10 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: c_nlink Contains a number greater than or equal to the number of links in the archive referencing the file. If the -a option is used to append to a cpio archive, then the pax utility need not account for the files in the existing part of the archive when calculating the c_nlink values for the appended part of the archive, and need not alter the c_nlink values in the existing part of the archive if additional files with the same c_dev and c_ino values are appended to the archive. Add to APPLICATION USAGE Caution is advised when using the -a option to append to a cpio format archive. If any of the files being appended happen to be given the same c_dev and c_ino values as a file in the existing part of the archive, then they may be treated as links to that file on extraction. Thus it is risky to use -a with cpio format except when it is done on the same system that the original archive was created on, and with the same pax utility, and in the knowledge that there has been little or no file system activity since the original archive was created that could lead to any of the files being appended being given the same c_dev and c_ino values as an unrelated file in the existing part of the archive. Also, when (intentionally) appending additional links to a file in the existing part of the archive, the c_nlink values in the modified archive can be smaller than the number of links to the file in the archive, which may mean that the links are not preserved on extraction. _____________________________________________________________________________ Page: 720 Line: 27811-27812 Section: pax Problem: Edition of Specification (Year): 2001 Defect code : 1. Error lines 27811-27812: 27811 c_nlink Contains the number of links referencing the file at the time the archive was 27812 created. The language is ambiguous, and leads to a common mis-intrepretation, that the link count saved in this field is that which pertained on the file system when this file was archived. This is not a meaningful number. This can lead to subtle and nasty data corruption bugs. The proper meaning of this field is "the number of links in this archive referencing the file at the time the archive was created". Action: Change lines 27811-27812 from: "c_nlink Contains the number of links referencing the file at the time the archive was created." to "c_nlink Contains the number of links in this archive referencing the file at the time the archive was created" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 11 don.cragun@sun.com Defect in XCU sed (rdvk# 11) {dwc-sed-1} Tue, 15 Apr 2003 15:26:35 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 846 Line: 32771 Section: sed Problem: Edition of Specification (Year): 2003 Defect code : 1. Error In the sentence: "If the delimiter is not n, within string1 and string2, the delimiter itself can be used as a literal character if it is preceded by a backslash." having the n in italics means that n is a parameter of the y command. But the only parameters to the y command are string1 and string2. The n here is a literal n character as used in two other places (L32766 and L32775) in this paragraph and should be shown as the three character sequence 'n' all in constant-width font. Action: Change "n" on P846, L32771 to "'n'". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 12 don.cragun@sun.com Defect in XCU tr (rdvk# 12) {dwc-tr:1} Wed, 7 May 2003 23:03:20 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 930 Line: 35992 Section: tr Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Example 3 on P930, L35990-35992 depends on the BSD behavior described in the application usage section on P929, L35969-35973. Text continuing on P929, L35973-35977 and normative text on P928, L35928-35930 state that this produces unspecified results. The examples should not depend on unspecified results. Action: Change P930, L35992 from: tr "[=e=]" e file2 to: tr "[=e=]" "[e*]" file2 _____________________________________________________________________________ OBJECTION Enhancement Request Number 13 joannaf@sun.com Defect in XCU localedef (rdvk# 13) {jf-kt-sun-210503-1} Wed, 21 May 2003 16:19:48 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 560 Line: 21593-21594 Section: localedef Problem: Edition of Specification (Year): 2003 Defect code : 1. Error There is a conflict with the width information in locale and with the localedef utility. In XBD6, at lines 3873-3885, pages 121-122, 'WIDTH' and 'WIDTH_DEFAULT' for the charmap file to be specified to the localedef utility are defined as follows: WIDTH An unsigned positive integer value defining the column width for the printable characters in the coded character set specified in Table 6-1 and Table 6-2. Coded character set character values shall be defined using symbolic character names followed by column width values. Defining a character with more than one WIDTH produces undefined results. The END WIDTH keyword shall be used to terminate the WIDTH definitions. Specifying the width of a non-printable character in a WIDTH declaration produces undefined results. WIDTH_DEFAULT An unsigned positive integer value defining the default column width for any printable character not listed by one of the WIDTH keywords. If no WIDTH_DEFAULT keyword is included in the charmap, the default character width shall be 1. So, for WIDTH and WIDTH_DEFAULT, the spec. says an unsigned positive integer value can be specified. This shows a conflict with localedef utility. In XCU6, at lines 21593-21594, page 560, it says as follows: If a non-printable character in the charmap has a width specified that is not -1, localedef shall generate a warning. This sounds like the localedef utility should accept -1 as the width value for a non-printable character in the charmap file. But, XBD6 says an unsigned positive integer value should be specified in the charmap file and the result will be undefined if the width of a non-printable character is defined with the WIDTH keyword in charmap file. Action: We think the XCU6 description should be modified. That is the result will be undefined when the width of a non-printable character is defined in charmap file. localedef does not need to generate warning. Change lines 21593-21594, page 560 to: If a non-printable character in the charmap has a width specified that is not -1 the result will be undefined. Remove line 21611 on page 561. _____________________________________________________________________________ OBJECTION Enhancement Request Number 14 gwc@opengroup.org Defect in XCU test (rdvk# 14) [gwc test primaries] Thu, 29 May 2003 18:04:17 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Replace lines 34872 to 34894 inclusive with the following: -b pathname True if pathname resolves to a file that exists and is a block special file. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a block special file. -c pathname True if pathname resolves to a file that exists and is a character special file. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a character special file. -d pathname True if pathname resolves to a file that exists and is a directory. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a directory. -e pathname True if pathname resolves to a file that exists. False if pathname cannot be resolved. -f pathname True if pathname resolves to a file that exists and is a regular file. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a regular file. -g pathname True if pathname resolves to a file that exists and has its set-group-ID flag set. False if pathname cannot be resolved, or if pathname resolves to a file that exists but does not have its set-group-ID flag set. -h pathname True if pathname resolves to a file that exists and is a symbolic link. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a symbolic link. If the final componenent of pathname is a symlink that symlink is not followed. -L pathname True if pathname resolves to a file that exists and is a symbolic link. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a symbolic link. If the final componenent of pathname is a symlink that symlink is not followed. -n string True if the length of string is non-zero, otherwise false. -p pathname True if pathname resolves to a file that exists and is a FIFO. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a FIFO. -r pathname True if pathname resolves to a file that exists and for which permission to read from the file will be granted, as defined in Section 1.7.1.4 (on page 4). False if pathname cannot be resolved, or if pathname resolves to a file for which permission to read from the file will not be granted. -S pathname True if pathname resolves to a file that exists and is a socket. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a socket. -s pathname True if pathname resolves to a file that exists and has a size greater than zero. False if pathname cannot be resolved, or if pathname resolves to a file that exists but does not have a size greater than zero. -t file_descriptor True if file descriptor number file_descriptor is open and is associated with a terminal. False if file_descriptor is not a valid file descriptor number, or if file descriptor number file_descriptor is not open, or if it is open but is not associated with a terminal. -u pathname True if pathname resolves to a file that exists and has its set-user-ID flag set. False if pathname cannot be resolved, or if pathname resolves to a file that exists but does not have its set-user-ID flag set. -w pathname True if pathname resolves to a file that exists and for which permission to write to the file will be granted, as defined in Section 1.7.1.4 (on page 4). False if pathname cannot be resolved, or if pathname resolves to a file for which permission to write to the file will not be granted. -x pathname True if pathname resolves to a file that exists and for which permission to execute the file (or search it, if it is a directory) will be granted, as defined in Section 1.7.1.4 (on page 4). False if pathname cannot be resolved, or if pathname resolves to a file for which permission to execute (or search) the file will not be granted. On lines 34894 to 34904 inclusive append "otherwise false". On line 34906 change "are true" to "are true, otherwise false". On line 34909 change "is true" to "is true, otherwise false". On line 34912 change "resolving the symbolic link" to "following the symbolic link". On line 34915 append "False if expression is true." On line 34916 after "is true." insert "False if expression is false." _____________________________________________________________________________ Page: 904-905 Line: 34872-34916 Section: test Problem: Defect code : 1. Error The descriptions of the file existence primaries for the test utility are poorly worded and do not accurately convey the intended behaviour. In addition, many of the descriptions of primaries only indicate that they evaluate to true when some condition is met. The requirement that they should evaluate to false when the condition is not met has to be inferred. It should be stated explicitly. Action: Replace lines 34872 to 34894 inclusive with the following: -b pathname True if pathname resolves to a file that exists and is a block special file. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a block special file. -c pathname True if pathname resolves to a file that exists and is a character special file. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a character special file. -d pathname True if pathname resolves to a file that exists and is a directory. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a directory. -e pathname True if pathname resolves to a file that exists. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved. -f pathname True if pathname resolves to a file that exists and is a regular file. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a regular file. -g pathname True if pathname resolves to a file that exists and has its set-group-ID flag set. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but does not have its set-group-ID flag set. -h pathname True if pathname resolves to a file that exists and is a symbolic link. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a symbolic link. -L pathname True if pathname resolves to a file that exists and is a symbolic link. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a symbolic link. -n string True if the length of string is non-zero, otherwise false. -p pathname True if pathname resolves to a file that exists and is a FIFO. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a FIFO. -r pathname True if pathname resolves to a file that exists and for which permission to read from the file will be granted, as defined in Section 1.7.1.4 (on page 4). False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file for which permission to read from the file will not be granted. -S pathname True if pathname resolves to a file that exists and is a socket. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a socket. -s pathname True if pathname resolves to a file that exists and has a size greater than zero. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but does not have a size greater than zero. -t file_descriptor True if file descriptor number file_descriptor is open and is associated with a terminal. False if file_descriptor is not a valid file descriptor number, or if file descriptor number file_descriptor is not open, or if it is open but is not associated with a terminal. -u pathname True if pathname resolves to a file that exists and has its set-user-ID flag set. False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file that exists but does not have its set-user-ID flag set. -w pathname True if pathname resolves to a file that exists and for which permission to write to the file will be granted, as defined in Section 1.7.1.4 (on page 4). False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file for which permission to write to the file will not be granted. -x pathname True if pathname resolves to a file that exists and for which permission to execute the file (or search it, if it is a directory) will be granted, as defined in Section 1.7.1.4 (on page 4). False if pathname resolves to a file that does not exist, or if pathname cannot be resolved, or if pathname resolves to a file for which permission to execute (or search) the file will not be granted. On lines 34894 to 34904 inclusive append "otherwise false". On line 34906 change "are true" to "are true, otherwise false". On line 34909 change "is true" to "is true, otherwise false". On line 34912 change "resolving the symbolic link" to "following the symbolic link". On line 34915 append "False if expression is true." On line 34916 after "is true." insert "False if expression is false." _____________________________________________________________________________ COMMENT Enhancement Request Number 15 bmark@us.ibm.com Defect in XCU test (rdvk# 15) {IBM-05250301} Tue, 27 May 2003 20:06:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_14 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 910 Line: 35229 Section: test Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The exit status for the test utility is three-pronged The following exit values shall be returned: 0 expression evaluated to true. 1 expression evaluated to false or expression was missing. >1 An error occurred. In the case of test -f non-existent-file it is easy to see that the error is "1" . But in the case of test -f path-longer-than-PATHMAX/foo is the error "1" or ">1"? "1" says that the expression is "false or missing", which may or may not be true since the path is too long for me to resolve. ">1" says "An error occurred", which is certainly true - but the file may actually exist. Whether or not the file exists *should* not matter, as the expression was not "evaluated to false" and the expression was present. However, the present test requires a "1" result, stating: "The point is that the vast majority of existing applications just do a plain "if test -f path" or "if test ! -f path" and in places where the second form is used, test will give the "wrong" answer if it exits with status >1 for pathname resolution errors." Action: Action: Clarify this please. In favor of ">1", by saying "The standard says what it says" or in favor of "1" by re-writing the terms of "1" to somehow include places where the expression would have evaluated successfully if it had not exceeded system limits somehow. I do not know how to write this term, myself. _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 joannaf@sun.com Defect in XCU uudecode (rdvk# 16) {jf-ac-sun-230503-1} Fri, 23 May 2003 15:33:26 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: the end of line 37351: If either of the op characters '+' and '-' are specified in symbolic mode, the initial mode on which those operations are based is unspecified _____________________________________________________________________________ Page: 969 Line: 37347-37351 Section: uudecode Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The standard is unclear and an interpretation is required. The description of the uuencode utility on page 972 lines 37440-37443 says: The output shall be encoded using one of the algorithms described in the STDOUT section and shall include the file access permission bits (in chmod octal or symbolic notation) of the input file and the decode_pathname, for re-creation of the file on another system that conforms to this volume of IEEE Std 1003.1-2001. in particular the phrase "shall include the file access permission bits (in chmod octal or symbolic notation)" indicate how access permissions shall be represented in the encoded file. The description of the uudecode utility on page 969 lines 37347-37351 says: The file access permission bits and contents for the file to be produced shall be contained in that data. The mode bits of the created file (other than standard output) shall be set from the file access permission bits contained in the data; that is, other attributes of the mode, including the file mode creation mask (see umask), shall not affect the file being produced. What this description does not indicate is that when the symbolic notation + and - are used what is the base mode upon which they are applied. This means the standard is unclear and an interpretation is required to record this. Looking at mkdir on page 638, lines 24713-24717 or mkfifo page 641, lines 24813-24816 there is text upon which a clarification to the description could be created but the actual initial mode for uudecode is open to question. Arguments for 777, 666, and 000 could be made with possible others as well. Action: 1) Issue a interpretation stating the standard is unclear. 2) Optionally investigate with the interpretations committee as future direction the possibility of adding text of the following form at the end of line 37351: The access permission in the data if in the form of symbolic_mode strings then the op characters '+' and '-' shall be interpreted relative to an assumed initial mode of a=???; '+' shall add permissions to the default mode, '-' shall delete permissions from the default mode. The question is if this type of text is appropriate what should the initial mode (indicated by ??? above) actually be for uudecode. Should it be a=rwx, a=rw or something else? _____________________________________________________________________________ EDITORIAL Enhancement Request Number 17 ajosey@opengroup.org Defect in XCU 2.9.1.1 (rdvk# 17) {shell.$0} Tue, 10 Jun 2003 15:47:36 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change From: "If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of IEEE Std 1003.1-2001, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, with any remaining arguments passed to the new shell." To: "If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of IEEE Std 1003.1-2001, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of $0 in the new shell may be set to the command name." _____________________________________________________________________________ Page: 48 Line: 1986 Section: 2.9.1.1 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error In trying out the shell tests on some implementations we are seeing the following failures 10|3 /tset/POSIX.shell/shell/sh_07.ex 16:38:29|TC Start, scenario ref 4-0, ICs: {1-800} 15|3 3.6 38|TCM Start 400|3 448 1 16:38:39|IC Start 200|3 34 16:38:39|TP Start 520|3 34 5289 1 1|Assertion #448 (A): When the search for command name using the PATH environment variable 520|3 34 5289 2 1|Standard output isn't the same as file 'test.448.exp' 520|3 34 5289 2 2|diff of "out.stdout" and "test.448.exp": 520|3 34 5289 2 3|*** out.stdout Thu Jun 5 16:38:39 2003 520|3 34 5289 2 4|--- test.448.exp Thu Jun 5 16:38:39 2003 520|3 34 5289 2 5|*************** 520|3 34 5289 2 6|*** 1 **** 520|3 34 5289 2 7|! /home/XXX/vsc-lite/vsc/tet_tmp_dir/02033aa/tset/POSIX.shell/shell/test.448.sh2 value 520|3 34 5289 2 8|--- 1 ---- 520|3 34 5289 2 9|! test.448.sh2 value 220|3 34 1 16:38:39|FAIL 410|3 448 1 16:38:39|IC End 400|3 449 1 16:38:39|IC Start 200|3 35 16:38:39|TP Start 520|3 35 5289 1 1|Assertion #449 (A): When the search for command name using the PATH environment variable 520|3 35 5289 2 1|Standard output isn't the same as file 'test.449.exp' 520|3 35 5289 2 2|diff of "out.stdout" and "test.449.exp": 520|3 35 5289 2 3|*** out.stdout Thu Jun 5 16:38:39 2003 520|3 35 5289 2 4|--- test.449.exp Thu Jun 5 16:38:39 2003 520|3 35 5289 2 5|*************** 520|3 35 5289 2 6|*** 1 **** 520|3 35 5289 2 7|! /home/XXX/vsc-lite/vsc/tet_tmp_dir/02033aa/tset/POSIX.shell/shell/test.449.sh2 value 520|3 35 5289 2 8|--- 1 ---- 520|3 35 5289 2 9|! test.449.sh2 value 220|3 35 1 16:38:39|FAIL 410|3 449 1 16:38:39|IC End 400|3 450 1 16:38:39|IC Start eg $0 contains the full pathname, rather than just the command name as the test expects. We think this might be a bug in the spec. The spec says in XCU 2.9.1.1 p48 line 1986 "If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of IEEE Std 1003.1-2001, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, with any remaining arguments passed to the new shell." If the pathname resulting from the search does not correspond to a file in the current directory, then passing the command name does not make any sense - the shell either would execute the wrong file (if a file of the same name exists in the current directory) or might not find the file at all (because the sh utility is not required to search PATH in this case, although it is allowed to). We think it should say "with the pathname resulting from the search as its first operand", in which case I would expect to see $0 set to the pathname (which is not what the test expects). Action: Change From: "If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of IEEE Std 1003.1-2001, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, with any remaining arguments passed to the new shell." To: "If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of IEEE Std 1003.1-2001, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 18 ajosey@opengroup.org Defect in XCU localedef (rdvk# 18) {andries.brouwer.email} Tue, 10 Jun 2003 14:29:05 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 559 Line: 21535 Section: localedef Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required --------------------------------------------------------------------- name Identifies the locale; see the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 7, Locale for a description of the use of this name. If the name contains one or more slash characters, name shall be interpreted as a pathname where the created locale definitions shall be stored. If name does not contain any slash characters, the interpretation of the name is implementation-defined and the locale shall be public. This capability may be restricted to users with appropriate privileges. --------------------------------------------------------------------- But "This capability" does not refer to anything. Suggested replacement: "The ability to create public locales in this way may be restricted ..." Action: Change from: "This capability may be restricted to users with appropriate privileges." To: "The ability to create public locales in this way may be restricted to users with appropriate privileges." _____________________________________________________________________________ OBJECTION Enhancement Request Number 19 gwc@opengroup.org Defect in XCU c99 (rdvk# 19) [gwc c99 width restricted envs] Mon, 16 Jun 2003 11:20:24 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 215 Line: 8385-8386 Section: c99 Problem: Defect code : 1. Error There has been a lot of confusion over the years about whether some arguments to getconf have an underscore on the front. This has now (I hope) been sorted out in the getconf changes in TC1. However, there are still some references to getconf where this problem persists. One such is the c99 page, in relation to POSIX_V6_WIDTH_RESTRICTED_ENVS. Firstly, the getconf argument should be POSIX_V6_WIDTH_RESTRICTED_ENVS (with no leading underscore) because it is derived from _CS_POSIX_V6_WIDTH_RESTRICTED_ENVS with the _CS_ removed. Secondly, it is not clear whether the programming environment names output by getconf (and confstr()) should have a leading underscore. The description of _CS_POSIX_V6_WIDTH_RESTRICTED_ENVS on the page just says "This value is a -separated list of names of programming environments". However, there are places where programming environment names occur with and without a leading underscore. E.g. the tables on the c99 pages have an underscore, but when a programming environment is specified to getconf via the -v option, it does not have a leading underscore. The intention for the output of getconf POSIX_V6_WIDTH_RESTRICTED_ENVS was that the names could be used with getconf -v, and each name could be used with "_CFLAGS" etc. appended to obtain the compiler/linker flags and libraries for that programming environment (as in example 4 on the c99 page). The latter will also work if the names are suitable for use with getconf -v (i.e. do not have a leading underscore). Action: On page 215 lines 8385-8386 change: "shall be output by a getconf command using the _POSIX_V6_WIDTH_RESTRICTED_ENVS argument." to: "shall be output by a getconf command using the POSIX_V6_WIDTH_RESTRICTED_ENVS argument, as a -separated list of names suitable for use with the getconf -v option." (Note the removed leading underscore on POSIX_V6_WIDTH_RESTRICTED_ENVS.) On page 218 lines 8503 and 8507 remove the leading underscore from "_POSIX_V6_WIDTH_RESTRICTED_ENVS". In XBD6 on page 406 line 14353, add "The format of each name shall be suitable for use with the getconf -v option." _____________________________________________________________________________ COMMENT Enhancement Request Number 20 don.cragun@sun.com Defect in XCU tr (rdvk# 20) {dwc-tr.1} Tue, 17 Jun 2003 18:36:06 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 931 Line: 36041 Section: tr Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The rationale on P931, L36041 says: "IEEE Std 1003.1-2001 specifies that octal sequences always refer to single byte binary values." But, the normative text on P927, L35867-35874 says: "Octal sequences can be used to represent characters with specific coded values. ... Multibyte characters require multiple, concatenated escape sequences of this type, including the leading '\' for each byte." I believe that this rationale was only intended to apply to the case where octal sequences were used as the end points in a range of collating elements. Action: Change: "IEEE Std 1003.1-2001 specifies that octal sequences always refer to single byte binary values." on P931, L36041 to: "IEEE Std 1003.1-2001 specifies that octal sequences always refer to single byte binary values when used to specify an endpoint of a range of collating elements." _____________________________________________________________________________ OBJECTION Enhancement Request Number 21 bmark@us.ibm.com Defect in XCU pax -r -w (rdvk# 21) {IBM-03200301} Thu, 20 Mar 2003 15:37:16 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add "[-o options]..." after "[-H|-L]" conditionally to the SYNOPSIS for -r -w _____________________________________________________________________________ Page: 698 Line: 26876 Section: pax Problem: Defect code : 3. Clarification required The pax -r -w (copy) mode does not aloow for use of the -o option (see syntax). Yet, there are -o keywords (see -o invalid=_action_) that refer to use in "copy" mode. Which is correct? Action: Correct the -o items that erroneously refer to "copy" mode: P.701, Lines: 27020, 27048 P.702, Lines: 27069, 27084, 27088, 27092, P.703, Lines: 27097, 27119, 27127, 27133, OR correct the -r -w syntax to allow -o. _____________________________________________________________________________ OBJECTION Enhancement Request Number 22 cynthia.eastham@sun.com Defect in XCU pax (rdvk# 22) {ce-pax-1} Thu, 26 Jun 2003 22:06:37 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 701 Line: 27019-27029 Section: pax Problem: Edition of Specification (Year): 2001 Defect code : 3. Clarification required The standard is unclear and interpretation is required. The description of the -odelete=pattern option of the pax utility on page 701, lines 27020-27029, does not mention how multiple -odelete=pattern options are to be handled. Page 701, lines 27014-27017,says: Multiple -o options can be specified; if keywords given to these multiple -o options conflict, the keywords and values appearing later in command line sequence shall take precedence and the earlier shall be silently ignored. It is unclear whether multiple -odelete=pattern specified on the command line would only omit the last pattern specified in the command line sequence from extended header records, or if the patterns specified with the delete option would be additive (all patterns specified with -odelete=pattern would be omitted from extended header records). Action: Add text (similar to page 703, lines 27115-27117) of the following form at the end of line 27029: When multiple -odelete=pattern options are specified, the patterns shall be additive; all keywords matching the specified string patterns shall be omitted from extended header records that pax produces. _____________________________________________________________________________ COMMENT Enhancement Request Number 23 gwc@opengroup.org Defect in XCU pax (rdvk# 23) [gwc pax ustar links] Fri, 4 Jul 2003 12:29:53 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: On page 717 line 27700 change: "Such files are identified by each file having the same device and file serial number." to: "Such files are identified by having the same device and file serial numbers, and pathnames that refer to different directory entries. All such files shall be archived as linked files." Add the following at line 27722: "It is unspecified whether files with pathnames that refer to the same directory entry are archived as linked files or as separate files. If they are archived as linked files this means that attempting to extract both pathnames from the resulting archive will always cause an error (unless the -u option is used) because the link cannot be created." Also add It is unspecified whether files with the same device and file serial numbers being appended to an archive are treated as linked files to members that were in the archive before the append. p720 in 2003 before line 27961 _____________________________________________________________________________ Page: 721 Line: 27886 Section: pax Problem: Defect code : 3. Clarification required The description of ustar format on the pax page states, for typeflag 1: "Represents a file linked to another file, of any type, previously archived. Such files are identified by each file having the same device and file serial number." It may not be obvious to users that this does not only apply to files that are hard-linked, but also to files that are aliased via symlinks. Action: Add to the end of the "APPLICATION USAGE" section: "When a ustar or pax format archive is written, a typeflag of 1 is used for files that have the same device and file serial number as a file previously archived. This means that if a file is archived using two pathnames that resolve to the same file via symbolic links (either in the path prefix if the -L and -H options are not used, or anywhere in the pathname if the -L or -H option is used), then in the archive the second pathname will be represented as a link to the first pathname, and they will be extracted as linked files." _____________________________________________________________________________ OBJECTION Enhancement Request Number 24 gwc@opengroup.org Defect in XCU pax (rdvk# 24) [gwc pax linking symlinks] Thu, 17 Jul 2003 11:00:15 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 699 Line: 26930 Section: pax Problem: Defect code : 1. Error The description of pax states: "If the selected archive format supports the specification of linked files, it shall be an error if these files cannot be linked when the archive is extracted." If the files to be linked are symlinks, since there is no standard way of creating hard-linked symlinks, systems which do not have any means of hard-linking symlinks should create separate copies of the symlink instead of reporting an error. (This is similar to the issue that came up before about how symlinks are handled when -rwl is used. That issue was resolved by requiring copies of the symlinks to be created on systems that cannot hard-link symlinks.) Action: Change "it shall be an error if these files cannot be linked when the archive is extracted." to "it shall be an error if these files cannot be linked when the archive is extracted, except that if the files to be linked are symbolic links and the system is not capable of making hard links to symbolic links then separate copies of the symbolic link shall be created instead." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 25 mitr@volny.cz Defect in XCU Token Recognition (rdvk# 25) {rhl100970} Mon, 28 Jul 2003 21:06:38 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The standard clearly states these requirements,and conforming implementations must conform to this. The group feels there is no defect here. _____________________________________________________________________________ Page: 32 Line: 1304,1328-1330 Section: Token Problem: Edition of Specification (Year): 2001 Defect code : 1. Error Currently, XCU 2.3 specifies that shell command language in terms of s, which makes the interpretation of any shell script dependent on the LC_CTYPE category of current locale. Aside from the obvious result that a single shell script may or may not work in a different environment, this also puts unnecessary burden on implementors (effectively requiring a call on isblank () on each input character). There is at least one widely used shell implementation (bash) that in fact does not honor the LC_CTYPE category. In order for a script to be portable, it must rely only on and characters being interpreted as . Replacing "" by " or " promotes shell script portability and allows faster shell implementations. Action: On page 32, line 1304, replace "If the current character is an unquoted ", ... by "If the current character is an unquoted or ", ... On page 32, line 1328, replace "If the value of the alias replacing the word ends in a ", ... by "If the value of the alias replacing the word ends in a or ", ... On page 32, line 1330, replace ... "that does not end in a ." by ... "that does not end in a or ." On page 35, line 1439-1440, remove "and s (character class blank). _____________________________________________________________________________ OBJECTION Enhancement Request Number 26 don.cragun@sun.com Defect in XCU file (rdvk# 26) {dwc-file.20030725} Sat, 26 Jul 2003 01:15:10 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 447-448 Line: 17323-17328,17352-17361 Section: file Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required When this revision of the standard added magic file syntax to the file utility, some actions related to processing floating point types seem to have been incorrectly or incompletely specified. The text on P447-448, L17323-17328 (in the extended description of the type field) says that all type specifiers except for s can be followed by a mask specifier and that the indicated mask value shall be AND'ed with the value in the input file. The C standard, however, constrains the meaning of bitwise operations to only apply to operands that have integer types. Therefore, I believe that the standard should, at a minimum, also exclude type f (as well as type s) from the masking operations. Similar issues arise on P448, L17352-17361 (in the extended description of the value field) where it describes the permissible characters and the comparisons they specify when the value field is not a string. The & and ^ tests make no sense in C with floating point types again because bitwise operators in C are constrained to work on integer type operands. Furthermore, the meaning of the comparisons to be performed corresponding to the =, <, and > characters in the value field for type float are not clearly specified for NaNs and Infinities. (For instance =NaN, NaN are all undefined in C even if a NaN in the file at the specified offset (NaNs are unordered). It could be interpreted as though =NaN was equivalent to using isnan(value_from_file), but that behavior is not specified by the current standard.) The description of non-string values in the value field only talk about signed decimal numbers in decimal, hexadecimal, and octal forms (see P448, L17348-17351), but not about the decimal points (or radix characters), Infinities, or NaNs that would be needed for floating point. It looks like type float was added to the standard for completeness when compared to the C Standard, but it doesn't look like the implications were well considered. Since I have never seen a case where floating point values were needed when creating a magic file, I suggest that floating point evaluations be removed from the spec. If they are not removed, the following must be clearly specified: 1. How are floating point values specified in the value field? 2. What are the & and ^ comparisons supposed to do with floating point values? 3. What is the meaning of =NaN? 4. Is there a meaning for NaN? 5. If =NaN is equivalent to isnan(value_from_file), is =Inf supposed to be equivalent to isinf(value_from_file) and is =+Inf different from =Inf? Note that none of the examples and nothing in the rationale mention floating point. Action: XCU P447, L17291-17292: Change: "d, f, s, and u, specifying character, signed decimal, floating point, string," to: "d, s, and u, specifying character, signed decimal, string," P447, L17297-17300: Change: "The type specification characters d, f, and u can be followed by an optional unsigned decimal integer that specifies the number of bytes represented by the type. The type specification character f can be followed by an optional F, D, or L, indicating that the value is of type float, double, or long double, respectively. ..." to: "The type specification characters d and u can be followed by an optional unsigned decimal integer that specifies the number of bytes represented by the type. ..." Delete P447, L17317-17322. _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 don.cragun@sun.com Defect in XCU file (rdvk# 27) {dwc-file.20030815b} Wed, 6 Aug 2003 00:22:12 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 447,448 Line: 17280,17336-17341 Section: file Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission XCU6 added magic files to the POSIX specifications, but the specification it provides is incompatible with existing implementation-provided magic files and with ways to specify strings containing characters. Most of the incompatibilities are pure extensions of what have been provided in existing implementations, but two problems seem to make in unneccessarily hard for implementors and for application writers that want to provide portable magic files as part of their application. These two problems are closely related. 1. UNIX System V based implementations of the file utility allow one or more characters to separate fields on each line in a magic file. Some other implementations (including GNU) seem to allow one or more white space characters (other than ) to separate fields. The standard (XCU6, P447, L17280) allows one or more characters that belong in the blank character class ( and in the C/POSIX Locale) to separate fields. 2. UNIX System V based implementations of the file utility allow non- characters (other than ) to be entered directly in strings in the value field. ( and and other white space characters can also be entered in the value field as backslash escape sequences.) Some other implementations (including GNU) require that all white space characters appearing in a string value field be entered as backslash escape sequences. The standard (XCU6, P448, L17336-17341) does not specify any way for a character to be entered in a string value field in a magic file, but requires other white space characters to be entered as backslash escape sequences. The changes provided in the Action section below will allow application writers to create portable magic files that can match characters in strings. It will also allow common extensions found in existing magic file implementations to continue to be recognized as operands to the -m and -M options although they would not always be portable to other POSIX conforming implementations. Action: Change: "four -separated fields:" on P447, L17280 to: "four -separated* fields: ---------- * Implementations may allow any combination of one or more white space characters other than to act as field separators." Add: "In addition, the escape sequence '\ ' (the character followed by the character) shall be recognized to represent a character. on P448, L17339 before the last sentence in the current paragraph. _____________________________________________________________________________ OBJECTION Enhancement Request Number 28 don.cragun@sun.com Defect in XCU file (rdvk# 28) {dwc-file.20030805a} Tue, 5 Aug 2003 23:08:58 +0100 (BST) _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 447 Line: 17291 Section: file Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission XCU6 added magic files to the POSIX specifications, but when it did so, it left the meaning of the type specification character 'c' unspecified. XCU6, P447, L17290-17292 says: "The type shall consist of the type specification characters c, d, f, s, and u, specifiying character, signed decimal, floating point, string, and unsigned decimal, respectively." Later paragraphs specify the number of bytes to be matched by all of these type, except c; specify the byte order to be used when matching all of these types, except c; and specifies that the strings byte, short, long, and string are to be interpreted as dC, dS, dL, and s, respectively, but again doesn't mention c. If the intention was to match a byte, that can already be specified by the type strings, "byte", "dC", "d1", "uC", or "u1" as appropriate. If the intention was to match a (possibly multibyte) character, that can already be specified with a type string "s" or "string" and giving a value field that matches one character. (Note that the value field corresponding to a type c is specified to be a signed decimal value (not a string), but there is no indication as to how a multibyte character is supposed to be converted to a signed decimal value in a portable manner. Action: Change: "characters c, d, f, s, and u, specifying character, signed decimal," on P447, L17291 to: "characters d, f, s, and u, specifying signed decimal,". If this change is not acceptable, specify how type character c is supposed to be interpreted and how matching characters are supposed to be entered as decimal values in the value field. _____________________________________________________________________________ COMMENT Enhancement Request Number 29 ajosey@opengroup.org Defect in XCU 1.7.1.4 (rdvk# 29) {impldefined} Mon, 11 Aug 2003 15:32:11 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: implementation-defined is used in the equivalent text in 1003.2-1992. A change identified is to remove the dashes from the line marked with * and ** 140,141,150 _____________________________________________________________________________ Page: 5 Line: 170 Section: 1.7.1.4 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The dash entries in table 1-1 are stated to be implementation-defined. This will thus require the semantics to be enumerated in the Conformance Document. Its unclear what the benefit of this documentation is to applications. Action: Change from: "implementation-defined" To: "unspecified" _____________________________________________________________________________ OBJECTION Enhancement Request Number 30 don.cragun@sun.com Defect in XCU c99 (rdvk# 30) {dwc-c99.20030808} Sat, 9 Aug 2003 01:37:54 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 212 Line: 8324 Section: c99 Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The description of the -L option gives a list of libraries that may produce unspecified results if they appear in directories specified by the -L option. This list has not been maintained as new libraries have been added to the standard for threads, real-time, tracing, and networking. (A similar list on P215, L8436-8437 was updated in TC1, but this list was missed.) It also assumes that all libraries are named lib"libraryname".a. But, now that shared libraries are recognized by the standard (through interfaces like dlopen()), other library name suffixes should be reserved as well. (The standard already implies that this should happen on P213, L8350-8351 where it says "Implementations may recognize implementation-defined suffixes other than .a as denoting libraries." in the description of the -l option.) Action: Change: "If a directory specified by the -L option contains files named libc.a, libm.a, libl.a, or liby.a, the results are unspecified." on P212, L8323-8324 to: "If a directory specified by the -L option contains files with names starting with any of the strings "libc.", "libl.", "libpthread.", "libm.", "librt.", "libtrace.", "libxnet.", or "liby.", the results are unspecified." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 31 ajosey@opengroup.org Defect in XCU ex (rdvk# 31) {typo} Tue, 12 Aug 2003 12:32:40 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 370 Line: 14333 Section: ex Problem: Edition of Specification (Year): 2003 Defect code : 1. Error the text says "lhs or rh" , the rh is a typo and should be rhs Action: Change from "rh" to "rhs" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 32 schilling@fokus.fraunhofer.de Defect in XCU pax (rdvk# 32) {unknown} Mon, 11 Aug 2003 15:41:39 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Does not need any change, the one suggested would have undesirable side effects. The intent that if a pathname is substituted to the null path that entry is to be skipped, the effect on later entries that might be files under that directory should not be affected by a parent being subtituted to the null path string. There is also a correlation between this and the -d option. _____________________________________________________________________________ Page: 708 Line: 27428 Section: pax Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The -s option (substitute) for pax is ambiguous. It states that a file archive member that substitutes to the empty string should be ignored when reading/writing archives. This does not specify what happens when a directory name substitutes to the empty string. Action: Add a new paragraph with the following text: If in write mode and a path name that coresponds to a directory substitutest to the empty string, then the directory and all its content is skipped. In copy mode, the substitution is handled the same way as if the substitution was done in write mode. _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 ajosey@opengroup.org Defect in XCU ed (rdvk# 33) {nine-bit-bytes} Thu, 14 Aug 2003 09:12:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The rationale or CH needs to note that prior versions of the standard allowed for implementations with bytes more than 8 bits,but that has been modified in this version _____________________________________________________________________________ Page: 343 Line: 13238 Section: ed Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Here and elsewhere in XCU we come across statements of the form : "If the size of a byte on the system is greater than nine bits, the ... is implementation-defined". This appears to be for systems outside of the standard, which requires support for 8 bit bytes Such occurrences should be stricken. Action: In ed, p343 l 13238 delete "If the size of a byte on the system is greater than nine bits, the format used for non-printable characters is implementation-defined." In ex p380 l14708 delete "If the size of a byte on the system is greater than 9 bits... implementation-defined." In file p448 l17345 delete "If the size of a byte on the system is greater than 9 bits... implementation-defined." In lex table 4-10 p540 l20802 delete "If the size of a byte on the system is greater than nine bits... implementation-defined." In the RATIONALE for lex l21021 p544 Change from "The description of octal and hexadecimal-digit escape sequences agrees with the ISO C standard use of escape sequences. See the RATIONALE for ed for a discussion of bytes larger than 9 bits being represented by octal values. Hexadecimal values can represent larger bytes and multi-byte characters directly, using as many digits as required." to "The description of octal and hexadecimal-digit escape sequences agrees with the ISO C standard use of escape sequences." In the RATIONALE for ed p348 l13451-13458 Delete "Systems with bytes too large to fit into three octal digits must devise other means of displaying non-printable characters. Consideration was given to requiring that the number of octal digits be large enough to hold a byte, but this seemed to be too confusing for applications on the vast majority of systems where three digits are adequate. It would be theoretically possible for the application to use the getconf utility to find out the CHAR_BIT value and deal with such an algorithm; however, there is really no portable way that an application can use the octal values of the bytes across various coded character sets, so the additional specification was not worthwhile." In od, p682 l 26379 delete "If the size of a byte on the system is greater than nine bits... implementation-defined." In sed p845 l32699 delete "If the size of a byte on the system is greater than 9 bits... implementation-defined." In tr, p927 l35871 delete If the size of a byte on the system is greater than nine bits... implementation-defined." _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 ajosey@opengroup.org Defect in XCU mailx (rdvk# 34) {system-startup-file} Wed, 13 Aug 2003 10:00:44 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 593 Line: 22926 Section: mailx Problem: Edition of Specification (Year): 2003 Defect code : 1. Error On line 22926 the system startup file is described as unspecified and yet on line 22946 its described as implementation-defined Action: Change on line 22946 from "implementation-defined" to "unspecified" _____________________________________________________________________________ OBJECTION Enhancement Request Number 35 ajosey@opengroup.org Defect in XCU nice (rdvk# 35) {system-startup-file} Wed, 13 Aug 2003 11:53:28 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 666 Line: 25769 Section: nice Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The first paragraph of rationale refers to text no longer in the standard after the page was revised for the 2001 edition. Action: Delete the first paragraph of the RATIONALE section. _____________________________________________________________________________ OBJECTION Enhancement Request Number 36 ajosey@opengroup.org Defect in XCU umask (rdvk# 36) {rationale} Wed, 13 Aug 2003 14:47:25 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 945 Line: 36539 Section: umask Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The rationale says that output is implementation-defined when the normative text says its unspecified Action: Change "implementation-defined" to "unspecified" on line 36539