View Issue Details

IDProjectCategoryView StatusLast Update
00004161003.1(2008)/Issue 7Shell and Utilitiespublic2013-04-16 13:06
Reporterjoerg Assigned To 
PrioritynormalSeverityEditorialTypeError
Status ClosedResolutionAccepted As Marked 
NameJörg Schilling
Organization
User Reference
Sectionval
Page Number3307
Line Number110388
Interp StatusApproved
Final Accepted Text0000416:0000834
Summary0000416: Message description for "val" is inconststent
DescriptionThe STDOUT section contains this text:

    The standard output shall consist of informative messages about either:

       1.

          Each file processed
       2.

          Each command line read from standard input

    If the standard input is not used, for each file operand yielding a discrepancy, the output line shall have the following format:

    "%s: %s\n", <pathname>, <unspecified string>

    If standard input is used, a line of input shall be written before each of the preceding lines for files containing discrepancies:

    "%s:\n", <input line>

The EXAMPLES section however contains this text:

    In a directory with three SCCS files- s.x (of t type "text"), s.y, and s.z (a corrupted file)-the following command could produce the output shown:

    val - <<EOF
    -y source s.x
    -m y s.y
    s.z
    EOF


    -y source s.x


        s.x: %Y%, -y mismatch
    s.z


        s.z: corrupted SCCS file

THe latter is the text that is written by historical "val" implementations, while the STDOUT section defines something different.
Desired ActionDecide whether the output for "val" should stay as it has been in historical val
implementations or whether the output should be changed.

If the output should be changed for POSIX, the EXAMPLES section needs to be corrected, in the other case, the STDOUT section needs correction.

Rationale: the Solaris implementation for "val" contains commented out code that
matches the STDOUT section but produces output that matches the EXAMPLES section.
As Solaris has been verified for POSIX conpliance, it seems that the historic
output (as documented in the EXAMPLES section) is OK.
Tagstc1-2008

Activities

jim_pugsley

2011-06-14 20:36

manager   bugnote:0000833

Using the online version of the Conformance Specification, there appear to be 2 discrepancies between the STDOUT format specification and the example; only one of them is real.

The first would be that the example appears to call for 1 or more blank lines between the '<input line>' output and the '<pathname>: <unspecified string>' output lines. This apparent discrepancy is an artifact of the conversion between the pdf version of the Specification and the online version; the pdf version, which includes line numbers, makes it clear that the example does not contain any blank lines.

The actual discrepancy is that the formatting specified by STDOUT, p 3307, lines 110382 through 110390, does not specify indentation of any output lines. The example, p 3308, 110419 through 110427, shows the '<input line>' output without indentation, but shows the '<pathname>: <unspecified string>' output to be indented by 4 space characters.

The Solaris implementation prints a blank line between the '<input line>' and the '<pathname>: <unspecified string>' lines which, as detailed above, is not specified by either STDOUT nor by the example. It indents the '<pathname>: <unspecified string>' lines by 4 space characters, as shown in the example but not specified in STDOUT.

It is true that the Solaris version of val.c/report() has some code commented out, but that code wouldn't output in the format specified under STDOUT. It would remove the spurious blank lines, but it indents the '<pathname>: <unspecified string>' lines by 1 space character instead of 4, matching neither STDOUT nor the example.

geoffclare

2011-06-15 14:49

manager   bugnote:0000834

Interpretation response
------------------------
The standard states the requirements for val output, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
The specified format does not match existing practice, although the example
output does.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
In STDOUT at line 110388 change:

    If standard input is used, a line of input shall be written before
    each of the preceding lines for files containing discrepancies:

    "%s:\n", <input line>

to:

    If standard input is used, for each input line yielding a discrepancy,
    the output shall have the following format:

    "%s\n\n %s: %s\n", <input>, <pathname>, <unspecified string>

    where <input> is the input line minus its terminating <newline>.


In EXAMPLES remove the blank line between lines 110423 and 110424.

ajosey

2011-06-16 10:16

manager   bugnote:0000848

Interpretation proposed 16 June 2011 for final 30 day review

ajosey

2011-07-29 06:13

manager   bugnote:0000904

The interpretation is now approved.

Issue History

Date Modified Username Field Change
2011-04-22 21:14 joerg New Issue
2011-04-22 21:14 joerg Name => Jörg Schilling
2011-04-22 21:14 joerg URL => http://pubs.opengroup.org/onlinepubs/9699919799/utilities/val.html
2011-04-22 21:14 joerg Section => utilities: val
2011-05-05 15:40 msbrown Project Online Pubs => 1003.1(2008)/Issue 7
2011-06-14 20:36 jim_pugsley Note Added: 0000833
2011-06-15 14:49 geoffclare Section utilities: val => val
2011-06-15 14:49 geoffclare Page Number => 3307
2011-06-15 14:49 geoffclare Line Number => 110388
2011-06-15 14:49 geoffclare Interp Status => Pending
2011-06-15 14:49 geoffclare Note Added: 0000834
2011-06-15 14:49 geoffclare Status New => Interpretation Required
2011-06-15 14:49 geoffclare Resolution Open => Accepted As Marked
2011-06-15 14:50 geoffclare Final Accepted Text => 0000416:0000834
2011-06-15 14:51 geoffclare Tag Attached: tc1-2008
2011-06-16 10:16 ajosey Interp Status Pending => Proposed
2011-06-16 10:16 ajosey Note Added: 0000848
2011-07-29 06:13 ajosey Interp Status Proposed => Approved
2011-07-29 06:13 ajosey Note Added: 0000904
2013-04-16 13:06 ajosey Status Interpretation Required => Closed