Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0734 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 0734.

Report 0734 Actions

    Problem Report Number 0734
    Submitter's Classification Specification problem
    State Resolved
    Resolution Temporary Interpretation (TIN)
    Problem Resolution ID TIN.X.0025
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1995-11-09 08:00
    Product Standard Commands and Utilities V2 (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSC version 4.1.4
    Test Identification POSIX.cmd/mailx 195
    Specification Commands and Utilities Issue 4 Version 2
    Location in Spec See Problem Text
    Problem Summary TIN4C.00036 The test should allow historical behavior not supported by current POSIX.2 or POSIX.2b/D10 wording.
    Problem Text
    *******************************************************************
    NOTE: This request was previously submitted as req.4.C.00215. It
    was refused as PG4C.00049. We would like a formal review by
    XoTGbase.
    *******************************************************************

    The test in question accurately tests the assertion, which is:

    If the User Portability Utilities option is supported: When one of the
    mailx commands copy, file, save, set, source, or write has an unquoted
    file argument that begins with a + and the folder internal variable is
    set, the file used by the command is the named file (without the leading
    +) in the folder directory and the file argument is not subjected to the
    process of shell word expansions.

    Moreover, this assertion accurately reflects the language of POSIX.2.
    However, this is not the historical behavior of the mailx command, and
    IEEE interpretation pasc-1003.2-122 addresses this issue. Historical
    behavior is described in the interpretation request, whose complete
    text (along with the IEEE response) is attached. The IEEE's response
    recognizes this fact.

    In view of the interpretation response and particularly its last
    sentence, this is clearly a grey area in XCU4.

    Added in the appeal:
    --------------------

    X/Open's consultant has recommended that this request be refused. In
    making that recommendation, the consultant remarked:

    We recommend this request be refused.

    The POSIX IR response included by the submitter clearly states

    The standard states the behavior for file name expansion in mailx
    and conforming implementations must conform to this.

    Although concerns have been raised, there is no POSIX.2b wording
    to support allowing the requested behavior.

    Historical practice is not normative.

    To this, we would respond:

    (1) The language about conforming implementations is IEEE boilerplate.
    As is well known, an IEEE interpretation cannot change a standard
    or the conformance requirements of a standard, even when it
    recognizes an error.

    (2) The argument that there is no POSIX.2b wording to support allowing
    the requested behavior is specious. The most recent draft of
    POSIX.2b was issued in May of 1995. The IEEE interpretation is
    dated August 11, 1995. Given the language used in the
    interpretation response, it is extremely likely that POSIX.2b or a
    future revision of POSIX.2 will provide language supporting the
    historical behavior.

    (3) It is true that historical practice is not normative. It is also
    true that the general intent of POSIX.2 was to standardize
    historical behavior and that in those instances where the standard
    deliberately differs from such behavior, it is documented. One
    could reasonably ask whether the present behavior is an instance of
    such an intentional change. This has been answered: the sentence
    "However, concerns have been raised about this which are being
    referred to the sponsor" is the standard POSIX interpretation
    language used to indicate that a normative requirement was
    inadvertent or wrong. Given that (as we have recognized) the
    standard is unambiguous, there is no stronger language that one can
    expect from the interpretation resolution.

    Refusing this waiver request will very likely have the effect of
    requiring many vendors to change the behavior of their mailx
    implementations, in a manner that will confuse customers. These
    vendors will then be required to change the behavior back at a later
    date with further attendant confusion when the standard is changed. It
    is much more appropriate to grant a temporary interpretation and await
    the actions of the IEEE. In the unlikely event that the present
    language remains, the temporary interpretation could be allowed to
    expire.

    Here is the text of IEEE Interpretation pasc-1003.2-122:
    -----------------start of interpretation-------------------

    _____________________________________________________________________________
    PASC Interpretation reference
    1003.2-92 #122

    _____________________________________________________________________________

    Interpretation Number: XXXX
    Topic: mailx command argument expansion for filenames
    Relevant Sections: 4.40.7.2


    Interpretation Request:
    -----------------------

    Date: Thu, 4 May 1995 09:51:46 -0700
    >From: kdawson@jurassic-52.Eng.Sun.COM (ken dawson [contractor])

    Dear Standards Board,

    I would like to request a formal interpretation on the following
    issue concerning the mailx utility in POSIX.2.


    In section 4.40.7.2 (P348, L6566-6570), it says:

    File names, where expected, shall be subjected to the process of
    shell word expansions (see 3.6); if more than a single pathname
    results and the command is expecting one file, the effects are
    unspecified. If the file name begins with an unquoted plus sign, it
    shall not be expanded, but treated as the named file (less the
    leading plus) in the folder directory. (See the folder variable.)

    While this language is clear, the actual historical behavior of this
    command should be expressed as follows (change bars are supplied on the
    left) :

    File names, where expected, shall be subjected to the following
    transformations, in sequence:

    If the file name begins with an unquoted plus sign, and the
    folder variable is defined (see the folder variable), the
    plus sign shall be replaced by the value of the folder
    variable followed by a slash; if the folder variable is unset
    or is set to null, the filename shall be unchanged.

    Shell word expansions shall be applied to the file name (see
    3.6); if more than a single pathname results from this
    expansion and the command is expecting one file, the effects
    are unspecified.

    I believe that this variance from actual historic practice was not
    intended. The rationale for mailx seems to carefully point out the cases
    where the standard differs from historic practice, but does not mention
    this issue.


    Interpretation response
    ------------------------


    The standard states the behavior for file name expansion in mailx and
    conforming implementations must conform to this. However, concerns have
    been raised about this which are being referred to the sponsor.

    Rationale
    -------------
    None.

    Forwarded to Interpretations group: May 16 1995
    Proposed resolution forwarded: Aug 11 1995
    ------------------end of interpretation--------------------
    Test Output
    ************************************************************************
    /tset/POSIX.cmd/mailx/mailx_03.ex 1 Failed


    Test Information:
    Assertion #195 (C): A file argument begining with a +, is not subject
    to expansion and is in the folder directory
    Command failed: 'grep "IN MESSAGE 1" 'mailx_out_folder/a*' > /dev/null
    2>&1'
    Command failed: 'grep "IN MESSAGE 2" 'mailx_out_folder/b*' > /dev/null
    2>&1'
    Command failed: 'grep "IN MESSAGE 3" 'mailx_out_folder/c*' > /dev/null
    2>&1'
    Command failed: 'grep "record test" 'mailx_out_folder/e*' > /dev/null
    2>&1'
    ************************************************************************

    Note: This is taken from the output of the vrpt report.

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    Upon review we believe the submitter is correct. The bolierplate
    wording used in the POSIX IR does imply a defect in the spec.

    A temporary interpretation is recommended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Temporary Interpretation (TIN)
    Review Conclusion
    A Temporary Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority