Re: Bug in pr?

[Paul Eggert]

Richard Stallman <address@hidden> writes:

>       Omitting the trailer causes GNU pr to try to print on
>     the very last line of the output page, which is a portability hassle:
>     some printers and printer emulators ignore newline before formfeed on
>     the last line of a page, while others don't.
>
> Wouldn't the trailer force a move to the next page,
> exactly the opposite of what we want?

Sorry, I see I wasn't clear.  By "omitting the trailer" I meant that
GNU pr attempted to print on the very last line of the output page,
omitting the usual trailer of 5 blank lines at the bottom of the
output page.  Printing on the very last line is a portability problem,
since printers and printer emulators vary as to what they do if you
output the characters of that line, then '\n', then '\f'.  Some
printers will then print a blank page; others won't.  And you cannot
work around the problem by omitting the '\n', because in that case
some printers will not go back to column 1 in the new page.

One other thing: there are even worse portability problems if you
output on the very last column of the last output line of the page.
Some printers then wrap to the next page, so that \f then generates a
blank page regardless of whether you precede it with \r.  Others
don't.

>     submit a patch along those lines shortly, to bug-coreutils.  This is
>     an incompatible change, since it will output 7 fewer lines per page
>     when you specify -F;
>
> Don't you mean 7 more lines?  I don't follow.

I meant that it outputs 7 fewer data lines (i.e., lines containing a
copy of the input file).  This is because the header now contains 5
lines, not 3, and the trailer now contains 5 lines, not 0.

> Anyway, if this change means less output per page, why do it?

In other pr implementations (notably BSD), the -F option does not
change the appearance of the output page; it changes only whether \f
is used.  This makes sense to me.  First, pr's implementation method
for separating pages ought to be independent of the appearance of the
resulting pages.  Second, it means pr dodges the portability hassles
mentioned above.  Finally, when in doubt it is better for GNU pr to be
compatible with BSD pr.

> I'd rather change just enough to fix the problem.

It would make sense to give GNU pr an option to control the number of
lines in the header and the footer; this would give you the output
format you prefer.  Someone who implements this option can deal with
the formfeed portability hassles mentioned above.  My suggestion is to
try outputting \r before \f after outputting to the very last line of
the page, but it will require a some testing with real-world printers
and printer emulation to see how well this works.