bug#47243: pr lacks -p

On 2025-07-28 10:36, Collin Funk wrote:
> I don't really like the idea of changing '-f' depending on whether
> POSIXLY_CORRECT is defined. So I would prefer this as well.

On second thought (sorry...) I now think I understand why GNU pr behaves 
the way it does. The GNU coding standards[1] say "...please don’t make 
the behavior of a command-line program depend on the type of output 
device it gets as standard output or standard input. Device independence 
is an important principle of the system’s design; do not compromise it 
merely to save someone from typing an option now and then."

The standards go on to list some exceptions, such as 'ls'. 'pr' is not 
one of the exceptions. Currently there are a few other exceptions in 
Coreutils ('df', 'mv', 'nohup', 'rm', 'tail') but I guess 'pr' didn't 
make the cut when it was written.

That is, my theory is that when GNU 'pr' was written, its original 
author Pete TerMaat followed the GNU coding standards, and deliberately 
made '-f' and '-F' aliases, because that way the behavior of pr would 
not depend on isatty (STDOUT_FILENO). And Pete did not implement -p 
because it didn't sound useful if we follow the coding standards.

If this theory is correct, then a fix that would be more in the spirit 
of GNU would be something like this:

(a) Implement -p as if isatty (STDOUT_FILENO) is true. This form of -p 
is useful only when stdout is a terminal, but that's good enough since 
nobody uses (or will use :-) -p.

(b) If POSIXLY_CORRECT is set, change -f and -p so that they both worry 
about isatty (STDOUT_FILENO), as POSIX requires.

This would conform to POSIX, would address Pádraig's concern about 
compatibility, and would follow the GNU coding standards. It'd be less 
useful in practice, but that doesn't matter since the practical need for 
this behavior vanished decades ago.

Sound good enough?

[1]: https://www.gnu.org/prep/standards/html_node/User-Interfaces.html