Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001590 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2022-06-20 10:57 2022-07-26 11:15
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
Name Geoff Clare
Organization The Open Group
User Reference
Section pr
Page Number 3109
Line Number 103939
Interp Status Approved
Final Accepted Text See Note: 0005866.
Summary 0001590: requirement for pr on an empty file doesn't match implementations
Description The description of pr does not allow it to behave differently if an input file is empty. I could not find any implementation that behaves in the required manner, i.e. writes a header followed by a sequence of <newline>s (or a <form-feed> if -F or -f is specified).

Solaris and HP-UX report it as an error.

GNU, macOS, and FreeBSD exit with status 0 but write nothing (no header and no <newline>s).
Desired Action On page 3109 line 103939 section pr, after:
The input files shall be text files.
append:
An empty input file may be treated as an error.

On page 3109 line 103964 section pr, change:
The pr utility output shall be a paginated version of the original file (or files). This pagination shall ...
to:
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 pr utility output shall be a paginated version of the original file. This pagination shall ...

Tags tc3-2008
Attached Files

- Relationships

-  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

- 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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker