0001590: requirement for pr on an empty file doesn't match implementations

Notes
(0005855) Don Cragun (manager) 2022-06-20 16:20 edited on: 2022-06-23 15:17	Old Interpretation response ------------------------ The standard states the behavior of pr with an empty file, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- The standard does not match existing practice. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes in the desired action.

(0005856) kre (reporter) 2022-06-20 16:49	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!

(0005858) geoffclare (manager) 2022-06-21 09:30	Reopening because the desired action is incorrect if the -m option is used.

(0005859) geoffclare (manager) 2022-06-21 09:34	Re Note: 0005856, thanks for spotting that the proposed change is wrong for -m. I will work on an updated proposal. The other points in your note are unrelated to the empty file issue and should be dealt with in one or more separate bugs. (Some of them may need their own formal interpretation response instead of being sneaked in as part of this one.)

(0005860) kre (reporter) 2022-06-21 11:07	On thinking about it, I think the right way to deal with empty files (other than to allow them to generate an error, if that is really what happens, sometimes) isn't to deal with them at all. Instead, what I believe that (at least many) pr implementations do is suppress the header and trailer if there would be so substantive output on a page. In normal mode, an empty file is nothing, hence no output, no header, no trailer, nothing. In -m mode, if one of the files is empty, it is treated just like any other file which has run out of data, and its column is filled with spaces. On the other hand, if all of the files given with -m are empty, there's no output at all (no header, or trailer, or anything). I'll see if I can dredge up the time to turn the rest of Note: 0005856 into one or more bug reports - but they're unlikely to have much of a desired action beyond "fix it" except where the problem is simply bad wording. I don't have the time at the minute to check implementations and see what they do. Would you prefer one omnibus "cleanup pr" PR, or one for each issue, or something in between ?

(0005861) geoffclare (manager) 2022-06-21 13:46 edited on: 2022-06-21 14:00	Re Note: 0005860 Good point about -m with all empty files. Everyone seems to handle that case the way you describe. Even Solaris and HP-UX with only one empty file - which makes them inconsistent with/without -m and that's probably grounds for a future direction disallowing the error they give without -m. As to how to group the other problems you raised into one or more new bugs... The file operand of "-" and the -t/-l "as if" problems will get fixed as a side effect of the change here. The -p and the -r problem I think should each have their own bug. The others could probably be lumped together in one bug.

(0005862) geoffclare (manager) 2022-06-21 14:12 edited on: 2022-06-21 14:15	Updated proposal ... On page 3109 line 103939 section pr (INPUT FILES), after: The input files shall be text files. append: If the -m option is not specified, an empty input file may, but should not, be treated as an error. On page 3109 line 103964 section pr (STDOUT), change: The pr utility output shall be a paginated version of the original file (or files). This pagination shall ... to: If the -m option is not specified, the pr utility output shall be as follows: If an input file is empty and the implementation does not treat this as an error, no output shall be written for that file and this shall be considered to be successful completion of the processing for that file. For each non-empty input file, the output shall be a paginated version of the original file. If the -m option is specified, the pr utility output shall be a paginated version of the merged file contents, as described in OPTIONS. In both cases, the pagination shall ... On page 3109 line 103966 section pr (STDOUT), change: Page headers shall be generated unless the -t option is specified. to: Page headers shall be generated unless the -t option is specified, the -l option is specified with too small a value (see OPTIONS), or the -m option is specified and all of the input files are empty. On page 3109 line 103969 section pr (STDOUT), change: In the POSIX locale, the <output of date> field, representing the date and time of last modification of the input file (or the current date and time if the input file is standard input), shall be equivalent to the output of the following command as it would appear if executed at the given time: date "+%b %e %H:%M %Y" without the trailing <newline>, if the page being written is from standard input. If the page being written is not from standard input, in the POSIX locale, the same format shall be used, but the time used shall be the modification time of the file corresponding to file instead of the current time. to: In the POSIX locale, the <output of date> field shall be equivalent to the output of the following command: date "+%b %e %H:%M %Y" as it would appear if executed at the current time if the -m option is specified, or at the following time otherwise: The current time on pages being written from standard input. The modification time of the file named by the corresponding file operand on pages not being written from standard input. On page 3110 line 103979 section pr (STDOUT), change: If the standard input is used instead of a file operand, the <file> field shall be replaced by a null string. If the -h option is specified, the <file> field shall be replaced by the header argument. to: If the -h option is specified, the <file> field shall be replaced by the header argument. Otherwise: If the -m option is specified, the <file> field shall be replaced by a null string on all pages. If the -m option is not specified, the <file> field shall be replaced by a null string on pages containing output that was read from standard input. After page 3111 line 104034 section pr (RATIONALE), add a new paragraph: Some implementations of pr treat an empty file as an error when -m is not specified, but not when -m is specified (even if there is only one input file). Implementations are encouraged to eliminate this inconsistency by never treating an empty file as an error. On page 3111 line 104036 section pr (FUTURE DIRECTIONS), change: None. to: A future version of this standard may require that an empty file is never treated as an error.

