Report 0615 Actions
Problem Report Number |
0615 |
Submitter's Classification |
Specification problem |
State |
Resolved |
Resolution |
Rejected (REJ) |
Problem Resolution ID |
REJ.X.0219 |
Raised |
1970-01-01 08:00 |
Updated |
2003-03-13 08:00 |
Published |
null |
Product Standard |
Commands and Utilities V2 (UNIX 95) |
Certification Program |
The Open Brand certification program |
Test Suite |
VSC version 4.1.4 |
Test Identification |
XOPEN.cmd/uux/uux.ex 1020 |
Problem Summary |
PG4C.00057 Should uux provide shell style pathname expansion on the appropriate system. |
Problem Text |
The implementator requests a formal interpretation, we believe the consultants response is incorrect. This request was opened as a result of a problem report from a customer with a mixed system shop. We understand that assertion 1020 is currently marked UNTESTED, however the TMLA requires to us to adher to the spec, which in this case we believe to be incorrect. Assertion 1020 of the uux test purpose tests the following from the page 767 XPG4 XCU V2 specification: " * In gathering file from different systems, pathname expansion is not performed by uux. Thus, a request such as: uux "c89 remsys!~/*.c" would attempt to copy the file name literally *.c to the local system." However, this violates historically practice and seems to be an error on the part of the spec writers. Historically, pathname expansion always occurs. On page 769, under the Application Usage section, the following is found: "As noted in uucp, shell pattern matching notation characters appearing in pathnames are expanded on the appropriate local system." And on page 745 in the uucp Operands sections the following is found: "The shell pattern matching notation characters ?, * and [...] appearing in pathname will be expanded on the appropriate system." These statements contradict the one above. In most implementations, uucp actually calls uux for the file transfers. Thus, uux must be able to handle pathname expansion. A TSD for uux assertion 1020 or PIN against the XCU V2 specification should be issued.
|
Test Output |
|
Review Information
Review Type |
TSMA Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Recommendation |
No Resolution Given |
Review Response |
We recommend this request be refused. But some rework of the uux spec does seem appropriate. uux test purpose 1020 is UNTESTED in VSC 4.1.4. So there is no possibility of granting a TSD for this request. Shell style pathname expansion does not appear to be tested by any assertion. We can find no support for the assertion that historical uux implementations support pathname expansion. Perhaps the requester is confused by the possibility of the shell expanding pathnames before the uux command is executed. This may occur during word expansion if a pathname does not have a system name, login name or ~ prefix. Besides historical practice is not normative. We believe that uucico not uux has historically been the underlying transport program for uucp. While the wording quoted from the uux Application Usage section supports the argument, it is not mormative and should be deprecated. However, the XCU uux Description Section states that A filename can be specified as for uucp; it can be an absolute pathname, a pathname preceded by ~name (which is replaced by the corresponding login directory), a pathname specified as ~/dest (dest is prefixed by the public directory called ``PUBDIR''; the actual location of PUBDIR is implementation- specific), or a simple filename (which is prefixed by uux with the current directory). See uucp for the details. The first phrase phrase leaves us wondering whether the XCU uucp statement The shell pattern matching notation characters ?, * and [...] appearing in pathname will be expanded on the appropriate system. applies. We believe that the effort the spec writers made to disallow pathname expansion (disallowing it both by rule and by example in a normative section) makes it inlikely. But we suggest adding Uucp shell pattern matching expansion will not be done on filenames in uux. to the end of the paragraph above.
|
Review Type |
Expert Group Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Resolution |
No Resolution Given |
Review Conclusion |
The request should be rejected. As noted by the Base working group, the text in this area must be clarified in a future version of the specification.
|
Review Type |
SA Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Resolution |
Rejected (REJ) |
Review Conclusion |
This request is refused.
|
Problem Reporting System Options:
|