IEEE Standards AssociationCopyright © 2006 IEEE. All rights reserved.
Interpretation Number: 040
Topic: pathchk DESCRIPTION
Relevant Sections: XCU pathchk ------------------------------------------------------------------------
7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable):
The Shell and Utilities Volume of IEEE Std 1003.1-2001
------------------------------------------------------------------------
8 Qualifier (e.g. error, omission, clarification required):
2. Omission
------------------------------------------------------------------------
9 References in document (e.g. page, clause, figure, and/or table numbers):
Page: 696 Line: 26977 Section: pathchk
XCUbug2.txt Enhancement Request Number 43
------------------------------------------------------------------------
10 Nature of defect (complete, concise explanation of the perceived problem):
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.
------------------------------------------------------------------------
11 Solution proposed by the submitter (optional):
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.
------------------------------------------------------------------------
Interpretation response ------------------------ 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.
Back to IEEE Standards Interpretations for IEEE Std 1003.1-2001