Richard Stallman <[EMAIL PROTECTED]> wrote:
> The pr program has what may arguably be a bug: when used with -F, it
> ends the last line on a page with a newline. With the printer
> here (and maybe all printers nowadays), that causes a blank page
> after each real page.
>
> Maybe it would be better for pr to omit the newline before a
> formfeed.
>
> What do you think?
Thanks for the report.
The standard says this wrt -F:
-F Use a <form-feed> for new pages, instead of the
default behavior that uses a sequence of <newline>s.
So that seems to leave enough wiggle room to make a change, if needed.
Does anyone know if a formfeed is reliably recognized even when it
does not follow a newline?
I see that GNU pr works the same way as the vendor pr
from Solaris 10's /usr/xpg4/bin/pr, OpenBSD 3.9, and NetBSD 1.6
in that respect:
$ echo a|/usr/bin/pr -F|cat -A
$
$
Jul 2 11:40 2007 Page 1$
$
$
a$
^L$
Hmm...
I see that GNU pr -F gives slightly different output:
[note the missing pair of leading newlines; date format doesn't matter]
$ echo a|pr -F|cat -A
2007-07-02 18:41 Page 1$
$
$
a$
^L$
Perhaps you can simply filter the output of pr through a filter
to eliminate the offending newline(s)? E.g., this is not terribly
efficient, but it's short and does the job:
perl -0 -pe 's/\n+\f/\f/'
The advantage of adding a filter is that it should work with
any version of pr.
I see that GNU pr's documentation for -F is at odds with POSIX's
XSI requirement for pr -F:
The pr utility output shall be a paginated version of the original
file (or files). This pagination shall be accomplished using either
<form-feed>s or a sequence of <newline>s, as controlled by
XSI the -F or -f option. Page headers shall be generated unless the -t
option is specified. The page headers shall be of the form:
"\n\n%s %s Page %d\n\n\n", <output of date>, <file>, <page number>
Looks like one or the other should change.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