(0005864) kre (reporter) 2022-06-21 15:35	That looks cleaner, though I still suspect it would be even simpler if the "no output on a page" test was specified, rather than the division between -m and not -m, and the special case for -m with all empty files. It really is just one generic "if there's nothing, write nothing" test (most likely, by deferring writing headers until there is some output to go on the page, and not writing the trailer (including all the blank lines required to position it properly) if no header was written. But I see no technical problems with what is proposed in Note: 0005862 for the issue it is dealing with.

(0005865) agadmin (administrator) 2022-06-21 15:49	Note the proposed interpretation status has been withdrawn as the bug was reopened after the meeting

(0005866) Don Cragun (manager) 2022-06-23 15:11 edited on: 2022-06-23 15:16	Interpretation response ------------------------ The standard states the behavior of pr with an empty file, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- The standard does not match existing practice. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes in Note: 0005862.

(0005870) agadmin (administrator) 2022-06-24 09:19	Interpretation proposed: 23 June 2022

(0005913) agadmin (administrator) 2022-07-26 11:15	Interpretation approved: 26 July 2022

(0005936) geoffclare (manager) 2022-08-19 15:09	When applying this bug I noticed that the text "without the trailing <newline>", relating the the output of a date command, had been accidentally dropped from the STDOUT section. I retained 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 Note: 0005855.
2022-06-20 16:22	Don Cragun	Tag Attached: tc3-2008
2022-06-20 16:49	kre	Note Added: 0005856
2022-06-21 09:30	geoffclare	Note Added: 0005858
2022-06-21 09:30	geoffclare	Status	Interpretation Required => Under Review
2022-06-21 09:30	geoffclare	Resolution	Accepted => Reopened
2022-06-21 09:34	geoffclare	Note Added: 0005859
2022-06-21 11:07	kre	Note Added: 0005860
2022-06-21 13:46	geoffclare	Note Added: 0005861
2022-06-21 14:00	geoffclare	Note Edited: 0005861
2022-06-21 14:12	geoffclare	Note Added: 0005862
2022-06-21 14:15	geoffclare	Note Edited: 0005862
2022-06-21 14:16	agadmin	Interp Status	--- => Proposed
2022-06-21 14:16	agadmin	Note Added: 0005863
2022-06-21 15:35	kre	Note Added: 0005864
2022-06-21 15:37	agadmin	Note Deleted: 0005863
2022-06-21 15:49	agadmin	Interp Status	Proposed => ---
2022-06-21 15:49	agadmin	Note Added: 0005865
2022-06-23 15:11	Don Cragun	Note Added: 0005866
2022-06-23 15:13	Don Cragun	Final Accepted Text	See Note: 0005855. => See Note: 0005866.
2022-06-23 15:13	Don Cragun	Status	Under Review => Interpretation Required
2022-06-23 15:13	Don Cragun	Resolution	Reopened => Accepted As Marked
2022-06-23 15:15	Don Cragun	Interp Status	--- => Pending
2022-06-23 15:16	Don Cragun	Note Edited: 0005866
2022-06-23 15:17	Don Cragun	Note Edited: 0005855
2022-06-24 09:19	agadmin	Interp Status	Pending => Proposed
2022-06-24 09:19	agadmin	Note Added: 0005870
2022-07-26 11:15	agadmin	Interp Status	Proposed => Approved
2022-07-26 11:15	agadmin	Note Added: 0005913
2022-08-19 15:09	geoffclare	Note Added: 0005936
2022-08-19 15:09	geoffclare	Status	Interpretation Required => Applied
2024-06-11 09:07	agadmin	Status	Applied => Closed

Relationships

Aardvark Mark IV