Unapproved Draft Last updated 15 May 2009 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 schilling:fokus.fraunhofer.de Defect in XCU pax (rdvk# 2) {none} Fri, 29 Aug 2003 11:35:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 1 (->interps) AI-086 The line nos were from D6. The Proper line number is page 701, 27137 In the para "write" within DESCRIPTION The standard says it should read from stdin and -H does not apply. Standard is clear, standard is wrong, allow either behavior until the next revision Notes to the editor: ADD Page 701, line 27165, after the words "standard input": and each entry in this list shall be processed as if it had been a operand on the command line. _____________________________________________________________________________ Page: 2900 Line: 26911 Section: pax Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission For the write and copy mode of pax, there is the following text: If no file operands are specified, a list of files to copy, one per line, shall be read from the standard input. This does not mention whether the list of files taken from stdin should be treaten as command line args or not. For the implementation of the -H option it is needed to know, so this is a defect. Action: Decide whether the file names read from stdin should be treaten as command line args or not and then add a note to clearify the behavior. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 2 schilling:fokus.fraunhofer.de Defect in XCU pax (rdvk# 1) {none} Fri, 29 Aug 2003 11:45:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) The correct Line number is 27190 -c and -n should be mutually exclusive and so need to be [-c|-n] in the SYNOPSIS Fix needs to be on lines 27108 and 21109 Change From: 27108 pax [-cdnv][-H|-L][-f archive][-s replstr]...[pattern...] 27109 pax -r[-cdiknuv][-H|-L][-f archive][-o options]...[-p string]... 27110 [-s replstr]...[pattern...] To: 27108 pax [-dv][-c|-n][-H|-L][-f archive][-s replstr]...[pattern...] 27109 pax -r[-c|-n][-dikuv][-H|-L][-f archive][-o options]...[-p string]... 27110 [-s replstr]...[pattern...] _____________________________________________________________________________ Page: 2901 Line: 26964 Section: pax Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The -c option for pax should reverse the results of a pattern match. However it is not mentioned what should count as match. Rationale: The -n option limits the number of matches for a specific pattern to one. If you like to implement this, you need to know what counts as match. If the fact that the pattern matcher got a match counts as match, then -c would result in the first file that matches being omited from the output if -c -n is used. If the fact that the pattern matcher did not match (inverted match) counts as match, then -c would result in the first file that does not match being the only file to be included in the outout. Action: Decide on the expected behavior and clear up the text. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 schilling:fokus.fraunhofer.de Defect in XCU pax (rdvk# 3) {none} Fri, 29 Aug 2003 11:30:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) The correct page/line number is p703 27202 Change from The default behavior shall be to archive the symbolic link itself. To: The default behavior, when neither -H or -L are specififed shall be to archive the symbolic link itself. and also at 27230 _____________________________________________________________________________ Page: 2902 Line: 26971 Section: pax Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The desciption of the options -H and -L is very hard to understand. The last sentence for both options is ambiguous. It is unclear whether the text: "The default behavior shall be to archive the symbolic link itself." refers to the behavior that is in effect when -L or -H don't have been specified or if it refers to a case when all cases listed before do not apply. Second problem with this text: it does not mention how the text: "...file type which pax can normally archive ..." Should be understood. Third problem: Several other utilities also implement -H and -L. The standard should use a unique text for all descriptions for the same options in different utilities. Action: First problem: The minimum required action is to change this sentence for -H/-L to e.g.: If none of the cases listed before apply (e.g. the symlink does not point to a non-symlink file type or the file the symlink points to may not archives with the archive type currently in effect) pax should archive the symlink itself. Second problem: The solution is already in the text proposal for the first problem. The important change is to mention the archive type currently in effect as pax supports different archive types that allow a different set if file types to be archived. Third problem: 'find' behaves very similar to 'pax' regarding the -H/-L options. The text for the find utulity is much easier to understand. A good idea would be to use the text from find for all programs (at least for pax also) and add sentences for the additional care that needs to be taken for e.g. pax. _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 joannaf:sun.com Defect in XCU file (rdvk# 4) {jf-rk-file1} Wed, 24 Sep 2003 14:45:08 +0100 (BST) ____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: Add to SD5 (for D1) ____________________________________________________________________________ Page: 446 Line: 17249-17256 Section: file Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission In Table 4-8 File Utility Output Strings on page 446 lines 17249-17256 in the notes column the digit 3 hould be added as these are only applicable if the i option is not specified. Action: In Table 4-8 File Utility Output Strings on page 446 lines 17249-17256 change: 17249 Executable binary executable 4,6 17250 ar archive library (see ar) archive 4,6 17251 Extended cpio format (see pax) cpio archive 4,6 17252 Extended tar format (see ustar in pax) tar archive 4,6 17253 Shell script commands text 5,6 17254 C-language source c program text 5,6 17255 FORTRAN source fortran program text 5,6 17256 Regular file whose type cannot be determined data to 17249 Executable binary executable 3,4,6 17250 ar archive library (see ar) archive 3,4,6 17251 Extended cpio format (see pax) cpio archive 3,4,6 17252 Extended tar format (see ustar in pax) tar archive 3,4,6 17253 Shell script commands text 3,5,6 17254 C-language source c program text 3,5,6 17255 FORTRAN source fortran program text 3,5,6 17256 Regular file whose type cannot be determined data 3 ____________________________________________________________________________ EDITORIAL Enhancement Request Number 5 cynthia.eastham:Sun.COM Defect in XCU OPTIONS (rdvk# 5) {ce-pax-3} Wed, 24 Sep 2003 21:30:20 +0100 (BST) ____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: Add to SD5 (for D1) ERRATA ____________________________________________________________________________ Page: 706 Line: 27251 Section: pax-OPTIONS Problem: Edition of Specification (Year): 2001 Defect code : 1. Error Line 27251 says "to the form required by Table 4-16 (on page 719).", however the keywords with the leading c_ which the sentence is talking about are in Table 4-15 (on page 718). Action: Change line 27251 from: to the form required by Table 4-16 (on page 719). to: to the form required by Table 4-15 (on page 718). ____________________________________________________________________________ EDITORIAL Enhancement Request Number 6 cynthia.eastham:Sun.COM Defect in XCU pax (rdvk# 6) {ce-pax-4} Wed, 24 Sep 2003 21:37:04 +0100 (BST) ____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: Add to SD5 (for D1) ERRATA? ____________________________________________________________________________ Page: 707 Line: 27281 Section: pax Problem: Edition of Specification (Year): 2001 Defect code : 1. Error Line 27281 says "... specify a symbolic line". Since it is a dicussion behavior with symbolic links, it should say "... specify a symbolic link". Action: Change line 27281 from: An additional conversion specifier character, L, shall be used to specify a symbolic line to: An additional conversion specifier character, L, shall be used to specify a symbolic link ____________________________________________________________________________ EDITORIAL Enhancement Request Number 7 cynthia.eastham:sun.com Defect in XCU EXAMPLES (rdvk# 7) {ce-pax-2} Mon, 22 Sep 2003 22:36:27 +0100 (BST) ____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) ____________________________________________________________________________ Page: 722 Line: 27902, Section: pax-EXAMPLES Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The examples on lines 27902, 27909, and 27910 are missing data as the default output for %T is %b %e %H:%M %Y. Lines 27902 and 27910 are missing the year (%Y), and Line 27909 is missing hours and minutes (%H:%M). Line 27902 is missing %Y: -rw-rw--- Jan 12 15:53 1492 /usr/foo/bar Line 27909 is missing %H:%M: Jan 12 1991 Line 27910 is missing %Y: Jan 31 15:53 Action: Change line 27902 to: -rw-rw--- Jan 12 15:53 2003 1492 /usr/foo/bar Change line 27909 to: Jan 12 15:53 1991 Change line 27910 to: Jan 31 15:53 2003 _____________________________________________________________________________ COMMENT Enhancement Request Number 8 cynthia.eastham:sun.com Defect in XCU chgrp (rdvk# 8) {ce-chgrp-1} Tue, 30 Sep 2003 18:27:11 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 233 Line: 9027-9028 Section: chgrp Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The 2001 edition SYNOPSIS section is: chgrp -hR group file ... chgrp -R [-H | -L | -P] group file This was incorrect and changed in the 2003 edition to: chgrp [-hR] group file ... chgrp -R [-H | -L | -P] group file However, this still is incorrect as no where in the text for chgrp does it talk about the behavior when -h is specified with -R. Upon reading the text for the -h, -R, and -P option, it appears that chgrp -hR is equivalent to chgrp -RP, and therefore there is no need for -h to be allowed with -R. Action: Change: (2001 edition) chgrp -hR group file ... chgrp -R [-H | -L | -P] group file 2003 edition) chgrp [-hR] group file ... chgrp -R [-H | -L | -P] group file to: chgrp [-h] group file ... chgrp -R [-H | -L | -P] group file thus leaving chgrp -Rh unspecified. _____________________________________________________________________________ COMMENT Enhancement Request Number 9 cynthia.eastham:sun.com Defect in XCU chown (rdvk# 9) {ce-chown-1} Tue, 30 Sep 2003 18:31:05 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 242 Line: 9389-9390 Section: chown Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The 2001 edition SYNOPSIS section is: chown -hR owner[:group] file ... chown -R [-H | -L | -P] owner[:group] file This was incorrect and changed in the 2003 edition to: chown [-hR] owner[:group] file ... chown -R [-H | -L | -P] owner[:group] file However, this still is incorrect as no where in the text for chown does it talk about the behavior when -h is specified with -R. Upon reading the text for the -h, -R, and -P option, it appears that chown -hR is equivalent to chown -RP, and therefore there is no need for -h to be allowed with -R. Action: Change: (2001 edition) chown -hR owner[:group] file ... chown -R [-H | -L | -P] owner[:group] file (2003 edition) chown [-hR] owner[:group] file ... chown -R [-H | -L | -P] owner[:group] file to: chown [-h] owner[:group] file ... chown -R [-H | -L | -P] owner[:group] file thus leaving chown -Rh unspecified. _____________________________________________________________________________ OBJECTION Enhancement Request Number 10 don.cragun:sun.com Defect in XCU c99_OUTPUT_FILES (rdvk# 1) {dwc:c99.20031023} Thu, 23 Oct 2003 23:58:29 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 214 Line: 8400 Section: c99_OUTPUT_FILES Problem: Edition of Specification (Year): 2003 Defect code : 1. Error In earlier versions of this standard, it was generally assumed, but not explicitly specified that object files and executable files were regular files. With the changes that were made to XBD subclause 1.7.1.4 (File Read, Write, and Creation) in this revision and wording in c99 that doesn't quite match the templates in XBD 1.7.1.4, some people have interpreted the standard to require that c99 be able to write object files and executable files to files of type fattach()-ed STREAM, block special, character special, and FIFO special as well as to regular files. I do not believe that this was the intent when the c89 and c99 utilities were originally drafted. I do not object to implementations supporting all of these file types, but I see no reason for the standard to require that compilers work correctly with anything but regular files (and symlinks pointing to regular files). Action: Add a new sentence to the end of the paragraph in the OUTPUT FILES section on P214, L8400: If an existing file that does not resolve to a regular file matches the name of an object file being written or matches the name of an executable file being created by c99, it is unspecified whether c99 shall attempt to write the object file or create the executable file, or shall issue a diagnostic and exit with a non-zero exit status. Add a new paragraph to the rationale after P218, L8602: This standard specifies that the c99 utility must be able to use regular files for *.o files and for a.out files. Implementations are free to overwrite existing files of other types when attempting to create object files and executable files, but are not required to do so. If something other than a regular file is specified and using it fails for any reason, c99 is required to issue a diagnostic message and exit with a non-zero exit status. But for some file types, the problem may not be noticed for a long time. For example, if a FIFO named a.out exists in the current directory, c99 may attempt to open a.out and will hang in the open() call until another process opens the FIFO for reading. Then c99 may write most of the a.out to the FIFO and fail when it tries to seek back close to the start of the file to insert a timestamp (FIFOs are not seekable files). The c99 utility is also allowed to issues a diagnostic immediately if it encounters an a.out or *.o file that is not a regular file. For portable use, applications should ensure that any a.out, -o option-argument, or *.o files corresponding to any *.c files do not conflict with names already in use that are not regular files or symbolic links that point to regular files. _____________________________________________________________________________ COMMENT Enhancement Request Number 11 craig.mohrman:sun.com Defect in XCU c99 (rdvk# 1) {1} Fri, 31 Oct 2003 23:28:53 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 214 Line: 8404 Section: c99 Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission XNS5.2 describes the header. That header failed to make it onto the c99 utility page. Action: XCU page 214 line 8404 On the c99 utility page somewhere in the description of the -l c in the EXTENDED DESCRIPTION section please add: to the existing list of headers. XCU page 214 line 8428 Further down in the -l xnet description, again add the same header to the existing list of headers. _____________________________________________________________________________ OBJECTION Enhancement Request Number 12 mstrbill:us.ibm.com Defect in XBD vi (rdvk# 2) {WLT-XCU-1} Fri, 24 Oct 2003 14:47:08 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 12 (->interps) AI-087 The TC2 page references for this item are p1017 line 39169 Handle as an interpretation request (defect). The standards states the requirements, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. The suggested changes to be put forward as proposed text for a future revision. Proposed changes: Existing 1 and 2 become 2 and 3 and this wording is inserted before line 39048 1. If the text in the buffer is from more than a single line, then set to the last column on which any portion of the first character from the buffer is displayed. _____________________________________________________________________________ Page: 1016 Line: 39047 Section: vi Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The vi Put from Buffer Before (P) command description is missing the multiline requirements that was added to the Put from Buffer Following (p) command. This causes problem when putting partial multiline text, i.e. like that can be obtained by doing y/search_text . Currently TC1 states Current line: Unchanged. Current column: If the buffer text is in line mode: If the buffer text is in character mode: 1. If the buffer is the unnamed buffer, set to the last column on which any portion of the last character from the buffer is displayed. 2. Otherwise, set to the first column on which any portion of the first character from the buffer is displayed. so for a multiline Put, the current line is to remain unchanged and the cursor is to be placed at the end of the last line inserted. This is means of course that the current line cannot stay unchanged. So unless this was intended to give Capt Kirk and Mr. Spock a means to fight the latest evil supercomputer, similar wording to the following from the p description needs to be added. 1. If the text in the buffer is from more than a single line, then set to the last column on which any portion of the first character from the buffer is displayed. Action: Add required wording to correct contradiction in the vi -P description. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 13 don.cragun:sun.com Defect in XCU mv (rdvk# 1) {dwc:mv-1} Fri, 7 Nov 2003 15:35:52 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 655 Line: 25350 Section: mv Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The second paragraph of the description and the operands section talk about a target_dir operand in the second synopsis form, but there is no target_dir operand in the synopsis section. Action: Change: mv [-fi] source_file... target_file on P655, L25350 to: mv [-if] source_file... target_dir _____________________________________________________________________________ COMMENT Enhancement Request Number 14 bug1:iinet.net.au Defect in XCU diff (rdvk# 1) {cruftydiff} Wed, 28 Jan 2004 08:24:35 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) This is an enhancement request. It was agreed that this should go down the future directions track, the submitter should be referred to see Austin/112r1 for more information. In particular a proposal of changes is required, and that proposal should include a survey of existing practise. _____________________________________________________________________________ Page: 0 Line: 0 Section: diff Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Diff is utility that compares two files and outputs the difference, it is commonly used in software development to share updated source code. POSIX mentions 3 formats that the difference can be described in, these formats are specified using the -e (ed format), -f (modified ed) and -c (context diff). There is another format which is similar to your context diff, it is called a unified diff, for an implementation please refer to the GNU diff program. Ive been an active member of the open source computing for a number of years and i would estimate unified diff is used in over 95% of diff's i have seen. I feel the omision of the default format of diff reflects very poorly on what otherwise appears to be a fairly accurate standard. Action: I recommend you incude the unified diff format, you may also want to make some of the other formats as obsolete or depreciated. _____________________________________________________________________________ COMMENT Enhancement Request Number 15 ru:FreeBSD.org Defect in XCU locale (rdvk# 1) {1} Thu, 5 Feb 2004 11:19:42 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 15(->interps track) AI-088 The review group agreed that the standard is unclear about LANG when it has no value. This should be raised as an interpretation and forwarded to the sponsor for consideration in a future revision. Proposed changes for a future revision are as follows: Insert a new 1st para in STDOUT The LANG variable shall be written first using the format "LANG=%s\n", If LANG is not set or is an empty string the value is the empty string. Change the existing first para from: If locale is invoked without any options or operands, the names and values of the LANG and LC_* environment variables described in this volume of IEEE Std 1003.1-2001 shall be written to the standard output, one variable per line, with LANG first, and each line using the following format. Only those variables set in the environment and not overridden by LC_ALL shall be written using this format: to: If locale is invoked without any options or operands, the names and values of the LC_* environment variables described in this volume of IEEE Std 1003.1-2001 shall be written to the standard output, one variable per line, and each line using the following format. Only those variables set in the environment and not overridden by LC_ALL shall be written using this format: _____________________________________________________________________________ Page: 0 Line: 0 Section: locale Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required There's an unclarity in the STDOUT section of the "setlocale" utility: http://www.opengroup.org/onlinepubs/007904975/utilities/locale.html Here's the relevant text: If locale is invoked without any options or operands, the names and values of the LANG and LC_* environment variables described in this volume of IEEE Std 1003.1-2001 shall be written to the standard output, one variable per line, with LANG first, and each line using the following format. Only those variables set in the environment and not overridden by LC_ALL shall be written using this format: "%s=%s\n", , The names of those LC_* variables associated with locale categories defined in this volume of IEEE Std 1003.1-2001 that are not set in the environment or are overridden by LC_ALL shall be written in the following format: "%s=\"%s\"\n", , It is unclear should the value of LANG be output if it's not set in the environment, or if both LANG and LC_ALL are set in the environment, and it's unclear which format should be used to output LANG. Action: After some research on different operating systems, I think the intent is to always output the value of the LANG variable (even if unset), regardless of whether LC_ALL is set or not, using the first format. I suggest to change the text as follows: If locale is invoked without any options or operands, the names and values of the LANG and LC_* environment variables described in this volume of IEEE Std 1003.1-2001 shall be written to the standard output, one variable per line, with LANG first, and each line using the following format. The LANG variable, and only those LC_* variables set in the environment and not overridden by LC_ALL shall be written using this format: "%s=%s\n", , If LANG is not set, it shall be written as: "LANG=\n" The names of those LC_* variables associated with locale categories defined in this volume of IEEE Std 1003.1-2001 that are not set in the environment or are overridden by LC_ALL shall be written in the following format: "%s=\"%s\"\n", , _____________________________________________________________________________ COMMENT Enhancement Request Number 16 ajosey:opengroup.org Defect in XCU cp (rdvk# 2) {aj.cp.options} Wed, 18 Feb 2004 09:16:16 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The standard is what it says. The words "in effect" means appears on the command line, there is no difference between cp -fi and cp -if, the details are on section 3 of the cp manual page. _____________________________________________________________________________ Page: 268 Line: 10461 Section: cp Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The standard does not talk clearly to the interplay between the -i and -f options for the cp utility, whereas it does describe the interplay for the same options within the rm and mv utilities (in which case the last option wins). This would appear to be an omission in the standard. for example, what happens for # create two files touch aa bb cp -if aa bb cp -fi aa bb It appears that some implementations support the last option applies rule, whereas others will alway prompt for interactive input regardless. Action: Consideration should be given to make the standard consistent between cp/mv/rm in a future direction. If the standard developers agree that the situation is unclear then an interpretation should be made that no conformance distinction can be made between implementations who handle the -fi and -if options differently for this version of the standard and the matter referred to the sponsor. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 17 gwc:opengroup.org Defect in XCU pax (rdvk# 1) [gwc pax ctime refs] Wed, 18 Feb 2004 13:17:48 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) The review group agreed that this was an editorial matter, and that the references to the now removed ctime field, which is removed in TC2, should be removed as noted for consistency. (also check the rationale section) _____________________________________________________________________________ Page: 703,722 Line: 27120,27905 Section: pax Problem: Defect code : 1. Error In TC2 the ctime keyword for pax extended headers was removed. However, there are two references to ctime elsewhere that were not updated at the same time. Action: On line 27120 change: atime, ctime, and mtime extended header records to: atime and mtime extended header records On line 27905 change: -o listopt='(name)s\n%(ctime)T\n%T' to: -o listopt='(name)s\n%(atime)T\n%T' _____________________________________________________________________________ COMMENT Enhancement Request Number 18 Gunnar.Ritter:pluto.uni-freiburg.de Defect in XCU mailx (rdvk# 1) {n/a} Fri, 19 Mar 2004 14:54:51 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 18(->interps) AI-089 This issue should be forwarded down the interpretations track a a proposed defect in the standard. The proposed change for a future revision is to revert to wording based on the 1992 standard: LC_TIME This variable may determine the format and contents of the date and time strings written by mailx. This volume of IEEE Std 1003.1-2001 specifies the effects of this variable only for systems supporting the User Portability Utilities Option. _____________________________________________________________________________ Page: 0 Line: 0 Section: mailx Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The following text in utilities/mailx.html, # LC_TIME # Determine the format and contents of the date and time strings written by mailx. seems to imply that all date and time strings written by mailx should be affected by the current locale. However, this may not affect date and time strings in Internet email and following the Unix 'From_' lines, because it would otherwise violate RFC 2822 or confuse implementations, respectively. Existing implementations seem to follow this rule in general. Moreover, existing implementations generally seem to simply copy the date and time string following the 'From_' line of messages to the output when displaying header summaries. In effect, date and time strings are thus always shown as in the POSIX locale. In IEEE Std 1003.2-1992, the text for LC_TIME was 'this variable may determine . . .'. This is still mentioned in the current rationale, but not in the standards text. Action: In any case, it should be made clear that LC_TIME does not apply to any parts of message formats, even if these formats are outside the scope of POSIX anyway. LC_TIME should be made optional for mailx again. _____________________________________________________________________________ OBJECTION Enhancement Request Number 19 Gunnar.Ritter:pluto.uni-freiburg.de Defect in XCU pax (rdvk# 1) [] Wed, 24 Mar 2004 17:15:53 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) All page and line numbers here refer to the Shell and Utilities volumes of the 2003 edition of the standard (which includes TC1). No changes to pax in TC2 are affected by this proposal. The intent is that these changes be listed in a formal interpretation of this issue as a proposed change to be included in the next revision of the standard. Note that the -o invalid=binary added action is the heart of this proposal; the rest is just support, clean up, and rationale for that addition. Make the following changes and additions to the standard: 1. Add a hdrcharset keyword to the pax extended headers. Before page 716, line 27766 add a tagged entry as follows: hdrcharset The name of the character set used to encode the value field of the gname, linkpath, path, and uname pax extended header records. The entries in the following table are defined to refer to known standards; additional names may be agreed on between the originator and the recipient. Formal Standard ======================= ============================= ISO-IRd10646d2000dUTF-8 ISO/IEC 10646, UTF-8 encoding BINARY None (EDITORIAL NOTE: the "d"s in the column need to be replaced by the Greek delta character indicating a single character as in the current table on page 715, lines 27699 through 27714.) If no hdrcharset extended header record is specified, the default character set used to encode all values in extended header records shall be the ISO/IEC 10646:2000, UTF-8 encoding. The BINARY entry indicates that all values recorded in extended headers for affected files are unencoded binary data from the underlying system. 2. Add a new action for the -o invalid=action option. Before page 705, line 27323 add a tagged paragraph as follows: binary In write mode, pax shall generate a hdrcharset=BINARY extended header record for each file with a file name, link name, group name, owner name, or any other field in an extended header record that cannot be translated to the UTF-8 codeset, allowing the archive to contain the files with unencoded extended header record values. In read or copy mode, pax shall use the values specified in the header without translation, regardless of whether this may overwrite an existing file with a valid name. In list mode, pax shall behave identically to the bypass action. 3. Clarify that invalid=UTF-8 applies to whatever codeset has been specified for that extended header; not just extended headers encoded using UTF-8. Add to the end of the paragraph on page 706, line 27335: If a hdrcharset extended header record is in effect for this file, the character set specified by that record shall be used instead of UTF-8. If a hdrcharset=BINARY extended header record is in effect for this file, no translation shall be performed. 4. Clarify List Mode Format Specifications use of UTF-8. Change: UTF-8 encoding on page 709, lines 27498-27499 to: UTF-8 encoding (or alternative encoding specified by any hdrcharset extended header record) 5. Clarify that translation errors can occur when in any mode; not just in read mode and list mode. Change the last paragraph in the STDERR section (page 712, lines 27611-27615) from: When pax is in read mode or list mode, using the -xpax archive format, and a filename, link name, owner name, or any other field in an extended header record cannot be translated from the pax UTF-8 codeset format to the codeset and current locale of the implementation, pax shall write a diagnostic message to standard error, shall process the file as described for the -o invalid=option, and then shall process the next file in the archive. to: When using the -xpax archive format, if a file name, link name, group name, owner name, or any other field value in an extended header record cannot be translated between the codeset in use for that extended header record and the character set of the current locale, pax shall write a diagnostic message to standard error, shall process the file as described for the -o invalid=option, and then shall continue processing with the next file. 6. Clarify which pax extended header record value fields are affected by a hdrcharset extended header record. Change the text on page 714, lines 27675-27679 from: The extended header records shall be encoded according to the ISO/IEC 10646-1:2000 standard (UTF-8). The field, , equals sign, and shown shall be limited to the portable character set as encoded in UTF-8. The and fields can be any UTF-8 characters. The field shall be the decimal length of the extended header record in octets, including the trailing . to: The extended header records shall be encoded according to the ISO/IEC 10646-1:2000 standard (UTF-8). The field, , equals sign, and shown shall be limited to the portable character set as encoded in UTF-8. The fields can be any UTF-8 characters. The field shall be the decimal length of the extended header record in octets, including the trailing . If there is a hdrcharset extended header in effect for a file, the field for any gname, linkpath, path, and uname extended header records shall be encoded using the character set specified by the hdrcharset extended header record; otherwise, the field shall be encoded using UTF-8. The field for all other keywords specified by this standard shall be encoded using UTF-8. 7. Clarify the use of UTF-8 in gname extended header records. Change the two sentences on page 715 lines 27735-27739 from: When used in read, copy, or list mode, pax shall translate the name from the UTF-8 encoding in the header record to the character set appropriate for the group database on the receiving system. If any of the UTF-8 characters cannot be translated, and if the -o invalid=UTF-8 option in not specified, the results are implementation-defined. to: When used in read, copy, or list mode, pax shall translate the name from the encoding in the header record to the character set appropriate for the group database on the receiving system. If any of the characters cannot be translated, and if neither the -o invalid=UTF-8 option nor the -o invalid=binary option is specified, the results are implementation-defined. 8. Clarify the use of UTF-8 in linkpath extended header records. Change "from the UTF-8 encoding" on page 716, line 27749 to "from the encoding in the header". 9. Clarify the use of UTF-8 in path extended header records. Change "from the UTF-8 encoding" on page 716, line 27761 to "from the encoding in the header". 10. Clarify the use of UTF-8 in uname extended header records. Change the two sentences on page 716 lines 27780-27784 from: When used in read, copy, or list mode, pax shall translate the name from the UTF-8 encoding in the header record to the character set appropriate for the user database on the receiving system. If any of the UTF-8 characters cannot be translated, and if the -o invalid=UTF-8 option in not specified, the results are implementation-defined. to: When used in read, copy, or list mode, pax shall translate the name from the encoding in the header record to the character set appropriate for the user database on the receiving system. If any of the characters cannot be translated, and if neither the -o invalid=UTF-8 option nor the -o invalid=binary option is specified, the results are implementation-defined. 11. Add rationale as follows: After page 727, line 28258 add the following paragraphs: The POSIX.2-1992 and POSIX.1-2001 requirements for pax, however, made it very difficult to create a single archive containing files created using extended characters provided by different locales. This revision adds the hdrcharset keyword to make it possible to archive files in these cases without dropping files due to translation errors. Translating file names and other attributes from a locale's encoding to UTF-8 and then back again can lose information, as the resulting file name might not be byte-for-byte equivalent to the original. To avoid this problem, users can specify the -o hdrcharset=binary option, which will cause the resulting archive to use binary format for all names and attributes. Such archives are not portable among hosts that use different native encodings (e.g., EBCDIC- versus ASCII-based encodings), but they will allow interchange among the vast majority of POSIX file systems in practical use. Also, the -o hdrcharset=binary option will cause pax in copy mode to behave more like other standard utilities like cp. If the values specified by the -o exthdr.name=value, -o globexthdr.name=value, or by $TMPDIR (if -o globexthdr.name is not specified) require a character encoding other than that described in ISO/IEC 646:1991, a path extended header record will have to be created for the file. If a hdrcharset extended header record is active for such headers, it will determine the codeset used for the the value field in these extended path header records. These path extended header records always need to be created when writing an archive even if hdrcharset=binary has been specified and would contain the same (binary) data that appears in the ustar header record prefix and name fields. (In other words, an extended header path record is always required to be generated if the prefix or name fields contain non-ASCII characters even when hdrcharset=binary is also in effect for that file.) 12. Clean up references to UTF-8 in rationale as follows: Change page 727, lines 28266-28267 from: specifically the UTF-8 action. (Note that an existing file that is named with a UTF-8 encoding is still subject to overwriting in this case. The -k option closes that loophole.) to: specifically the UTF-8 and binary actions. (Note that an existing file is still subject to overwriting in this case. The -k option closes that loophole.) Add to APPLICATION USAGE When archives containing binary header information are listed the filenames printed may cause strange behavior on some terminals. _____________________________________________________________________________ Page: 0 Line: 0 Section: pax Problem: The 'pax' format states that extended header records have to be encoded in UTF-8. This in particular concerns the file names in the 'path' and 'linkpath' fields. Since file names are usually encoded as byte sequences on the host system, the description of these fields states that those sequences have to be converted to UTF-8 when being stored. This, however, leads to two major problems which make the 'pax' format effectively unusable for a general purpose archiver on traditional Unix implementations: 1. Traditional Unix implementations allow an application to pass arbitrary byte sequences to open() and related calls. They just handle the two bytes (not characters!) '/' and '\0' specially and otherwise accept anything. In particular, they do not require these byte sequences to have a character representation in any character encoding. Thus they also do not require these sequences to be in any relation to sequences representing characters in the current locale. Moreover, many different locales may be used in parallel by different users on the same machine or even by one user in different terminals on the same machine. Even if the file names used for a single open() call are representable in the respective current locale, the Unix systems does not keep track of this relation anywhere. Thus if the super-user creates an archive of the whole file system, or if a user who has used multiple locales creates an archive of his entire data, there is no method for him to determine which character encoding has been used for a single file name. It has sometimes been proposed as a workaround to create such an archive in a locale which assigns a separate character to every single byte, such as ISO-8859-1. This is not a good workaround, however, as 1) it is against the purpose of UTF-8 conversion, since it effectively destroys the character representation of file names not in the locale used for archiving; 2) it forces the user to manually keep track of the locale used, such as on the tape label; 3) there is no guarantee that an equivalent locale is available on another system, including future revisions of the same implementation. (In fact, there are ISO-8859-1 locales which treat the range 0200 to 0237 as illegal.) In effect, the 'pax' format is unable to hold a complete Unix file hierarchy in a sane way. 2. File names do not only occur in archive headers; the may also occur in file data stored inside the archive. An example would be a Makefile. But this may also effect files which mostly contain binary data, such as an executable or an office document. Such files cannot be subject to character conversion when the archive is created. Now if an archive is created which e. g. contains an office document and some external image files with 8-bit file names to which links inside the office document point, the byte representation in the 'pax' archive headers differs from that in the file data within the archive. This will lead to broken links if the archive is extracted in another locale than the one it was created in. (The portability restrictions concerning locales mentioned above apply again here.) In effect, the 'pax' format breaks links between the files stored. Action: Add fields to store file and link names as byte sequences, either replacing or supplementing the existing 'path' and 'linkpath' fields. It might then be advisable to do the same for the 'uname' and 'gname' fields too. _____________________________________________________________________________ COMMENT Enhancement Request Number 20 Gunnar.Ritter:pluto.uni-freiburg.de Defect in XCU mailx (rdvk# 2) [] Wed, 24 Mar 2004 17:14:33 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 20(->interps track) AI-090 Interps the standard says and concerns are being fwd to the sponsor 2003 Ed p600 l 23219- If the current message has not been written (for example, by the print command) since mailx started or since any other message was the current message, behave as if the print command was entered. Otherwise, if there is an undeleted message after the current message, make it the current message and behave as if the print command was entered. Otherwise, an informational message to the effect that there are no further messages in the mailbox shall be written, followed by the mailx prompt. Should the current message location be the result of an immediately preceeding "hold" or "preserve" command, next will act as if the current message has already been written. See XCU ERN 54 _____________________________________________________________________________ Page: 0 Line: 0 Section: mailx Problem: If a 'next' command follows a 'hold' command in mailx, traditional implementations display the next message following the one the 'hold' applied to, as if the holded message had been printed. This makes sense since the 'hold' usually implies that the user knows what is in the message and does not wish to view it again immediately. But the behavior apparently conflicts with POSIX as the description states that the 'next' command may only advance if the current message has been written before, which is not the case with 'hold'. Action: Update the description of the 'next' command such that 'hold' makes it also advance to the following message. ______________________________________________________________________________ COMMENT Enhancement Request Number 21 gwc:opengroup.org Defect in XCU awk (rdvk# 1) [gwc awk srand time] Fri, 16 Apr 2004 16:18:22 +0100 ______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: XCU ERN 21 awk what does srand() time of day mean Reject The standard does not specify what it means and that is intentional. To specify the means would mean specifying the implementation. ______________________________________________________________________________ ______________________________________________________________________________ Page: 167 Line: 6364 Section: awk Problem: Defect code : 3. Clarification required The description of the srand() function for awk says it uses the "time of day" if no argument is passed to srand(). What does this mean exactly? In particular: 1. Does it relate to the time value returned by the function gettimeofday() in XSH? If so, is it just the seconds or the fractional part as well? 2. Or is it supposed to imply a value with a cycle of 24 hours? All the implementations I have tried use just the seconds from the time returned by gettimeofday() (i.e. the return value of time()). I think a value with a cycle of 24 hours would be a bad idea and the specification should make it clear that this is not allowed. (Consider the effect on a cron job which is started at the same time each day.) Another thing to consider is that awk's srand() provides a known way of obtaining the seconds since the epoch in a shell script (using awk 'BEGIN { srand(); printf "%d\n", srand(); }'). It is currently not clear how portable the method is, and a clarification of the standard would remove any doubts. Action: Preferably change "time of day if expr is omitted" to one of the following: "current system time, as would be returned by the time() function in the System Interfaces volume of IEEE Std 1003.1-2001, if expr is omitted" or: "current system time, as would be returned in tv_sec by the gettimeofday() function in the System Interfaces volume of IEEE Std 1003.1-2001, optionally plus tv_usec*1.0e-6, if expr is omitted" _______________________________________________________________________________ OBJECTION Enhancement Request Number 22 eggert:cs.ucla.edu Defect in XCU awk (rdvk# 2) {20040504a} Tue, 4 May 2004 23:54:01 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 22(->interps track) AI-189 Send down the interps track We will need to change both normative text and the rationale. On awk page 157 line 6050 Change from: A string value shall be converted to a numeric value by the equivalent of the following calls to functions defined by the ISO C standard: setlocale(LC_NUMERIC, ""); numeric_value = atof(string_value); To A string value shall be converted to a numeric value either by the equivalent of the following calls to functions defined by the ISO C standard: setlocale(LC_NUMERIC, ""); numeric_value = atof(string_value); or by converting the initial portion of the string to type double representation as follows: The input string is decomposed into two parts: an initial, possibly empty, sequence of white-space characters (as specified by isspace()) and a subject sequence interpreted as a floating-point constant. The expected form of the subject sequence is an optional + or - sign, then a non-empty sequence of digits optionally containing a period, then an optional exponent part. An exponent part consists of e or E, followed by an optional sign, followed by one or more decimal digits. The sequence starting with the first digit or the period (whichever occurs first) is interpreted as a floating constant of the C language, and that if neither an exponent part nor a period appears, a period is assumed to follow the last digit in the string. If the subject sequence begins with a minus sign, the value resulting from the conversion is negated. Page 177 Change from 8. The token NUMBER shall represent a numeric constant. Its form and numeric value shall be equivalent to either of the tokens floating-constant or integer-constant as specified by the ISO C standard, with the following exceptions: a. An integer constant cannot begin with 0x or include the hexadecimal digits 'a', 'b', 'c', 'd', 'e', 'f', 'A', 'B', 'C', 'D', 'E', or 'F'. b. The value of an integer constant beginning with 0 shall be taken in decimal rather than octal. c. An integer constant cannot include a suffix ( 'u', 'U', 'l', or 'L' ). d. A floating constant cannot include a suffix ( 'f', 'F', 'l', or 'L' ). To: 8. The token NUMBER shall represent a numeric constant. Its form and numeric value shall either be equivalent to the token decimal-floating-constant as specified by the ISO C standard, or it shall be a sequence of decimal digits and shall be evaluated as an integer constant in decimal. In addition, implementations may accept numeric constants with the form and numeric value equivalent to the tokens hexadecimal-constant and hexadecimal-floating-constant as specified by the ISO C standard. XCU p 185 Replace the following text in rationale 7293: The description of numeric string processing is based on the behavior of the atof ( ) function in the ISO C standard. While it is not a requirement for an implementation to use this function, many historical implementations of awk do. In the ISO C standard, floating-point constants use a period as a decimal point character for the language itself, independent of the current locale, but the atof ( ) function and the associated strtod( ) function use the decimal point character of the current locale when converting strings to numeric values. Similarly in awk, floating-point constants in an awk script use a period independent of the locale, but input strings use the decimal point character of the locale. with Historical implementations of awk did not parse hexadecimal integer or floating constants like "0xa" and "0xap0". Due to an oversight, the 2001 through 2004 editions of this standard required support for hexadecimal floating constants. This was due to the reference to atof(). This version of the standard allows but does not require implementations to use atof() and includes a description of how floating point numbers are recognized as an alternative to match historic behavior. The intent of this change is to allow implementations to recognize floating point constants according to either the C89 or the C99 standards, and to allow (but not require) implementations to recognize hexadecimal integer constants. Add to CH The EXTENDED DESCRIPTION is changed to make the support of hexadecimal integer and floating constants optional. _______________________________________________________________________________ Page: 177 Line: 6924 Section: awk Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The C99 standard introduced the notion of hexadecimal floating constants, and since the POSIX "awk" specification refers to C99, POSIX "awk" is required to support them. However, the POSIX specification was not updated with this C99 change in mind, as as a result POSIX "awk" is required to support hexadecimal numbers in some contexts but not others. This should be fixed, either by requiring support for hexadecimal numbers everywhere, or disallowing it everywhere. Here's the problem. XCU page 177 lines 6924-6925 contains this restriction: a. An integer constant cannot begin with 0x or include the hexadecimal digits 'a', 'b', 'c', 'd', 'e', 'f', 'A', 'B' 'C', 'D', 'E', or 'F' . However, restriction (a) contradicts the awk rationale, which says (XCU page 185 lines 7293-7295): The description of numeric string processing is based on the behavior of the atof() function in the ISO C standard. While it is not a requirement for an implementation to use this function, many historical implementations of awk do. Restriction (a) evidently was inspired by C89, where atof() did not parse hexadecimal numbers. However, in C99 atof() must parse hexadecimal numbers like "0xa" and "0xap0". Hence the rationale no longer matches the text of the standard. The "awk" specification does not contain any restrictions against hexadecimal floating constants. As a result of this inconsistency, a conforming awk implementation must treat the hexadecimal floating constant "0xap0" as a number equal to 10, but "awk" is not allowed to treat the hexadecimal integer constant "0xa" as a number equal to 10 -- even though atof() does so. Also, restriction (a) causes an inconsistency with another POSIX requirement (XCU page 157 lines 6050-6053): A string value shall be converted to a numeric value by the equivalent of the following calls to functions defined by the ISO C standard: setlocale(LC_NUMERIC, ""); numeric_value = atof(string_value); Hence, for example, the Awk expression ("0xa" + 0 == 10) must evaluate to 1, even though restriction (a) means that the similar expression (split("0xa", a) && a[1] == 10) must evaluate to 0 because "0xa" is not considered to be a numeric string. I see three possible fixes: 1. The standard is correct as-is. Conforming "awk" implementations must parse hexadecimal floating constants and must reject hexadecimal integer constants, and they must parse numeric strings differently from strings explicitly converted to numbers. (If this alternative is chosen, the rationale should explain this.) 2. The intent was for "awk" to disallow hexadecimal numbers; add more restrictions that disallow hexadecimal floating constants. 3. The intent was for "awk" to use atof(), so remove the restriction disallowing hexadecimal integer constants. (1) is entirely unsatisfactory, as it's not internally consistent and disagrees with the rationale. (2) is internally consistent, but disagrees with the rationale. (3) is internally consistent and agrees with the rationale. It can be accomplished by removing restriction (a). Action: Remove the following text from XCU page 177 lines 6924-6925. a. An integer constant cannot begin with 0x or include the hexadecimal digits 'a', 'b', 'c', 'd', 'e', 'f', 'A', 'B' 'C', 'D', 'E', or 'F' . Append the following text to the awk rationale, after XCU page 185 line 7300: Historical implementations of awk did not parse hexadecimal integer or floating constants like "0xa" and "0xap0". Because C99 required support for these constants in atof(), support for them is now required in awk. This is a silent change to the awk language: for example, the expression ("0xap0" + 0) formerly returned 0, but now returns 10. Due to an oversight, the 2001 through 2004 editions of this standard required support only for hexadecimal floating constants, but this edition has corrected this to require support for hexadecimal integer constants as well. ______________________________________________________________________________ OBJECTION Enhancement Request Number 23 eggert:cs.ucla.edu Defect in XCU awk (rdvk# 3) {20040511a} Tue, 11 May 2004 21:13:19 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 23(->interps track) AI-201 Send down the interps track Change XCU page 158 lines 6074-6081 from: and after all the following conversions have been applied, the resulting string would lexically be recognized as a NUMBER token as described by the lexical conventions in Grammar: * All leading and trailing s are discarded. * If the first non- is '+' or '-' , it is discarded. * Changing each occurrence of the decimal point character from the current locale to a period. If a '-' character is ignored in the preceding description, the numeric value of the numeric string shall be the negation of the numeric value of the recognized NUMBER token. Otherwise, the numeric value to: and an implementation-dependent condition corresponding to either (a) or (b) below is met. a. After the equivalent of the following calls to functions defined by the ISO C standard, string_value_end would differ from string_value, and any characters before the terminating null character in string_value_end would be s: char *string_value_end; setlocale(LC_NUMERIC, ""); numeric_value = strtod (string_value, &string_value_end); b. After all the following conversions have been applied, the resulting string would lexically be recognized as a NUMBER token as described by the lexical conventions in Grammar: * All leading and trailing s are discarded. * If the first non- is '+' or '-' , it is discarded. * Each occurrence of the decimal point character from the current locale is changed to a period. In case (a) the numeric value of the numeric string shall be the value that would be returned by the strtod() call. In case (b) if the first non- is '-', the numeric value of the numeric string shall be the negation of the numeric value of the recognized NUMBER token; otherwise the numeric value Append the following text to the awk rationale, after XCU page 185 line 7300: Historical implementations of awk did not support floating-point infinities and NaNs in numeric strings, e.g., "-INF" and "NaN". However, implementations that use the atof() or strtod() function to do the conversion picked up support for these values if they used a C99 version of the function instead of a C89 version. Due to an oversight, the 2001 through 2004 editions of this standard did not allow support for infinities and NaNs, but in this revision support is allowed (but not required). This is a silent change to the behavior of awk programs; for example, in the POSIX locale the expression ("-INF" + 0 < 0) formerly had the value 0 because "-INF" converted to 0, but now it may have the value 0 or 1. _______________________________________________________________________________ Page: 177 Line: 6074 Section: awk Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The C99 standard introduced the notion of an explicit string representation for infinities and NaNs, and since the POSIX "awk" specification refers to C99, POSIX "awk" is required to support them. However, the POSIX specification was not updated with this C99 change in mind, as as a result POSIX "awk" is required to support infinities and NaNs in some contexts but not others. This should be fixed, either by requiring support for them everywhere, or disallowing it everywhere. Here's the problem. XCU page 177 lines 6074-6079 says that a string value is considered a numeric string only if: after all the following conversions have been applied, the resulting string would lexically be recognized as a NUMBER token as described by the lexical conventions in Grammar: * All leading and trailing s are discarded. * If the first non- is '+' or '-' , it is discarded. * Changing each occurrence of the decimal point character from the current locale to a period. and the rationale (page 181 lines 7121-7124) says: The intent has been to specify historical practice in almost all cases. The one exception is that, in historical implementations, variables and constants maintain both string and numeric values after their original value is converted by any use. As I understand it, historical practice was to invoke strtod on the string, and to check that the string was entirely parsed by strtod except possibly for some trailing blanks. This matches the specification above. However, now that C99 has modified strtod's behavior with respect to infinities and NaNs, there is a discrepancy between this historical practice and what is now specified. For example, in the POSIX locale the following shell command: awk -v n=-INF -v p=+INF 'BEGIN {print (n < p)}' , which talks about a similar problem for hexadecimal floating-point numbers. The problems are related and perhaps should be considered together. Action: Change XCU page 177 lines 6074-6081 from this: and after all the following conversions have been applied, the resulting string would lexically be recognized as a NUMBER token as described by the lexical conventions in Grammar: * All leading and trailing s are discarded. * If the first non- is '+' or '-' , it is discarded. * Changing each occurrence of the decimal point character from the current locale to a period. If a '-' character is ignored in the preceding description, the numeric value of the numeric string shall be the negation of the numeric value of the recognized NUMBER token. Otherwise, the to this: and after the equivalent of the following calls to functions defined by the ISO C standard, string_value_end differs from string_value, and all characters in string_value_end are s. char *string_value_end; setlocale(LC_NUMERIC, ""); numeric_value = strtod (string_value, &string_value_end); The Append the following text to the awk rationale, after XCU page 185 line 7300: Historical implementations of awk did not support floating-point infinities and NaNs in data, e.g., "-INF" and "NaN". Because C99 required support for these constants in atof(), support for them is now required in awk. This is a silent change to the behavior of awk programs; for example, in the POSIX locale the expression ("-INF" + 0 < 0) formerly returned 0 because "-INF" converted to zero, but now returns 1 because "-INF" converts to negative infinity or to a huge negative value. Due to an oversight, the 2001 through 2004 editions of this standard did not allow support for infinities and NaNs in numeric strings, but this has been corrected in this edition. _____________________________________________________________________________ OBJECTION Enhancement Request Number 24 gwc:opengroup.org Defect in XCU cd (rdvk# 1) [gwc cd relative paths] Tue, 18 May 2004 16:28:51 +0100 ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-037 This is an interpretation. The standards states the requirements for the cd utility and its handling of symbolic links, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: A number of defects have been identified with how the cd utility handles symbolic links. Notes to the Editor (not part of the interpretation) ---------------------------------------------------- Replace step 6 with the following: "6. If the -P option is in effect, set curpath to the directory operand. Otherwise, set curpath to the string formed by the concatenation of the value of PWD, a slash character, and the operand." Replace step 7 with the following: "7. If the -P option is in effect, proceed to step 10. If curpath does not begin with a slash character, set curpath to the string formed by the concatenation of the value of PWD, a slash character, and the operand." (Note that most of the old step 7 text reappears in the new step 10 below.) Replace step 8b with the following: "b. For each dot-dot component, if there is a preceding component and it is neither root nor dot-dot, then: i. If the preceding component does not refer (in the context of pathname resolution with symbolic links followed) to a directory, then the cd utility shall display an appropriate error message and no further steps shall be taken. ii. The preceding component, all slashes separating the preceding component from dot-dot, dot-dot and all slashes separating dot-dot from the following component (if any) shall be deleted." Insert a new step 9: "9. If curpath is longer than {PATH_MAX} bytes (including the terminating null) and the directory operand was not longer than {PATH_MAX} bytes (including the terminating null), then curpath shall be converted from an absolute pathname to an equivalent relative pathname if possible. This conversion shall always be considered possible if the value of PWD, with a trailing slash added if it does not already have one, is an initial substring of curpath. Whether or not it is considered possible under other circumstances is unspecified. Implementations may also apply this conversion if curpath is not longer than {PATH_MAX} bytes or the directory operand was longer than {PATH_MAX} bytes." Replace the old step 9 with the following: "10. The cd utility shall then perform actions equivalent to the chdir() function called with curpath as the path argument. If these actions fail for any reason, the cd utility shall display an appropriate error message and the remainder of this step shall not be executed. If the -P option is not in effect, the PWD environment variable shall be set to the value that curpath had on entry to step 9 (i.e. before conversion to a relative pathname). If the -P option is in effect, the PWD environment variable shall be set to an absolute pathname for the current working directory and shall not contain filename components that, in the context of pathname resolution, refer to a file of type symbolic link. If there is insufficient permission on the new directory, or on any parent of that directory, to determine the current working directory, the value of the PWD environment variable is unspecified." ______________________________________________________________________________ ______________________________________________________________________________ Page: 226-227 Line: 8859-8887 Section: cd Problem: Defect code : 1. Error In SUSv3 there was a major revision of the description of the cd utility in order to specify how symbolic links are handled. Defects in some of the steps of the new description have been identified during discussions on the Austin Group reflector. Firstly, if the CDPATH search is either not done or fails then the steps always end up converting a relative pathname to an absolute pathname before it is passed to chdir(), which leads to two problems when the cd operand is a relative pathname: * The standard apparently requires cd to fail (because chdir() would produce an ENAMETOOLONG error) under circumstances where existing practice is to convert back to a relative pathname in order to avoid the ENAMETOOLONG error. The description should be amended to specify this conversion back to a relative pathname. * If PWD does not refer to the current directory (e.g. because another process renamed one of the directories within PWD) then changing to the absolute pathname "$PWD/cd_operand" would fail (or change to the wrong directory) whereas if the shell just called chdir(cd_operand) it would work correctly. This is more of an issue when the -P option is in effect, since cd's logical directory handling is fundamentally dependent on PWD anyway. The description should be amended so that, when the CDPATH search is either not done or fails, a relative pathname used with "cd -P" is passed to chdir() "as is". (Note that this would not prevent implementations from converting to an absolute pathname and back again internally.) Secondly, the description of dot-dot removal does not match existing practice, in that it does not include a check that the component preceding the dot-dot refers (with symbolic links followed) to a directory. Thirdly, if the CDPATH search succeeds and the path used from CDPATH is a relative path, and the -P option is not in effect, then PWD ends up being set to a relative path. Action: Replace step 6 with the following: "6. If the -P option is in effect, set curpath to the directory operand. Otherwise, set curpath to the string formed by the concatenation of the value of PWD, a slash character, and the operand." Replace step 7 with the following: "7. If the -P option is in effect, proceed to step 10. If curpath does not begin with a slash character, set curpath to the string formed by the concatenation of the value of PWD, a slash character, and the operand." (Note that most of the old step 7 text reappears in the new step 10 below.) Replace step 8b with the following: "b. For each dot-dot component, if there is a preceding component and it is neither root nor dot-dot, then: i. If the preceding component does not refer (in the context of pathname resolution with symbolic links followed) to a directory, then the cd utility shall display an appropriate error message and no further steps shall be taken. ii. The preceding component, all slashes separating the preceding component from dot-dot, dot-dot and all slashes separating dot-dot from the following component (if any) shall be deleted." Insert a new step 9: "9. If curpath is longer than {PATH_MAX} bytes (including the terminating null) and the directory operand was not longer than {PATH_MAX} bytes (including the terminating null), then curpath shall be converted from an absolute pathname to an equivalent relative pathname if possible. This conversion shall always be considered possible if the value of PWD, with a trailing slash added if it does not already have one, is an initial substring of curpath. Whether or not it is considered possible under other circumstances is unspecified. Implementations may also apply this conversion if curpath is not longer than {PATH_MAX} bytes or the directory operand was longer than {PATH_MAX} bytes." Replace the old step 9 with the following: "10. The cd utility shall then perform actions equivalent to the chdir() function called with curpath as the path argument. If these actions fail for any reason, the cd utility shall display an appropriate error message and the remainder of this step shall not be executed. If the -P option is not in effect, the PWD environment variable shall be set to the value that curpath had on entry to step 9 (i.e. before conversion to a relative pathname). If the -P option is in effect, the PWD environment variable shall be set to an absolute pathname for the current working directory and shall not contain filename components that, in the context of pathname resolution, refer to a file of type symbolic link. If there is insufficient permission on the new directory, or on any parent of that directory, to determine the current working directory, the value of the PWD environment variable is unspecified." _____________________________________________________________________________ COMMENT Enhancement Request Number 25 jonhitchcock:hotmail.com zcat (rdvk# 6) {jjh105} Thu, 8 Jul 2004 12:38:39 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Place in SD/5 to be considered for the next revision. _____________________________________________________________________________ Page: 0 Line: 10297 Section: compress, Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The portable use of compress, uncompress and zcat appears to be limited because the standard allows for systems that do not support adaptive Lempel-Ziv coding. The last of the LZW patents listed at www.unisys.com/about__unisys/lzw exipred yesterday, so there is little reason for compression not to be implemented on systems that support the XSI option. Also, the specification says that the interchange of compressed files between implementations is not required. But to my knowledge, in practice the compressed files are portable. Action: Simplify the standard at the next revision by requiring systems that support the XSI option to implement compression using the commonly-used format. This would obviously need a difinition of the format. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 jonhitchcock:hotmail.com Defect in XCU uncompress (rdvk# 5) {jjh104} Thu, 8 Jul 2004 12:37:55 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) Go with part 1 and describe the deviation (the utility name has 10 letters) _____________________________________________________________________________ Page: 0 Line: 36865 Section: uncompress Problem: Edition of Specification (Year): 2004 Defect code : 1. Error An implementation of uncompress is required to conform to the Utility Syntax Guidelines, but it is impossible to conform to Guideline 1 (utility names should be between two and nine characters). Action: Describe this as a deviation from the guidelines in the OPTIONS section. OR Change the guidelines to allow longer names. _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 eggert:cs.ucla.edu Defect in XCU ln (rdvk# 3) {20040624a} Thu, 24 Jun 2004 21:07:33 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) Add to the rationale, new para before line 21247 The Consequence of Errors section does not require "ln -f a b" to remove "b" if a subsequent link operation would fail. _____________________________________________________________________________ Page: 549 Line: 21190 Section: ln Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX currently requires "ln -f a b" to remove "b" even if the underlying link() function fails. It should not require this. That is POSIX should allow implementations where "ln -f a b" does not remove "b" upon failure. Here are some examples of the problem. * Suppose /a/f and /b/f are two files on different file systems and the implementation does not support links between file systems. POSIX currently requires the command "ln -f /a/f /b/f" to remove /b/f and then fail. * Suppose d1/d is a directory, d2/d is a file, and the process does not have appropriate privileges. POSIX currently requires the command "ln d1/d d2" to remove d2/d and then fail. * Suppose a_very_long_name is too long for the current file system and the regular file f exists. POSIX currently requires "ln -s a_very_long_name f" to remove f and then fail. * Suppose a does not exist but b does. Then POSIX requires "ln -f a b" to remove b. In all these cases, POSIX should allow "ln" to fail without removing the target. (Ideally, POSIX should require "ln" to fail without removing its target, but such a requirement would invalidate many existing implementations so I'm not proposing it here.) Action: Insert the following text at the start of step (1b) in XCU page 549 line 21190. (This step may be omitted unless the actions described in steps (2) through (4) would fail with errno set to EEXIST.) Insert the following text in the ln rationale, after XCU page 551 line 21279: Earlier versions of this standard required "ln -f a b" to remove b even if the underlying link() function failed. This behavior is no longer required: "ln -f a b" is now allowed to fail without removing b. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 28 eggert:cs.ucla.edu Defect in XCU rm (rdvk# 4) {20040703a} Sat, 3 Jul 2004 17:26:40 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_34 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 826 Line: 32097 Section: rm Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX currently seems to require that "rm ." must output a diagnostic and then exit with status zero. This is due to a glitch in the EXIT STATUS section of the specification for "rm". There is a similar problem with "rm /". For more details about the problem, please see the second half of Walter Briscoe's email message . Action: Change the following text in lines 32097-32098 from: 0 All of the named directory entries for which rm performed actions equivalent to the rmdir() or unlink() functions were removed. to: 0 Each directory entry was successfully removed, unless its removal was canceled by a non-affirmative response to a prompt for confirmation. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 29 tjr:freebsd.org Defect in XCU tr (rdvk# 1) {tjr4} Wed, 30 Jun 2004 08:58:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Reject , the description of \octal sequences on p928 line 35976-35981 specifies that octal escapes can be used to generate multibyte characters, so this proposed change is not correct. _____________________________________________________________________________ Page: 929 Line: 36042 Section: tr Problem: Edition of Specification (Year): 2004 Defect code : 1. Error XCU lines 36042-36043 state: If the -c option is specified, the complement of the values specified by string1 shall be placed in the array in ascending order by binary value. XCU lines 36051-36052 state: When the -c option is specified with -d, all values except those specified by string1 shall be deleted. The contents of string2 shall be ignored, unless the -s option is also specified. It is clear that "values" here is intended to refer to byte values when the current locale does contain multibyte characters, but the wording is ambiguous in the context of locales with multibyte characters. Action: Consider changing the wording @ 36051-36052 to: If the -c option is specified: - if the current locale does not contain multibyte characters, the complement of the byte values specified by string1 shall be placed in the array in ascending order by binary value - otherwise, the -c option shall be equivalent to the -C option. (I am still not entirely satisfied with this.) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 30 tjr:freebsd.org Defect in XCU tr (rdvk# 2) {tjr3} Tue, 29 Jun 2004 08:16:01 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 932 Line: 36139 Section: tr Problem: Edition of Specification (Year): 2004 Defect code : 1. Error XCU lines 36139-36143 state: The ISO POSIX-2:1993 standard had a -c option that behaved similarly to the -C option, but did not supply functionality equivalent to the -c option specified in IEEE Std 1003.1-2001. This meant that historical practice of being able to specify tr -d\200-\377 (which would delete all bytes with the top bit set) would have no effect because, in the C locale, bytes with the values octal 200 to octal 377 are not characters. The example given (tr -d \200-\377) does not make sense in the context it is used in since it does not use either the -c or -C option. (It also looks like a space is missing between -d and the following argument.) Action: Consider changing the example to tr -cd \000-\177 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 31 alex.neyman:auriga.ru Defect in XCU cp (rdvk# 7) {0} Wed, 30 Jun 2004 14:35:15 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) 1. The Page and Line numbers referenced (relative to draft 7) should be changed as follows (all using the 2004 edition as a reference): Page: 2470 should be changed to Page: 269 Line: 10391 should be changed to Line: 10511 2. The references to lines 10316-10317 and lines 10391-10392 in the Problem statement should be changed to page 267, lines 10433-10434 and page 269, lines 10511-10512 respectively. 3. The submitter (alex.neyman:auriga.ru) states that he has no access to more recent versions of the standard [than draft 7], but says the text appears in SUSv3. We need to let Mr. Neyman know that SUSv3 is the same standard as IEEE Std 1003.1 and the ISO/IEC 9945 family of standards. 4. P267-268, L10430-10446 (including the text Mr. Neyman referenced) specify how source_file is to be interpreted when it refers to a symbolic link. The references to source_file on P268-269, L10447-10514, therefore will treat source_file as a symbolic link only if the -H option is in effect and source_file was specified as a source_file operand on the command line; or if the -P option is in effect. 5. Therefore, I believe the standard is correct as it stands. It was agreed that the following editorial change could provide more clarification and remove confusion. Change 10511 to If source_file is a file of type symbolic link, and the options require the symbolic link itself to be acted on, the pathname... _____________________________________________________________________________ Page: 2470 Line: 10391 Section: cp Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The lines 10316-10317 state that it is unspecified which of -H, -L and -P options is the default. However, later at the lines 10391-10392 the description states that "if source_file is a file of type symbolic link, the pathname contained in dest_file shall be the same as the pathname contained in source_file". This phrase implies that the dest_file will be created as a symbolic link, which is not the case for -H or -L options. (the line numbers are against the draft 7 of the 2001 edition, I have no access to more recent versions of the standard. However, since the same text is present in the SUSv3, I assume the issue is still actual). Action: Change wording to: "If source_file is a file of type symbolic link, the action depends on which of -H, -L and -P options is in effect. If -H option is in effect and source_file was specified in as an operand, the action shall be taken based on the type of the file source_file refers to. If -L option is in effect, the action shall be taken based on the type of the file source_file refers to. Otherwise, the pathname contained in dest_file shall be the same as the pathname contained in source_file." _____________________________________________________________________________ OBJECTION Enhancement Request Number 32 eggert:cs.ucla.edu Defect in XCU nice (rdvk# 2) {20040725b} Mon, 26 Jul 2004 06:11:00 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 664 Line: 25710 Section: nice Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The POSIX specification for the "nice" command is confused about the sign of nice values in a few places. Common practice is for "nice command" to run a command with a larger nice value, typically 10 greater than before. However, the specification for the "nice" command says just the opposite. Action: Replace the following text in page 664 lines 25710-25712: With no options and only if the user has appropriate privileges, the executed utility shall be run with a nice value that is some implementation-defined quantity less than or equal to the nice value of the current process. with: With no options, the executed utility shall be run with a nice value that is some implementation-defined quantity greater than or equal to the nice value of the current process. In page 665 line 25770, change "the default lower nice value" to "the default higher-or-equal nice value". In page 665 line 25772, change "lower nice value" to "higher nice value". In page 666 line 25808, change "lower the nice value" to "raise the nice value". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 33 eggert:cs.ucla.edu Defect in XCU nice (rdvk# 3) {20040725c} Mon, 26 Jul 2004 06:53:43 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 666 Line: 25800 Section: nice Problem: Edition of Specification (Year): 2004 Defect code : 1. Error For a command like "nice -n -1 utility" (when the user lacks appropriate privileges) the rationale says that neither the System V nor the 4.3 BSD behavior was considered clearly superior, so the behavior was left unspecified. However, the standard does not allow the 4.3 BSD behavior: it requires "nice -n -1 utility" to run the utility, whereas 4.3 BSD does not run the utility. Action: Replace the following text in page 666 line 25800 Neither was considered clearly superior, so the behavior was left unspecified. with: The standard specifies the System V behavior together with an optional BSD-style "permission denied" message. _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 eggert:cs.ucla.edu Defect in XCU rm (rdvk# 1) {20040725a} Mon, 26 Jul 2004 05:11:12 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 34(->interps track) AI-091 It is agreed this is a defect in the EXIT STATUS 0 wording and that this should be forwarded down the interpretations track. _____________________________________________________________________________ Page: 826 Line: 32097 Section: rm Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX currently requires that "rm ." must output a diagnostic and then exit with status zero, contrary to common practice. The EXIT STATUS section of the specification for "rm" says that the exit status must be zero if all rmdir() or unlink() calls succeeded, but the algorithm specified on page 824 makes it clear that "rm ." never invokes rmdir() or unlink(), so "rm ." must therefore exit with status zero. There is a similar problem with "rm /", "rm nonexistentfile", etc. Action: Change the following text in lines 32097-32098 from: 0 All of the named directory entries for which rm performed actions equivalent to the rmdir() or unlink() functions were removed. to: 0 Each directory entry was successfully removed, unless its removal was canceled by a non-affirmative response to a prompt for confirmation. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 35 eggert:cs.ucla.edu Defect in XCU sort (rdvk# 35) {20040730a} Sat, 31 Jul 2004 01:03:40 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 35(->interps track) AI-092 In the example given sort -o - the final "-" is an option argument; not an operand. The description of the -o option says that the output option argument is the name of an output file to be used instead of standard output, so a file named "-" shall be created. No change is necessary to the standard. Notes to working group A related issue was raised on Utility Syntax Guideline 13 and general applicability to other utilities. For the current standard, the standard is unclear. This means thatportable applications can *only* depend on one or other of the behaviors (i.e. - is stdin, stdout or a filename) if the standard explicitly describes it. In the next revision we need to clarify guideline 13 and explicitly state that for any utility that handles filename operands how "-" should be treated. Possible words for a future revision: At Page XBD 204, line 7233, replace "Guideline 13: For utilities that use operands to represent files to be opened for either reading or writing, the - operand should be used only to mean standard input (or standard output when it is clear from context that an output file is being specified)." with "Guideline 13: For utilities that use operands to represent files to be opened for either reading or writing, the - operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named -." After line 7240, add "Where a utility described in the Shell and Utilities volume of IEEE Std 1003.1-2001 as conforming to these guidelines accepts the operand - to mean standard input or output, this usage shall be explained in the OPERANDS section." _____________________________________________________________________________ Page: 871 Line: 33829 Section: sort Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Does the command "sort -o -" create a file named "-", or does it write to standard output? The specification for "sort" says that it conforms to the Utility Syntax Guidelines, and Guideline 13 says For utilities that use operands to represent files to be opened for either reading or writing, the '-' operand should be used only to mean standard input (or standard output when it is clear from context that an output file is being specified). Here, "-" is an operand, so apparently "sort -o -" should write to standard output. This is what GNU coreutils 5.2.1 "sort" does. However, I just checked Solaris 9 "sort" (both /usr/bin/sort and /usr/xpg4/bin/sort) and OpenBSD 3.4 "sort", and they both create an output file "-". It sounds like the standard is not clear enough here, perhaps because of the indirect reference to the Guidelines. Action: Append the following text after page 871 line 33829: If "output" is "-", sort shall write to standard output. _____________________________________________________________________________ COMMENT Enhancement Request Number 36 flaw:rhid.com Defect in XCU test (rdvk# 36) {0} Fri, 10 Sep 2004 20:01:38 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-038 This is an interpretation. The standard does not speak to this issue of what constitutes a number in XCU's test(1) and shell arithmetic expansion, and as such no conformance distinction can be made between alternative implementations based on this. In the event that the primary operand to the primary operators (-gt, -ge, -lt, -le, -eq, -ne) are not integers, implementations are free to provide extensions that would recognize those values or to treat them as errors. Point 6 in the Utility Argument Syntax portion of the Utility Conventions (subclause 12.1 in the Base Definitions volume of the standard) states that unless otherwise specified, operands that are to be treated as numeric values are to be interpreted as decimal integers. Since the test utility doesn't specify different behavior, the n1 and n2 operands to the -eq, -ne, -gt, -ge, -lt, and -le binary primaries are required to be treated as decimal integers. The description of Arithmetic Expansion (subclause 2.6.4 in the Shell and Utilities volume of the standard), however, explicitly requires that decimal, octal, and hexadecimal constants have to be recognized when performing arithmetic expansions. _____________________________________________________________________________ Page: 0 Line: 0 Section: test Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required test asdf -ge 0 $((asdf + 1)) What constitutes a number in both of these cases, test(1) and shell arithmetic expansion, does not appear to be specified. This was brought to my attention when I noticed the differing implementations. Firstly, zsh, which will return 0 on the first command, and the arithmetic expansion will expand to 1. As opposed to FreeBSD's--and likely BSDs in general--/bin/sh, which will cause an error to be echoed to stderr and a non-zero result in both cases. At first I contacted the zsh developers, as I assumed this was specified behaviour after checking /bin/sh's and bash's test implementation. This was not the case, and Dan Nelson on the zsh work list responded with examples of other shells that behaved the same way as zsh. (A couple notable examples being GNU's test and pdksh). He also said that he believed this fell into undefined behaviour, and, therefore, zsh was not incorrect. I then contacted the FreeBSD-standards list to try to confirm that this was undefined behaviour. Those who responded believed that this was undefined, and thought that I should at least bring this question to the austin group mailing list. In case you are interested in the threads that led up to this clarification request, here are their URIs: http://www.zsh.org/mla/workers/2004/msg00937.html http://lists.freebsd.org/pipermail/freebsd-standards/2004-September/000673.html Action: Clarification of what constitutes a number in XCU's test(1) and shell arithmetic expansion, and perhaps other related locations. Specifically, a given number should be considered valid if strtol(str, &end, 0) accepts str as a valid number. This would allow the usage of hexadecimal and octal numbers in test and arithmetic expansion, which is likely a feature that would be welcomed by all. (See http://www.opengroup.org/onlinepubs/000095399/functions/strtol.html) In the case of an invalid number, the utility should throw an error and return non-zero, perhaps a standard error code for an invalid numbers should be allocated, if one is not already. An invalid number in arithmetic expansion should cause an error to be thrown before the command is executed, and result in a non-zero value, and perhaps a different value than the former so that a distinction can be made between where the invalid number error occurred--before or during the execution of a command. An important note to make is the contrast between test(1) and expr(1), where expr defines a valid integer, and test does not. From http://www.opengroup.org/onlinepubs/000095399/utilities/expr.html: integer - An argument consisting only of an (optional) unary minus followed by digits. I also recommend that expr(1) be updated to allow hexadecimal and octal numbers in the format that strtol(str, &end, 0) accepts, so as to be consistent with the newly defined behaviour in test(1) and shell arithmetic expansion. (Props to Garrett Wollman on freebsd-standards for the notice of this contrast!) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 37 eggert:cs.ucla.edu Defect in XCU od (rdvk# 37) {20040905c} Mon, 6 Sep 2004 02:44:51 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 679 Line: 26312 Section: od Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The "od" OPERANDS section specifies that an operand is to be treated as an offset if none of the -A, -j, -N, or -t options is specified and if some other conditions hold. But looking at the synopsis and the other XSI shading, it's clear that the -v option was intended to be in that list of options. Action: In XCU page 679 line 26312, replace: ... none of the -A, -j, -N, or -t options is specified, ... with: ... none of the -A, -j, -N, -t, or -v options is specified, ... _____________________________________________________________________________ EDITORIAL Enhancement Request Number 38 bjh21:cam.ac.uk Defect in XCU 2.9.3.1 (rdvk# 38) {bjh21-20040927} Mon, 27 Sep 2004 13:11:56 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 51 Line: 2068 Section: 2.9.3.1 Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The second reason why a process ID can become unknown is ungrammatical. It reads: "This process ID shall remain known until: [...] 2. Another asychronous list invoked before "$!" (corresponding to the previous asynchronous list) is expanded in the current execution environment." ANSI/IEEE Std 1003.2-1992 (section 3.9.3.1 line 863) had the following text: "This process ID shall remain known until [...] -- Another asynchronous list is invoked before $! (corresponding to the previous asynchronous list) is expanded in the current execution environment." Action: Insert "is" between "list" and "invoked". _____________________________________________________________________________ OBJECTION Enhancement Request Number 39 eggert:cs.ucla.edu Defect in XCU pathchk (rdvk# 39) {20040924a} Sat, 25 Sep 2004 06:05:26 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-039 This is being handled as an interpretation request. Interpretation response: The standards states the requirements for portable filenames and the behavior for the pathchk utility, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: It is believed that the intent of the former POSIX.1-1990 and POSIX.2-1992 standards was that the constraint on use of the hyphen character as the first character of a portable filename is a constraint on application behavior and not on implementations, since applications might not work as expected when such a filename is passed as a command line argument. Notes to the Editor for a future revision(not part of the interpretation) XBD Chapter 3 Definitions 3.170 Filename Portability is not a definition, it is advice on why filenames should be constructed from the portable filename character set, and should be moved elsewhere (see below) Remove Definition 3.170 Change XBD Chapter 4 Global Concepts 4.6 Filenames From: "4.6 Filenames For a filename to be portable across implementations conforming to IEEE Std 1003.1-2001, it shall consist only of the portable filename character set as defined in Portable Filename Character Set. The hyphen character shall not be used as the first character of a portable filename. Uppercase and lowercase letters shall retain their unique identities between conforming implementations. In the case of a portable pathname, the slash character may also be used." To: "4.6 Filenames Uppercase and lowercase letters shall retain their unique identities between conforming implementations. " Insert new General Concept into XBD after 4.6 Filenames and before 4.7 File Times Update" "4.X Filename Portability For a filename to be portable across implementations conforming to IEEE Std 1003.1-2001, it shall consist only of the portable filename character set as defined in Portable Filename Character Set. Portable filenames shall not have the hyphen character as the first character since this may cause problems when filenames are passed as command line arguments." Insert new RATIONALE into XRAT before A.4.7 File Times Update "A.4.X Filenames should be constructed from the portable filename character set because the use of other characters can be confusing or ambiguous in certain contexts. (For example, the use of a colon ( ':' ) in a pathname could cause ambiguity if that pathname were included in a PATH definition.) [The constraint on use of the hyphen character as the first character of a portable filename is a constraint on application behavior and not on implementations, since applications might not work as expected when such a filename is passed as a command line argument.]" (wording in [] suggested by AJ after the meeting) For pathchk it was agreed that we need to address the hyphen character issue, and that pathchk must be able to issue a diagnostic when it encounters it. We discussed whether the new behavior should be added to the -p option rather than a new -P option. If the new behavior was added to -p there were concerns raised about how to maintain conformance to the current and previous standards. The approach of adding a new -P option allows backwards compatibility, and yet allows existing implementations to implement the future direction. In XCU pathchk (2004 ed , p696) Insert at the end of the OPTIONS section in the pathck utility "-P Write a diagnostic for each pathname operand that contains a component whose first character is the hyphen character" In the pathchk SYNOPSIS section change From : "pathchk [-p] pathname...." To: "pathchk [-p] [-P] pathname...." In the pathchk DESCRIPTION section Change the last sentence of the first paragraph From: "More extensive portability checks are provided by the -p option." To: "More extensive portability checks are provided by the -p and -P options." Add to the pathchk APPLICATION USAGE "To verify that a pathname meets the requirements of filename portability, applications should use both -p and -P options together." Add to the pathckh RATIONALE "For historical purposes -p does not check for the use of the hyphen character as the first character in a component of the pathname." _____________________________________________________________________________ Page: 696 Line: 26993 Section: pathchk Problem: Edition of Specification (Year): 2004 Defect code : 1. Error By intent (as shown in XCU page 698 lines 27053-27054), pathchk -p should succed only on pathnames that can be moved to any conforming system. However, the formal description neglects one case: file name components that begin with "-". Under the current strict reading of the standard, for example, the command "pathchk -p ./-" must succeed even though "./-" is not a portable pathname (see XBD section 4.6 page 98 line 3071). Action: After XCU page 696 line 26993, add a new bullet: * Contains any component whose first character is a hyphen. _____________________________________________________________________________ COMMENT Enhancement Request Number 40 eggert:cs.ucla.edu Defect in XCU c99 (rdvk# 40) {20040928e} Wed, 29 Sep 2004 00:54:25 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-040 This is an editorial update In c99 APPLICATION USAGE (XCU page 217 line 8538), change: -l options. to: -l operands, because the standard requires options to appear before operands. The standard allows the first operand to be an -l operand, so conforming implementations accept usages like "c99 -l y foo.c". _____________________________________________________________________________ Page: 217 Line: 8538 Section: c99 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required This is a question about how greedy option-parsing is required (or allowed) to be. Consider the command c99 -l y foo.c which uses the Yacc library's definition of "main". Here, "-l y" is an operand, and the c99 description and the utility syntax guidelines are all being followed. The question is whether an implementation is required to accept this form, or can it reject the "-l" as an unknown option, so that a portable application must use "c99 -- -l y foo.c" instead? XCU page 211 lines 8286-8288 say, "The c99 utility shall conform to the ... Utility Syntax Guidelines, except that: * The -l library operands have the format of options, ...". This suggests that one cannot resolve the question of "c99 -l y foo.c" merely by appealing to the guidelines, since this part of c99 is explicitly an exception to the guidlines. Common practice is for implementations to accept "c99 -l y foo.c" (or, at least "c89 -l y foo.c", which is what I checked on Solaris 9 with Forte Developer 7 C 5.4). Also, one minor editorial bug (independent of the main question): in line 8538 the standard says "-l options" where "-l operands" was clearly intended. Action: In c99 APPLICATION USAGE (XCU page 217 line 8538), change: -l options. to: -l operands, because the standard requires options to appear before operands. The standard allows the first operand to be an -l operand, so conforming implementations must accept usages like "c99 -l y foo.c". _____________________________________________________________________________ COMMENT Enhancement Request Number 41 eggert:cs.ucla.edu sh (rdvk# 41) {20040928d} Wed, 29 Sep 2004 00:50:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 41(->interps track) AI-093 The standard is clear, the + character has no meaning as the first character of an operand for the pr utility , it is only allowed as the +page option case, so implementations are allowed to treat +x as an invalid page number or an operand. Portable applications should use pr -- +x to avoid this problem. For sh, no change is needed. See the APPLICATION USAGE section. Notes to editor for a future revision: Add to APPLICATION USAGE (wording based on the APP USAGE in sh) A conforming application must protect its first operand, if it starts with a plus sign, by preceding it with the "--" argument that denotes the end of the options. For example pr +x could be interpreted as an invalid page number or a file operand. _____________________________________________________________________________ Page: 739 Line: 28780 Section: pr, Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The standard is unclear whether the utilities "pr" and "sh" must accept first operands that begin with "+". For example, must an implementation accept this command: pr +file as specifying an operand pathname "+file", or is the implementation allowed to reject "+file" as an invalid option, so that a portable application must use "pr -- +file" instead? Similarly, must an implementation accept this command: sh ++ as specifying an operand command_file "++", or is it allowed to reject the "++" as an invalid option, so that a portable application must use "sh -- ++" instead? Common practice is to reject such usages, which suggests that conforming applications should be cautious, and the standard should not be strict about what behaviors are required of implementations. Please note that this problem description is limited to the first operand. A later Aardvark will take up the issue of operands after the first operand. Action: Add the following text to pr OPERANDS (after XCU page 739 line 28780): The first operand, if any, shall not begin with "+" unless the operand is preceded by a "--" delimiter. Add the following text to sh OPERANDS (after XCU page 852 line 33051): The first operand, if any, shall not begin with "+" unless the operand is preceded by a "--" delimiter. _____________________________________________________________________________ OBJECTION Enhancement Request Number 42 ebb9:byu.net Defect in XCU cp (rdvk# 42) {ebb.cp} Wed, 6 Oct 2004 14:13:43 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) (it was noted that if the proposed wording is not acceptable then ln should be changed also) _____________________________________________________________________________ Page: 0 Line: 0 Section: cp Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The current wording of http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html, in paragraph 6 of the Description, requires that when using the -R option, "It shall be an error if target does not exist and more than two operands are specified, or if target exists and is a file of a type defined by the System Interfaces volume of IEEE Std 1003.1-2001, but is not a file of type directory." A strict interpretation of this wording prohibits symbolic links to directories as being the target of cp -R, because definition 3.163 defines "symbolic link" and "directory" as two distinct file types. However, this conflicts with current implementations of cp, which treat a symlink to a directory as the target argument the same as a directory as the target: $ rm -Rf a b c $ mkdir a $ ln -s a b $ cp -RP b c # invocation 1 $ cp -RP b c # invocation 2 Invocation 1 sees that c does not exist, and b is a symlink, so paragraph 5 applies to create the destination name ./c, then step 4.b applies and symlink ./c is created pointing to directory a. Invocation 2 sees that c exists, and is a file of type symbolic link, so under the current wording, it should print a diagnostic and return failure with no further action. But many implementations treat c as a directory, apply paragraph 4 to create the destination name ./c/b, then step 4.b to create the symbolic link ./c/b (also visible by the name ./a/b) as a dangling reference to a (since no file by the name a exists in directory a). The wording for ln does not have this problem: http://www.opengroup.org/onlinepubs/009695399/utilities/ln.html Description paragraph 4 states simply "The second synopsis form shall be assumed when the final operand names an existing directory." This can be interpreted to include symbolic links to directories as well as actual directories as the target of a symbolic link, since both file types name a directory. Action: In the Description for cp, change the wordings of paragraphs 2, 4, and 6 as follows: ... It shall be an error if any source_file is a file of type directory, if target does not exist, or if target does not name a directory. ... ... - If target exists and names an existing directory, the name of the corresponding destination path ... ... It shall be an error if target does not exist and more than two operands are specified, or if target exists and does not name a directory. _____________________________________________________________________________ OBJECTION Enhancement Request Number 43 eggert:cs.ucla.edu Defect in XCU pathchk DESCRIPTION (rdvk# 43) {20041008a} Fri, 8 Oct 2004 22:22:11 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 43 (->interps)AI-094 This is being handled as an interpretation request. The standard does not speak to the issue of handling empty pathnames, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The usage pathchk -p -- -x is not required to fail since the "-p" has specific defined tests that shall be followed , the characters -x are valid in a component of pathname. The standard does not address the null pathname. It was felt that for the same reasons as expressed in XCU ERN 39 that this be added to -P rather than -p. Supplement XCU ERN 39 with the following revisions In XCU pathchk (2004 ed , p696) Insert at the end of the OPTIONS section in the pathck utility "-P Write a diagnostic for each pathname operand that: - contains a component whose first character is the hyphen character - is empty " Add to the pathckh RATIONALE "For historical purposes -p does not check for the use of the hyphen character as the first character in a component of the pathname, or for an empty pathname operand." _____________________________________________________________________________ Page: 696 Line: 26977 Section: pathchk Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission In reviewing the pathchk -P option proposed the XCU ERN 39 notes to the editor (see the minutes of the Oct 7 2004 Teleconference), I discovered another problem with pathchk: it is not required to reject empty pathnames. For example, the command "pathchk ''" is not required to fail, and on the implementations that I have easy access to (Solaris 9, GNU/Linux) it does not fail. This problem is somewhat independent of the -p option, as the empty pathname is not only unportable: it guaranteed to be invalid. As a result of this problem, a portable application cannot reliably use the command 'pathchk -- "$f"' to check the validity of the pathname $f, because $f might be empty. This raises another question, related to both the empty-filename problem and the leading-hyphen problem. Is an implementation of "pathchk -p" allowed to reject filenames with leading hyphens? The XCU ERN 39 interpretation says that the standard does not require "pathchk -p -- -x" to fail, but on the other hand the standard does not clearly require that the command must succeed either. That is, the standard lists several tests that the pathname operand must pass, but it does not say whether the list is exhaustive. This second question also applies to empty pathnames. Is a conforming implementation of "pathchk" allowed to reject empty pathnames? I.e., can "pathchk ''" fail (even though it is not required to fail)? If the answer to the second question is "yes", that suggests that there is no need for the proposed -P option. If the current standard allows commands like "pathchk ''" and "pathchk -p -- -x" to fail, then a revision to the standard could require these commands to fail without affecting portable applications. It would be a win if we could avoid the need for a new, somewhat-confusing option like -P. Action: Proposed interpretation response: The standard is clear that "pathchk ''" is not required to fail, and conforming applications must not assume that it fails. However, concerns have been raised about this which are being referred to the sponsor. The standard is not clear whether commands like "pathchk -p ''", and "pathchk -p ''" are allowed to fail in conforming implementations. Nor is it clear whether commands like "pathchk -p -- -x" are allowed to fail. Concerns have been raised about this which are being referred to the sponsor. Notes to the Editor for a future revision (not part of the interpretation): After XCU page 696 line 26977 (pathchk DESCRIPTION), add a new bullet: * Is empty. After XCU page 696 line 26993 (pathchk OPTIONS, under -p), add two new bullets: * Contains any component whose first character is a hyphen. * Is empty. After XCU page 699 line 27124 (pathchk RATIONALE), add: Previous editions of this standard did not require pathchk to fail when given an empty pathname, or when given the -p option and a pathname containing a component with a leading hyphen. Such pathnames are invalid (or in the case of -p, are not portable), so the current edition requires pathchk to fail in these cases as well. _____________________________________________________________________________ OBJECTION Enhancement Request Number 44 gwc:opengroup.org Defect in XCU pr (rdvk# 44) [gwc pr -i] Tue, 5 Oct 2004 11:30:58 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 738 Line: 28742 Section: pr Problem: Defect code : 1. Error In PASC interpretation 1003.2-92 #151 a change to the description of the pr -i option was identified to make it match historical behaviour. This change appears to have been overlooked in the revision. The same interpretation also proposed a clarification regarding all-digit option arguments for -e and -i. This change could also be made if desired, although the current text seems quite clear to me. Action: On line 28742 change "replace multiple s with s wherever two or more" to "replace s with s wherever one or more". Consider appending the following to line 28746: "If the first character of the -i option-argument is a digit the entire option argument shall be assumed to be gap." and the following to line 28735: "If the first character of the -e option-argument is a digit the entire option argument shall be assumed to be gap." _____________________________________________________________________________ COMMENT Enhancement Request Number 45 eggert:cs.ucla.edu Defect in XCU touch (rdvk# 45) {20040928f} Fri, 1 Oct 2004 01:04:47 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) Add RATIONALE In previous editions of the standard, if at least two operands are specified, and the first operand is an eight- or ten-digit decimal integer, the first operand was assumed to be a date_time operand. This usage was removed in this edition of the standard since it had been marked obsolescent previously. _____________________________________________________________________________ Page: 923 Line: 35798 Section: touch Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required In previous editions of the standard, the command "touch 01010101 file" was required to be equivalent to "touch -t 01010101 file", as this was common historical practice. This usage was marked as obsolescent. In 2001 this obsolescent form was removed, so the same command is now required to be equivalent to "touch ./01010101 file", and an implementation therefore cannot conform to both the pre-2001 and the post-2001 standards simultaneously. This change appears to be intentional, as it is documented in XCU "touch" page 923 line 35798, but the resulting incompatibility is not explained clearly. Action: Add the following text after XCU "touch" page 923 line 35798: This means previous and current editions of the standard require incompatible behaviors. For example, "touch 01010101 file" was formerly equivalent to "touch -t 01010101 file" but is now equivalent to "touch ./01010101 file". Applications desiring portability to implementations conforming to previous editions of the standard must avoid this problematic usage. _____________________________________________________________________________ OBJECTION Enhancement Request Number 46 karen:apple.com UUX (rdvk# 46) {3844718} Tue, 19 Oct 2004 17:31:08 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is not a defect in the current standard which reflects existing known practise. It is agreed that this item should be placed into SD/5 for consideration of whether to move it into an option in the next revision. The review group noted that based on feedback to date there appears to still be use and there are freely available implementations In the revision UUCP has now been placed into the UUCP Utilities option _____________________________________________________________________________ Page: 0 Line: 0 Section: UUCP, Problem: Edition of Specification (Year): 2003 Defect code : 1. Error With the overwhelming adoption of TCP/IP and its associated SMTP, FTP and other higher-level protocols, the functionality provided by UUCP is essentially deprecated and was retired from our platform (to general acclaim) almost 2 years ago. We believe that the Internet has evolved past it and it should be removed from the specification. Action: The uucp suite of tools for UNIX-to-UNIX file copying should be removed from the specification. This includes uucp, uustat, and uux. _____________________________________________________________________________ OBJECTION Enhancement Request Number 47 gwc:opengroup.org Defect in XCU c99 (rdvk# 47) [gwc c99 -l operand] Fri, 22 Oct 2004 12:18:27 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 47(->interps)AI-095 This is an Interpretation The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Notes to the Editor for a future revision (not part of this interpretation): On line 8342 change: "An operand is either in the form of a pathname or the form -l library." to: "An operand is either in the form of a pathname or the form -llibrary, or is one of two consecutive operands of the form -l for the first and library for the second." On line 8354 change: "-l library (The letter ell.) Search the library named:" to: "-llibrary (A , the letter ell and a library name.) -l library (Two consecutive operands, the first being a and the letter ell; the second being a library name.) Search the library named:" Add a new para before 8356 p213: For the remainder of this description of the c99 utility, both of the forms -l library and -llibrary are referred to as as -l operand for brevity (even though the -l library form is actually two operands). After line 8359 add a new paragraph: "If the last operand is a -l with no library name, then the c99 utility shall write a diagnostic message to standard error and shall return a non-zero exit status." _____________________________________________________________________________ Page: 212 Line: 8342-8445 Section: c99 Problem: Defect code : 1. Error The c99 page states "An operand is either in the form of a pathname or the form -l library." This and other uses of the singular word operand imply that applications (and users) are required to pass "-l library" as a single operand, e.g. by quoting the space in the shell: $ c99 myfile.c -l\ m or $ c99 myfile.c '-l m' If an application were actually to do that on any system, the result would almost certainly be an error message indicating that the library "-l m" (or "lib m") does not exist. The text should be updated to make it clear that the -l and the library name are two consecutive operands. The behaviour when the last operand is -l (i.e. no library name is given) should be specified. Widespread existing practice (for c89, cc, etc.) is to pass a single operand, e.g. "-lm". This usage should also be specified. Action: The following are all the changes I have identified as being needed in the normative text on the c99 page. The editors may wish to make similar changes in the non-normative text. On line 8342 change: "An operand is either in the form of a pathname or the form -l library." to: "An operand is either in the form of a pathname or the form -llibrary, or is one of two consecutive operands of the form -l for the first and library for the second." On line 8354 change: "-l library (The letter ell.) Search the library named:" to: "-llibrary (A , the letter ell and a library name.) -l library (Two consecutive operands, the first being a and the letter ell; the second being a library name.) Search the library named:" [add new para before 8356 l213 For the remainder of this description of the c99 utility, both of the forms -l library and -llibrary are referred to as as -l operand for brevity (even though the -l library form is actually two operands). ] On lines 8356-8357 change: "the placement of a -l operand is significant" to: "the placement of -llibrary and -l library operands is significant" After line 8359 add a new paragraph: "If the last operand is a -l with no library name, then the c99 utility shall write a diagnostic message to standard error and shall return a non-zero exit status." On line 8411 change: "The c99 utility shall recognize the following -l operands for standard libraries:" to: "The c99 utility shall recognize the following library operands, both in the form of a single operand -llibrary and in the form of two consecutive operands -l library, for standard libraries:" On lines 8412, 8419, 8421, 8423, 8426, 8429, 8434 and 8439 change: "This operand shall make visible" to: "Make visible" On lines 8422 and 8440 change: "through the -l c operand" to: "through -l c" On line 8425, 8427, 8433, 8435 and 8437 change: "in the absence of this operand" to: "in the absence of any operand or operands that specify it" On line 8436 change: "This operand makes visible" to: "Make visible" On line 8442 change: "the equivalent of a -l c operand to be passed to the link editor as the last -l operand" to: "the equivalent of -l c to be passed to the link editor as the last -llibrary operand or -l library operands" On line 8445 change: "The implementation may accept as -l operands names of objects that do not exist as regular files" to: "The implementation may accept as -llibrary or -l library operands names of objects that do not exist as regular files" _____________________________________________________________________________ OBJECTION Enhancement Request Number 48 gwc:opengroup.org Defect in XCU find (rdvk# 48) [gwc find -L dangling link] Fri, 12 Nov 2004 15:48:36 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) add the text "If the referenced file does not exist, the file information and type shall be for the link itself" to the description of the -L option _____________________________________________________________________________ Page: 452 Line: 17520 Section: find Problem: Defect code : 3. Clarification required It is not clear how find should behave when the -L option is used and a dangling symbolic link is encountered. The description of -L does not contain the following text which appears in the description of -H: "If the referenced file does not exist, the file information and type shall be for the link itself." The absence of this text would seem to imply that with -L, if the referenced file does not exist then find should treat it as an error. (I.e. if stat() fails find with -L should not try an lstat() to check whether it is a dangling symbolic link - it should just behave the same as if the file does not exist at all.) However, the rationale on the find page states: "Since the -L option resolves all symbolic links and the -type l primary is true for symbolic links that still exist after symbolic links have been resolved, the command: find -L . -type l prints a list of symbolic links reachable from the current directory that do not resolve to accessible files." This implies that the intention was for the treatment of dangling links with -L to be the same as with -H. Action: Either add the text "If the referenced file does not exist, the file information and type shall be for the link itself" to the description of the -L option, or correct the rationale. _____________________________________________________________________________ OBJECTION Enhancement Request Number 49 gwc:opengroup.org Defect in XCU 2.5.3 IFS (rdvk# 49) [gwc shell IFS unset] Tue, 21 Dec 2004 15:51:32 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 49(->interps)AI-096 This is an interpretation In the first case, the standard is ambiguous, second case, defect concerns being forwarded to the sponsor Replace the description of IFS with the following: (Input Field Separators.) A string treated as a list of characters that is used for field splitting and to split lines into fields with the read command. If IFS is not set, it shall behave as normal for an unset variable, except that field splitting by the shell and line splitting by the read command shall be performed as if the value of IFS is ; see Section 2.6.5 (on page 42). Implementations may ignore the value of IFS in the environment, or the absence of IFS from the environment, at the time the shell is invoked, in which case the shell shall set IFS to when it is invoked. _____________________________________________________________________________ Page: 35 Line: 1427-1432 Section: 2.5.3 Problem: Defect code : 1. Error The description of the IFS variable states: (Input Field Separators.) A string treated as a list of characters that is used for field splitting and to split lines into fields with the read command. If IFS is not set, the shell shall behave as if the value of IFS is , , and ; see Section 2.6.5 (on page 42). Implementations may ignore the value of IFS in the environment at the time the shell is invoked, treating IFS as if it were not set. There are two problems with this text. Firstly, the "shall behave as if" part needs to specify which aspects of the shell's behaviour it applies to. It is loosely implied by the context that it only applies to field splitting and the read command, but the text should made clear that only these aspects are affected, and not such things as the evaluation of ${IFS-unset} or the value of IFS reported by a plain "set" command. Secondly, the "treating IFS as if it were not set" part does not match existing practice, which is to set IFS to , not to unset it (nor even to leave it unset if it isn't set in the environment). Also, as an editorial comment, I think "" better represents the concatenation of those characters than does ", , and ". Action: Replace the description of IFS with the following: (Input Field Separators.) A string treated as a list of characters that is used for field splitting and to split lines into fields with the read command. If IFS is not set, field splitting by the shell and line splitting by the read command shall be performed as if the value of IFS is ; see Section 2.6.5 (on page 42). Other uses of IFS shall behave as normal for an unset variable, for example "${IFS-unset}" expands to "unset". Implementations may ignore the value of IFS in the environment, or the absence of IFS from the environment, at the time the shell is invoked, in which case the shell shall set IFS to when it is invoked. _____________________________________________________________________________ COMMENT Enhancement Request Number 50 gwc:opengroup.org Defect in XCU ls (rdvk# 50) [gwc ls -A] Sun, 16 Jan 2005 12:07:12 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) The reviewers agreed that this was a well formed proposal for a new addition to the standard. As it was proposing adding features to an existing interface the full criteria in Austin/112 need not apply. This item should be added to SD/5. It was noted that the final proposed change (to delete the rationale) should be handled differently, that is it should be noted that ls -A did not appear in earlier versions of this standard, but had been added due to widespread implementation. Take the changes proposed apart from the last one , which instead should be Change page 577 lines 22298-22299: from The BSD ls provides a -A option (like -a, but dot and dot-dot are not written out). The small difference from -a did not seem important enough to require both. To: Earlier versions of this standard did not describe the BSD -A option (like -a, but dot and dot-dot are not written out). It has been added due to widespread implementation. _____________________________________________________________________________ Page: 571 Line: 22019-22058 Section: ls Problem: Defect code : 2. Omission Many current implementations of ls support a -A option. I believe it would be a worthwhile addition in the next revision of the standard. It is supported by Solaris, HP-UX, Tru64, Unixware, the various BSD flavours, Linux and probably several others. The rationale on page 577 states "The BSD ls provides a -A option (like -a, but dot and dot-dot are not written out). The small difference from -a did not seem important enough to require both." I doubt whether BSD was the only implementation that provided ls -A at the time this was written (1992 or earlier). Even so, it would seem that support for it is more widespread now than it was then. I disagree that the difference from -a is not important enough to require -A. It is very useful in certain situations. For example, in a shell script which needs to generate a sorted list of all the files contained in the current directory, ls -1A is a simple and clean way to obtain the list. The alternatives are all either clumsy, easy to get wrong, or have drawbacks, e.g.: ls -a | grep -Ev '^\.\.?$' # exit status is that of grep, not ls ls -d -- * .[!.] .??* # may get E2BIG error or ENOENT error(s) find . ! -name . -prune -print | sed 's,^\./,,' | sort # exit status is that of sort (or if sort isn't needed, that of sed) for file in * .[!.] .??* do test -L "$file" || test -e "$file" && printf '%s\n' "$file" done | sort # (so bad I wonder why I bothered to include it as an alternative) If the list does not need to be sorted, and having "./" on the front of each filename is not a problem, then the find command above (without the sed and sort) is the closest to being a viable alternative to ls -1A. However, it is still far from being simple, and is easy to get wrong. (A natural mistake is trying to use -o in some way, as "... -prune -o ..." is a common idiom with find.) Action: Insert at line 22019 after "associated information.": Filenames beginning with a period ('.') and any associated information shall not be written out unless explicitly referenced, the -A or -a option is supplied, or an implementation-defined condition causes them to be written. Insert after line 22035: -A Write out all directory entries, including those whose names begin with a period ('.') but excluding the entries dot and dot-dot (if they exist). On lines 22056-22058 delete: Entries beginning with a period shall not be written out unless explicitly referenced, the -a option is supplied, or an implementation-defined condition shall cause them to be written. On page 577 delete lines 22298-22299: The BSD ls provides a -A option (like -a, but dot and dot-dot are not written out). The small difference from -a did not seem important enough to require both. _____________________________________________________________________________ COMMENT Enhancement Request Number 51 Gunnar.Ritter:pluto.uni-freiburg.de Defect in XCU mv (rdvk# 51) [] Fri, 28 Jan 2005 15:22:30 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) We believe that the standard being silent allows either behavior. We agreed to state it explicitly. Add to mv DESCRIPTION Page 656 before 25426 Insert into p656 before the existing para that states: "If the duplication of the file hierarchy fails for any reason, mv shall write a diagnostic message to standard error, do nothing more with the current source_file, and go on to any remaining source_files." If files being duplicated to another filesystem have hard links to other files it is unspecified whether the files copied to the new filesystem have the hard links preserved or separate copies are created for the linked files. _____________________________________________________________________________ Page: 0 Line: 0 Section: mv Problem: If the mv command has to duplicate a file hierarchy because rename() failed with EXDEV, it seems unclear if it has to re-create hard links within that hierarchy, or if it is allowed to create a separate file for each link. That is, with the following command sequence: $ mkdir d $ touch d/a $ ln d/a d/b $ ls -li d total 0 1156620 -rw-r--r-- 2 gunnar other 0 Jan 28 14:59 a 1156620 -rw-r--r-- 2 gunnar other 0 Jan 28 14:59 b $ mv d to_some_other_filesystem $ ls -li to_some_other_filesystem/d either of the following might happen: total 0 3583 -rw-r--r-- 1 gunnar other 0 Jan 28 14:59 a 3584 -rw-r--r-- 1 gunnar other 0 Jan 28 14:59 b or total 0 3596 -rw-r--r-- 2 gunnar other 0 Jan 28 14:59 a 3596 -rw-r--r-- 2 gunnar other 0 Jan 28 14:59 b Existing implementations mostly behave as in the first variant, i.e. they split hard links; the only exceptions known to me are GNU ls and my own implementation. However, I think that the second variant is actually correct. This is because 1) it more closely resembles the situation in which rename() was successful, 2) the hard links belong to the structure of the hierarchy and should be duplicated with it. A similar situation arises if a file within the duplicated hierarchy has multiple links, but not all of these links are located within that hierarchy. In this case, mv could be required to re-create at least the links within the hierarchy. Action: Since the specification for mv is explicit about symbolic links, it should be explicit about hard links as well. At the minimum, it should explicitly mention that the behavior with hard links is implementation-defined, which allowed all parties to keep their current behavior but would be a warning to users not to rely on it. If nobody objects, it could be preferable to require mv to preserve hard links, though. _____________________________________________________________________________ COMMENT Enhancement Request Number 52 Gunnar.Ritter:pluto.uni-freiburg.de Defect in XCU man (rdvk# 52 ) [] Sat, 05 Feb 2005 16:00:01 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 52(->interps) AI-108 This is an interpretation of the standard. The standard is clear , however concerns are being forwarded to the sponsor. Note to the editor for a future revision: Change line 24571 to "The standard error shall be used for diagnostic messages, and may also be used for informational messages of unspecified format." _____________________________________________________________________________ Page: 632 Line: 24571 Section: man Problem: The standard currently specifies that the man command must not use standard error for other than diagnostic messages. However, historic implementations have written a message "Reformatting page. Wait..." when they started to reformat the nroff source for a page, and have followed this by " done" when finished. These messages had originally been written to standard output in 4BSD, but later, SunOS and SVR4 derivatives, whose implementations of /usr/ucb/man seem to be of BSD origin, have been writing it to standard error. These are not diagnostic messages, though, since they do not indicate an error but just a processing delay. Now a) it makes sense to write such a message, since the user must sometimes wait several seconds for nroff even on moderately modern machines, and b) it makes sense to write it to standard error, since the message should not appear in the regular output e.g. if the user invokes something like "man utility | col -b >utility.txt". POSIX should thus not disallow such messages. Action: Change line 24571 to "The standard error shall be used for diagnostic messages, and may also be used for optional informational messages of unspecified format." _____________________________________________________________________________ OBJECTION Enhancement Request Number 53 ebb9:byu.net Defect in XCU pwd (rdvk# 2) {ebb9.pwd} Wed, 16 Feb 2005 15:50:17 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 53(->interps) AI-097 This issue should be forwarded down the interpretations track as a proposed defect in the standard. The standard is clear, standard is wrong concerns are being forward to the sponsor Proposed change for a future revision (not part of the interpretation): Replace the first sentence of the PWD Environment variable section "If the -P option is in effect, this variable shall be set to an absolute pathname of the current working directory that does not contain any components that specify symbolic links, does not contain any components that are dot, and does not contain any components that are dot-dot." with "An absolute pathname of the current working directory." Add to Rationale section: A previous version of this standard stated that the PWD environment variable was affected when the -P option was in effect. This was incorrect, conforming implementations do not do this." _____________________________________________________________________________ Page: 0 Line: 0 Section: pwd Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The Environment Variables section of the pwd(1) command, http://www.opengroup.org/onlinepubs/009695399/utilities/pwd.html, is clear that execution of ``pwd -P'' shall set the environment variable PWD to a canonical form (no symlinks, ., or ..). But in practice, I was unable to find any system where pwd could change the environment, whether provided as a shell built-in (ash, bash, pdksh, zsh) or as a separate utility (GNU coreutils, Solaris 8). Additionally, I don't see how a separate utility would be capable of setting the environment of the invoking shell, which would implicitly require pwd to be a shell builtin; but unlike the cd utility, the Application Usage section of pwd is silent on this fact. For example, $ cd /tmp $ mkdir a $ ln -s a b $ cd -L b $ pwd -L /tmp/b $ echo $PWD /tmp/b $ pwd -P /tmp/a $ echo $PWD # pwd -P did not change $PWD /tmp/b Action: Under the description of the use of the PWD variable by pwd, change: "If the -P option is in effect, this variable shall be set to an absolute pathname of the current working directory..." to: "If the -L option is in effect, this variable is read as described in the DESCRIPTION. If the -P option is in effect, this variable may be set to an absolute pathname of the current working directory..." _____________________________________________________________________________ COMMENT Enhancement Request Number 54 Gunnar.Ritter:pluto.uni-freiburg.de Defect in XCU mailx (rdvk# 1) [] Sat, 12 Feb 2005 13:43:01 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 54(->interps track) AI-090 (no need to do anything here as addressed in ERN 20) Change resolution to #20 as follows If the current message has not been written (for example, by the print command) since mailx started or since any other message was the current message, behave as if the print command was entered. Otherwise, if there is an undeleted message after the current message, make it the current message and behave as if the print command was entered. Otherwise, an informational message to the effect that there are no further messages in the mailbox shall be written, followed by the mailx prompt. Should the current message location be the result of an immediately preceeding "hold", "mbox", "preserve", or "touch" command, next will act as if the current message has already been written. (i.e. just add "mbox" and "touch" to the list of commands at the bottom). _____________________________________________________________________________ Page: 600 Line: 23240-23245 Section: mailx Problem: In enhancement request number 20, it was proposed to change the behavior of the "next" command such that a previous "hold" command advances to the next message, as if the current one had been written. It has now come to my attention that the situation is similar with previous "mbox" and "touch" commands. These commands are normally also used with messages which the user does not want to view immediately again (as they are essentially commands that "write" the message but with delayed processing), and it is also the case here that traditional mailx implementations were advancing to the next message. A similar consideration applies to the "new" and "unread" commands which are not part of POSIX but of traditional implementations. I am not sure if implementations are free to advance to the next message with such commands, or if the POSIX text for "next" must be applied to them as well as its presciption is generic ("has not been written"). If so, it should be made clear that any command that is an extension is not restricted by the text for "next". Action: Change the resolution for #20 to If the current message has not been written (for example, by the print command) since mailx started or since any other message was the current message, behave as if the print command was entered. Otherwise, if there is an undeleted message after the current message, make it the current message and behave as if the print command was entered. Otherwise, an informational message to the effect that there are no further messages in the mailbox shall be written, followed by the mailx prompt. Should the current message location be the result of an immediately preceeding "hold", "mbox", "preserve", or "touch" command, next will act as if the current message has already been written. (i.e. just add "mbox" and "touch" to the list of commands at the bottom). If the current text also applies to extension commands, change it to ... current message location be the result of an immediately preceeding "hold", "mbox", "preserve", or "touch" command, or of other unspecified commands not defined in the standard, next will act as if the current message has already been written. _____________________________________________________________________________ OBJECTION Enhancement Request Number 55 gwc:opengroup.org Defect in XCU 2.6.5 Field Splitting (rdvk# 3) [gwc non-whitespace IFS] Thu, 10 Mar 2005 11:10:53 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 55(->interps) AI-098 (see also XCU 49) _____________________________________________________________________________ Page: 42 Line: 1729 Section: 2.6.5 Problem: Defect code : 1. Error Discussions on the Austin Group mailing list of how non-whitespace IFS characters are used as delimiters have identified the need for some improvements to the description of IFS and field splitting that would help prevent misinterpretation, plus a correction to the description of the read utility where it refers to IFS characters as separators. The new descriptions clarify the intended behaviour whereby the IFS characters are used to terminate fields, as confirmed in POSIX.2 interpretation pasc-1003.2-98. Action: On page 35 line 1427 section 2.5.3 Shell Variables: Delete "(Input Field Separators.) " from the beginning of the IFS description. (Note that this change should be done after the change in XCU ERN 49.) On page 42 line 1729 section 2.6.5 Field Splitting, paragraph 2: Change "The shell shall treat each character of the IFS as a delimiter and use the delimiters to split the results of parameter expansion and command substitution into fields." to "The shell shall treat each character of the IFS as a delimiter and use the delimiters as field terminators to split the results of parameter expansion and command substitution into fields." On page 817 line 31778-31780 section read: Change "If there are fewer var operands specified than there are fields, the leftover fields and their intervening separators shall be assigned to the last var. If there are fewer fields than vars, the remaining vars shall be set to empty strings." to "If there are fewer fields than there are var operands, the remaining vars shall be set to empty strings. If there are fewer vars than fields, the last var shall be set to a value comprising the following elements: * the field that corresponds to the last var in the normal assignment sequence described above, * the delimiter(s) that follow the field corresponding to the last var, and * the remaining fields and their delimiters, with trailing IFS white space ignored." On page 853 line 33116-33120 section sh under ENVIRONMENT VARIABLES: Replace the description of IFS with a copy of the one from section 2.5.3 after the change specified above has been applied to it. (This will do more than just delete "(Input Field Separators.) ", since XCU ERN 49 will also have been previously applied to 2.5.3.) On page 865 line 33622 section sh under RATIONALE: Insert the following before "The KornShell ignores the contents of IFS" (as a new first sentence of that paragraph): "The name IFS was originally an abbreviation of Input Field Separators, however this name is misleading as the IFS characters are actually used as field terminators." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 56 gwc:opengroup.org Defect in XCU mkdir (rdvk# 2) [gwc mkdir -m] Thu, 10 Mar 2005 10:37:38 +0000 _____________________________________________________________________________ Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) _____________________________________________________________________________ Page: 638 Line: 24731 Section: mkdir Problem: Defect code : 1. Error In POSIX.2b the mkdir and mkfifo descriptions were both changed in the same way to clarify an ambiguity regarding the -m option. In XCU6 the change made it onto the mkfifo page but not the mkdir page. Action: Change "If the -m option is specified, the mode option-argument overrides this default." to "If the -m option is specified, the value of the mkdir() mode argument is unspecified, but the directory shall at no time have permissions less restrictive than the -m mode option-argument." (The CHANGE HISTORY section for both mkdir and mkfifo should also be updated to record this change.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 57 eggert:cs.ucla.edu Defect in XCU mv (rdvk# 1) {20050304a} Fri, 4 Mar 2005 20:54:55 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 57 (->interps) AI-164 Send down the interpretations track. The standard is clear, concerns are being forwarded to the sponsor. After XCU page 655 line 25410 append this: If the destination path exists and was created by a previous step it is unspecified whether this will treated as an error or the destination path will be overwritten. Change XCU page 268 line 10474 from this: a. If dest_file exists, the following steps shall be taken: to this: a. The behavior is unspecified if dest_file exists and was written by a previous step. Otherwise, if dest_file exists, the following steps shall be taken: Insert new sentence on ln 21887 before If... If the destination path exists and was created by a previous step it is unspecified whether ln shall write a diagnostic message to standard error, do nothing more with the current source_file, and go on to any remaining source_files; or will continue processing the current /source_file/. Add to RATIONALE for ln The specification ensures that 'ln a a' with or without the -f option will not unlink the file a. Earlier versions of the standard were unclear in this case. _____________________________________________________________________________ Page: 655 Line: 25410 Section: mv Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX currently requires the command "mv a/f b/f d" to remove a/f; this breaks a fundamental user assumption that "mv" should not lose file contents. POSIX should be modified to allow implementations to detect this situation and refuse to move to the same location twice. For example, here is how GNU mv behaves: $ mkdir a b d $ touch a/f b/f $ mv a/f b/f d mv: will not overwrite just-created `d/f' with `b/f' $ echo $? 1 and POSIX should allow this behavior. There is a similar problem with cp, if the user simulated a move using cp and rm. Action: After XCU page 655 line 25410 append this: The behavior is implementation-defined if the destination path exists and was created by a previous step. Change XCU page 268 line 10474 from this: a. If dest_file exists, the following steps shall be taken: to this: a. The behavior is implementation defined if dest_file exists and was written by a previous step. Otherwise, if dest_file exists, the following steps shall be taken: _____________________________________________________________________________ COMMENT Enhancement Request Number 58 nick:usenix.org Defect in XCU who (rdvk# 4) {nms-who-b} Mon, 28 Feb 2005 22:11:54 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D1) Revise the -b option as follows: 1. Use the same term as in XBD: -b Write the time and date of the last system reboot. 2. Add a sentence The system reboot time is the time at which the implementation is able to commence running processes. 3. In the STDOUT section add to the XSI shaded text "XSI-conformant systems shall write the default information to the standard output in the following general format: ...." For the -b option, shall be "system boot". The is unspecified. 4. In the STDOUT sectoin (on page 1053) Add after line 40602 This entry is not associated with a terminal. CROSS VOLUME CHANGE FOR A FUTURE REVISION In XBD Chapter 3 Definitions System Boot should be added with the current text for the definition of System Reboot And System Reboot should simply state "See System Boot" _____________________________________________________________________________ Page: 1051 Line: 40531 Section: who Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The -b option to "who" is described: -b Write the time and date of the last reboot. There are a couple of clarifications required here. 1. "System Reboot" is defined (in XBD) as "An unspecified sequence of events that may result in the loss of transitory data; that is, data that is not saved in permanent storage. For example, message queues, shared memory, semaphores, and processes." This sequence of events has a distinct (amd often not insignificant) duration. What exactly is "the time of the last reboot"? The time that the system started rebooting (i.e. before it closed down), the time it started recovering (i.e. the time that various init scripts start running), or the time when it is fully operational again? Certain scripts and applications that may run during this recovery might wish to know if they are running close to a reboot ... e.g. "has the system been up for less than 30 seconds?" Understanding when the clock starts running would be useful. 2. The output format for this option is not particularly clear "XSI-conformant systems shall write the default information to the standard output in the following general format: []