bug#47243: pr lacks -p

On 2025-07-30 11:29, Pádraig Brady wrote:
> On 30/07/2025 18:31, Paul Eggert wrote:
>> On 2025-07-30 04:18, Pádraig Brady wrote:
>>> I'd have a slight preference for _not_ gating the isatty(STDOUT) check
>>> on $POSIXLY_CORRECT.
>>> We generally only use $POSIXLY_CORRECT to gate incompatible behavior.
>>
>> Sure, but don't the GNU coding standards disagree with POSIX here? If we
>> follow the GNU coding standards with respect to stdout, then we need a
>> POSIXLY_CORRECT check.
> 
> 
>> Or are you suggesting that we disregard the coding standards and follow
>> POSIX instead? That would be a reasonable suggestion but we might want
>> to ask RMS about it.
> 
> I thought POSIX might have higher priority here when it doesn't
> clash with existing behavior.  As I said I hadn't a strong opinion.

It's indeed not big deal, but if we're in for a nickel with -f (where we 
already disagree with POSIX due to the GNU coding standards, and we'll 
continue to do so) we might as well be in for a dime with -p (and follow 
the GNU coding standards there too).


> Didn't we discuss that, deciding we need POSIXLY_CORRECT here to gate 
> the incompat behavior.

Oh, right.

> I.e. existing scripts may be using -f to use form feeds, and we don't
> want such scripts starting to pause for their first page of output.
> Or do you mean output a bell, but not pause? I can't see how that would 
> be useful?

Oh right again, it wouldn't be.

However, come to think of it, doesn't the FreeBSD behavior conforms 
POSIX? Although 
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap01.html#tag_18_04> 
says that a utility whose description lacks a STDERR section must exit 
with nonzer status if it output to stderr, pr's description *does* have 
a STDERR section, and that section does not impose this requirement on "pr".

Hence "pr" can output extra bytes to stderr whenever it likes, and that 
means that when POSIXLY_CORRECT is set GNU "pr -f" can output a bell 
before the first page, as FreeBSD "pr" does.