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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0623 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 0623.

Report 0623 Actions

    Problem Report Number 0623
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0227
    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 POSIX.cmd/mailx 195
    Problem Summary PG4C.00049 The test should allow historical behavior not supported by current POSIX.2 or POSIX.2b draft wording.
    Problem Text
    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.

    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
    -----------------start of 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'
    ************************************************************************

    ------------------end of test output-------------------

    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
    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.

    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:

     

    Back   

Contact the Certification Authority