A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1590 ====================================================================== Reported By: geoffclare Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1590 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: Interpretation Required Name: Geoff Clare Organization: The Open Group User Reference: Section: pr Page Number: 3109 Line Number: 103939 Interp Status: --- Final Accepted Text: See https://austingroupbugs.net/view.php?id=1590#c5855. ====================================================================== Date Submitted: 2022-06-20 10:57 UTC Last Modified: 2022-06-20 16:49 UTC ====================================================================== Summary: requirement for pr on an empty file doesn't match implementations ======================================================================
---------------------------------------------------------------------- (0005856) kre (reporter) - 2022-06-20 16:49 https://austingroupbugs.net/view.php?id=1590#c5856 ---------------------------------------------------------------------- I agree this should be fixed (though it is a little mind boggling that anyone would treat an empty file as an error) - but it is going to take more/different text than suggested to fix it. In particular, with -m, empty files are never simply ignored (nor, I would suggest, though I have no idea what odd implementations might do, be treated as an error) - rather the empty file is treated like any other file, it simply ends a little sooner than some of the others (its output column tends to be rather empty). Other oddments here, STDOUT says If the standard input is used instead of a file operand, the <file> field shall be replaced by a null string. Which is fine, but I believe the same is true when standard input is used because of a file argument ("-") rather than instead of one. This should probably say: When the current file is the standard input, the <file> field shall be replaced by a null string. It doesn't matter (for this) why pr is reading stdin, just that it is. The description of -p says pr shall write an <alert> to standard error and wait for a <newline> to be read on /dev/tty. I believe that's not quite correct, what pr waits for is for a read on /dev/tty to complete, the normal way this happens is when the user types a <newline> but EOF works just as well (the EOL char probably would too). That (from "and wait" onwards) should probably be changed to say and wait for a read on /dev/tty to complete (usually accomplished by entering a <newline>). As best I can tell (limited testing) what is actually entered makes no difference at all (but that should probably be left unspecified, in case some implementation has decided to incorporate some relation of "more" in pr -p). STDOUT says: Page headers shall be generated unless the -t option is specified. Yet the description of the -l option says: If lines is not greater than the sum of both the header and trailer depths (in lines), the pr utility shall suppress both the header and trailer, as if the -t option were in effect. They cannot both be correct (unless both -t and -l small are given). Either -l small suppresses the header (in which case what it says in STDOUT is incorrect - the header is not printed, yet no -t option was specified) or STDOUT is correct, the header and trailer are printed for small pages, leaving no space for any file data (if -l is small enough) so the output is just a continuous stream (forever) of header&trailer. That needs fixing as well. The STDOUT section also says nothing at all about the trailer appearing there. The description of the "-column" option doesn't actually say anywhere that the "column" there is an integer, nor bound its value in any way (what does -0 do ?) What does "should not be used with -m" mean really, that's not standards language. It also says that -e and -i are assumed for multi-column output, but those options have (optional) parameters, nothing there says what values those parameters should have in this case, nor whether these assumed options override earlier explicit -e or -i options. Given the positioning, it is also unclear if the "multicolumn output" it refers to there is only that from the -column option, or also includes -m output. More non-standards language appears as "When used with -t, use the minimum number of lines to write the output." which looks like an instruction to the implementer, not something that an application script writer could depend upon, nor anything upon which one could base a conformance decision. The -r option says not to write diagnostic reports when files cannot be opened, but when given, if the only event that could be considered an error is such an open failure, does this count as an error for the purposes of the exit status, or (with -r) is the failure to open a file ignored completely (exit(0) if no other errors occurred). There's no spec of how the spaces that -o requires to be output (assuming offset is > 0) interact with the -i option. Consider "-o 8 -i+4" -- does that still result in lines starting with 8 spaces, or with two '+' chars ? There is probably more, I am out of time... beginning discussions on some of the ancient text is fun, isn't it! Issue History Date Modified Username Field Change ====================================================================== 2022-06-20 10:57 geoffclare New Issue 2022-06-20 10:57 geoffclare Name => Geoff Clare 2022-06-20 10:57 geoffclare Organization => The Open Group 2022-06-20 10:57 geoffclare Section => pr 2022-06-20 10:57 geoffclare Page Number => 3109 2022-06-20 10:57 geoffclare Line Number => 103939 2022-06-20 10:57 geoffclare Interp Status => --- 2022-06-20 16:20 Don Cragun Note Added: 0005855 2022-06-20 16:20 Don Cragun Status New => Interpretation Required 2022-06-20 16:20 Don Cragun Resolution Open => Accepted 2022-06-20 16:22 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=1590#c5855. 2022-06-20 16:22 Don Cragun Tag Attached: tc3-2008 2022-06-20 16:49 kre Note Added: 0005856 ======================================================================
