GNU bug report logs - #47243
pr lacks -p

Previous Next

To reply to this bug, email your comments to 47243 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Coreutils <bug-coreutils <at> gnu.org>
Subject: pr lacks -p
Date: Thu, 18 Mar 2021 10:38:44 -0500

POSIX requires 'pr -p' to support paging (although it incorrectly stated
that it waits for \r, and is being fixed to wait for \n instead):
https://austingroupbugs.net/view.php?id=1433

During discussion of the behavior of -p today, the Austin Group was
surprised that coreutils' pr lacks -p altogether.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Message #8 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Thu, 18 Mar 2021 10:51:38 -0700

On 3/18/21 8:38 AM, Eric Blake wrote:
> POSIX requires 'pr -p' to support paging (although it incorrectly stated
> that it waits for \r, and is being fixed to wait for \n instead):
> https://austingroupbugs.net/view.php?id=1433
> 
> During discussion of the behavior of -p today, the Austin Group was
> surprised that coreutils' pr lacks -p altogether.

Given that hardly anybody uses pr any more, I'm surprised that the 
Austin Group still cares about its options. It's an obsolete utility, 
and ought to be deprecated.

Message #13 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: 47243 <at> debbugs.gnu.org
Subject: Re: pr lacks -p
Date: Sun, 27 Jul 2025 15:36:48 -0700

[Message part 1 (text/plain, inline)]

Paul Eggert said:

> Given that hardly anybody uses pr any more, I'm surprised that the 
> Austin Group still cares about its options. It's an obsolete utility, 
> and ought to be deprecated.

True, but this option seems simple enough to implement.

How about the attached patch?

Collin

[0001-pr-implement-p-as-required-by-POSIX-Issue-6.patch (text/x-patch, attachment)]

Message #16 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Collin Funk <collin.funk1 <at> gmail.com>, 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 00:09:41 +0100

On 27/07/2025 23:36, Collin Funk wrote:
> Paul Eggert said:
> 
>> Given that hardly anybody uses pr any more, I'm surprised that the
>> Austin Group still cares about its options. It's an obsolete utility,
>> and ought to be deprecated.
> 
> True, but this option seems simple enough to implement.
> 
> How about the attached patch?

I would just ignore the -p if stdin/stdout are not a tty.
That would make a test easier anyway, to ensure
`pr -p file >/dev/null` passes.

thanks!
Padraig

Message #19 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Sun, 27 Jul 2025 16:37:31 -0700

Hi Pádraig,

Pádraig Brady <P <at> draigBrady.com> writes:

>>> Given that hardly anybody uses pr any more, I'm surprised that the
>>> Austin Group still cares about its options. It's an obsolete utility,
>>> and ought to be deprecated.
>> True, but this option seems simple enough to implement.
>> How about the attached patch?
>
> I would just ignore the -p if stdin/stdout are not a tty.
> That would make a test easier anyway, to ensure
> `pr -p file >/dev/null` passes.

Thanks for the input.

I was conflicted on whether the best behavior was to warn, error, or
ignore the option in those cases. And whether it should be ignored if
standard out was not a tty. I guess it would be pointless to do, for
example, 'pr -p ChangeLog < file-full-of-newlines'.

I have attached the V2 patch which adds the additional check for
'isatty (STDIN_FILENO)' (V1 only had it for STDERR_FILENO), documents
that behavior, and adds a NEWS entry.

I'll push tomorrow to give others some time to comment.

Collin

Message #22 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Sun, 27 Jul 2025 16:39:46 -0700

[Message part 1 (text/plain, inline)]

Collin Funk <collin.funk1 <at> gmail.com> writes:

> I have attached the V2 patch [...]

Oops, forgotten patch attached here.

Collin

[v2-0001-pr-implement-p-as-required-by-POSIX-Issue-6.patch (text/x-patch, attachment)]

Message #25 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>, Pádraig Brady
 <P <at> draigBrady.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Sun, 27 Jul 2025 17:19:18 -0700

Thanks for looking into that. Unfortunately POSIX says -p should be 
ignored only if standard output is a terminal, and that newline should 
be read from /dev/tty, not from standard input. This is so that users 
can pipe into 'pr -p'. So the proposed patch needs some changes. Here 
are the issues I found:


> +  pr now supports the -p option, to pause upon printing each page until
> +  a newline character is read from standard input, as required by POSIX
> +  Issue 6.  The corresponding long option is --pause.

This should be /dev/tty, not standard input.


> +After printing each page, print an alert (bell) to standard error and
> +wait for a newline to be read from standard input before printing the

Likewise.

> +next page.  This option is ignored unless both standard input and
> +standard output are a tty.

This should mention only standard output.


> +  if (pause_option)
> +    pause_option = isatty (STDOUT_FILENO) && isatty (STDIN_FILENO);

This should check only standard output.


> -  if (have_read_stdin && fclose (stdin) == EOF)
> +  if ((have_read_stdin || pause_option) && fclose (stdin) == EOF)
>      error (EXIT_FAILURE, errno, _("standard input"));

This change should be omitted.


> -  while (print_page ())
> -    ;
> +  for (;;)
> +    {
> +      if (pause_option)
> +        {
> +          putc ('\a', stderr);
> +          while (getchar () != '\n')
> +            ;
> +        }
> +      if (! print_page ())
> +        break;
> +    }

This should read from /dev/tty, not from stdin.


> +  -p, --pause       pause at the beginning of each page until a newline\n\
> +                    is read from standard input.\n\

This should mention /dev/tty, not standard input.

Message #28 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>, Pádraig Brady
 <P <at> draigBrady.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Sun, 27 Jul 2025 17:26:24 -0700

On 2025-07-27 17:19, Paul Eggert wrote:
> +          putc ('\a', stderr);

A few more things.

stderr might be line buffered, so this needs an fflush afterwards.

If the putc or fflush fails, pr should diagnose and exit immediately 
(otherwise the user will wonder why pr stopped).

A failed open or read from /dev/tty should be diagnosed and exited too.

Message #31 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Sun, 27 Jul 2025 19:21:15 -0700

[Message part 1 (text/plain, inline)]

Hi Paul,

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Thanks for looking into that. Unfortunately POSIX says -p should be
> ignored only if standard output is a terminal, and that newline should
> be read from /dev/tty, not from standard input. This is so that users
> can pipe into 'pr -p'. So the proposed patch needs some changes. Here
> are the issues I found:

Thanks for the thorough review.

I think that v3 attached should cover everything.

Collin

[v3-0001-pr-implement-p-as-required-by-POSIX-Issue-6.patch (text/x-patch, attachment)]

Message #34 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 11:22:16 +0100

On 28/07/2025 03:21, Collin Funk wrote:
> Hi Paul,
> 
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
> 
>> Thanks for looking into that. Unfortunately POSIX says -p should be
>> ignored only if standard output is a terminal, and that newline should
>> be read from /dev/tty, not from standard input. This is so that users
>> can pipe into 'pr -p'. So the proposed patch needs some changes. Here
>> are the issues I found:
> 
> Thanks for the thorough review.
> 
> I think that v3 attached should cover everything.
> 
> Collin
> 

write_error() manipulates stdout,
so for the putc(..., stderr) I'd just do a straight error(EXIT_FAILURE, ....)

The NEWS would be best in a "New Features" section.

thanks!
Padraig

Message #37 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 14:25:38 +0100

On 28/07/2025 11:22, Pádraig Brady wrote:
> On 28/07/2025 03:21, Collin Funk wrote:
>> Hi Paul,
>>
>> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>>
>>> Thanks for looking into that. Unfortunately POSIX says -p should be
>>> ignored only if standard output is a terminal, and that newline should
>>> be read from /dev/tty, not from standard input. This is so that users
>>> can pipe into 'pr -p'. So the proposed patch needs some changes. Here
>>> are the issues I found:
>>
>> Thanks for the thorough review.
>>
>> I think that v3 attached should cover everything.
>>
>> Collin
>>
> 
> write_error() manipulates stdout,
> so for the putc(..., stderr) I'd just do a straight error(EXIT_FAILURE, ....)
> 
> The NEWS would be best in a "New Features" section.
> 
> thanks!
> Padraig

Reading POSIX more closely I see there is also pause logic for the first page only:
  -f    [XSI] [Option Start] Use a <form-feed> for new pages, instead of the default behavior that uses a sequence of <newline> characters.
        Pause before beginning the first page if the standard output is associated with a terminal. [Option End]

Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stan Marsh <gazelle <at> xmission.com>
To: bug-coreutils <at> gnu.org
Subject: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 08:41:00 -0600

>Paul Eggert <eggert <at> cs.ucla.edu> writes:

>Thanks for looking into that. Unfortunately POSIX says -p should be
>ignored only if standard output is a terminal, and that newline should
-----------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Shouldn't this be "ignored unless standard output is a terminal" ?

>be read from /dev/tty, not from standard input. This is so that users
>can pipe into 'pr -p'. So the proposed patch needs some changes. Here
>are the issues I found:

Then	Pádraig Brady wrote:
>Reading POSIX more closely I see there is also pause logic for the first page 
>only:
>  -f    [XSI] [Option Start] Use a <form-feed> for new pages, instead of the default 
>behavior that uses a sequence of <newline> characters.
>        Pause before beginning the first page if the standard output is 
>associated with a terminal. [Option End]

How can it be both?

And, one wonders, why do both -F and -f do the same thing?
(The man page on my system says they do...)

Note: I've been using -F with pr since forever; I had no idea (until now) that -f
did the same thing.

=================================================================================
Please do not send me replies to my posts on the list.
I always read the replies via the web archive, so CC'ing to me is unnecessary.

Note that they always end up in my Spam file anyway, so it is annoying
to have to periodically clean that out.

Message #43 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 08:01:18 -0700

On 2025-07-28 07:41, Stan Marsh wrote:
>> Paul Eggert <eggert <at> cs.ucla.edu> writes:
> 
>> Thanks for looking into that. Unfortunately POSIX says -p should be
>> ignored only if standard output is a terminal, and that newline should
> -----------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Shouldn't this be "ignored unless standard output is a terminal" ?

Yes, sorry.


> Then	Pádraig Brady wrote:
>> Reading POSIX more closely I see there is also pause logic for the first page
>> only:
>>   -f    [XSI] [Option Start] Use a <form-feed> for new pages, instead of the default
>> behavior that uses a sequence of <newline> characters.
>>         Pause before beginning the first page if the standard output is
>> associated with a terminal. [Option End]
> 
> How can it be both?

If neither -p nor -f is specified, pr doesn't pause.

If -p is specified, pr pauses before every output page, regardless of 
whether -f is also specified.

If -f but not -p is specified, pr pauses only before the first output page.

The motivation for -p is that you are using something like a Teletype 
Model 37[1] to log in, i.e., you are logged in via a printing terminal. 
But you want to print something out using special paper that you need to 
load by hand, one sheet at a time, and you don't want your interactive 
session to appear on that paper.

The -f option is also motivated for a device like the Model 37, except 
you merely want to use the existing multi-sheet paper and tear off the 
interactive session.

Although devices like the Model 37 became obsolete for logins in the 
1970s (I last used one for that purpose in 1975), apparently enough of 
them were still being used in older installations that the -p option was 
added by some well-meaning engineer at AT&T around 1980. (The -p option 
was not present in 7th edition UNIX, released in 1979.) And POSIX 
standardized -p - which has not been needed for at least three decades, 
probably four - and we are now spending time implementing -p for 
coreutils, time that would be more usefully spent elsewhere.

[1]: https://en.wikipedia.org/wiki/Teletype_Model_37

Message #46 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 08:14:22 -0700

On 2025-07-27 19:21, Collin Funk wrote:

> I think that v3 attached should cover everything.

In addition to Pádraig's comments, I would add:

> +  a newline character is read from /dev/tty, as required by POSIX Issue
> +  6.  The corresponding long option is --pause.

Don't say "Issue 6" as almost nobody knows what that means and it's 
obsolete anyway. Just say "POSIX".

> +              if (ch == EOF)
> +                {
> +                  /* Just exit if the user presses Ctrl-D.  */
> +                  if (feof (tty_fp))
> +                    goto finish;
> +                  error (EXIT_FAILURE, errno, _("error reading %s"),
> +                         quoteaf ("/dev/tty"));
> +                }

'goto finish;' should be 'return;'. That way, we don't need the 'finish' 
label.

It's possible for feof and ferror to both be true. In that case, pr 
should report the error. So, this code should call ferror instead of 
calling feof.

Come to think of it, why use stdio here? Plain 'open' and 'read' work 
just as well for this, and avoid possible stdio glitches. There's no 
real need for stdio's buffering.

Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stan Marsh <gazelle <at> xmission.com>
To: bug-coreutils <at> gnu.org
Subject: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 10:06:31 -0600

Paul wrote:

>Then    Pádraig Brady wrote:
>>Reading POSIX more closely I see there is also pause logic for the first page
>>only:
>>  -f    [XSI] [Option Start] Use a <form-feed> for new pages, instead of the 
-------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (!)
>>default
>>behavior that uses a sequence of <newline> characters.
>>        Pause before beginning the first page if the standard output is
>>associated with a terminal. [Option End]

>> How can it be both?

Then Paul wrote:

>If neither -p nor -f is specified, pr doesn't pause.

>If -p is specified, pr pauses before every output page, regardless of whether -f is
>also specified.

>If -f but not -p is specified, pr pauses only before the first output page.

I think there is a misunderstanding here.

The point is that -f is already taken; it is a synonym for -F.

So, it can't be re-purposed to mean: pause only before the first output page,
without breaking any script or human who depends on it meaning: use form feeds.

=================================================================================
Please do not send me replies to my posts on the list.
I always read the replies via the web archive, so CC'ing to me is unnecessary.

Note that they always end up in my Spam file anyway, so it is annoying
to have to periodically clean that out.

Message #52 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 17:23:30 +0100

On 28/07/2025 17:06, Stan Marsh wrote:
> Paul wrote:
> 
>> Then    Pádraig Brady wrote:
>>> Reading POSIX more closely I see there is also pause logic for the first page
>>> only:
>>>   -f    [XSI] [Option Start] Use a <form-feed> for new pages, instead of the
> -------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (!)
>>> default
>>> behavior that uses a sequence of <newline> characters.
>>>         Pause before beginning the first page if the standard output is
>>> associated with a terminal. [Option End]
> 
>>> How can it be both?
> 
> Then Paul wrote:
> 
>> If neither -p nor -f is specified, pr doesn't pause.
> 
>> If -p is specified, pr pauses before every output page, regardless of whether -f is
>> also specified.
> 
>> If -f but not -p is specified, pr pauses only before the first output page.
> 
> I think there is a misunderstanding here.
> 
> The point is that -f is already taken; it is a synonym for -F.
> 
> So, it can't be re-purposed to mean: pause only before the first output page,
> without breaking any script or human who depends on it meaning: use form feeds.

Yes it's a fair point.
We don't want existing scripts that use -f to start pausing unexpectedly.
I suppose this is a case for only pausing with -f if POSIXLY_CORRECT
env var is set.

cheers,
Padraig

Message #55 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 09:53:57 -0700

On 2025-07-28 09:23, Pádraig Brady wrote:
> Yes it's a fair point.
> We don't want existing scripts that use -f to start pausing unexpectedly.
> I suppose this is a case for only pausing with -f if POSIXLY_CORRECT
> env var is set.

Although backward compatibility is an issue, the current behavior is 
clearly wrong for the intended use of -f, which is for logins via 
printing terminals so stdout is the printer. So a better way to think 
about it is that this is merely a longstanding obscure bug in GNU 'pr' 
that we can fix.

The only reason we haven't noticed the bug before, is that nobody has 
seriously used those terminals in decades, so nobody has run into the 
bug and taken the time to report it.

Other 'pr' implementations (e.g., FreeBSD) do the right thing here, and 
I see no significant reason (other than inertia) for us to be both wrong 
for the intended use and incompatible with the rest of the world.

Message #58 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 09:57:30 -0700

On 2025-07-28 09:06, Stan Marsh wrote:
> The point is that -f is already taken; it is a synonym for -F.

That's a bug in GNU 'pr'. -f is supposed to mean "act like -F but also 
pause before the first page if standard output is a terminal". See 
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pr.html#tag_20_95_04>.

Message #61 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 10:36:02 -0700

Pádraig Brady <P <at> draigBrady.com> writes:

> Reading POSIX more closely I see there is also pause logic for the first page only:
>   -f    [XSI] [Option Start] Use a <form-feed> for new pages, instead of the default behavior that uses a sequence of <newline> characters.
>         Pause before beginning the first page if the standard output is associated with a terminal. [Option End]

Thanks, I'll have a look.

> I presume you're waiting until the implementation solidifies,
> but just in case, a couple of basic tests to show
> that -p is accepted at least would be good.

Yep, I was going to add some simple tests afterwards.

Paul Eggert said:

> On 2025-07-28 09:23, Pádraig Brady wrote:
>> Yes it's a fair point.
>> We don't want existing scripts that use -f to start pausing unexpectedly.
>> I suppose this is a case for only pausing with -f if POSIXLY_CORRECT
>> env var is set.

> Although backward compatibility is an issue, the current behavior is
> clearly wrong for the intended use of -f, which is for logins via
> printing terminals so stdout is the printer. So a better way to think
> about it is that this is merely a longstanding obscure bug in GNU 'pr'
> that we can fix.
>
> The only reason we haven't noticed the bug before, is that nobody has
> seriously used those terminals in decades, so nobody has run into the
> bug and taken the time to report it.
>
> Other 'pr' implementations (e.g., FreeBSD) do the right thing here,
> and I see no significant reason (other than inertia) for us to be both
> wrong for the intended use and incompatible with the rest of the
> world.

I don't really like the idea of changing '-f' depending on whether
POSIXLY_CORRECT is defined. So I would prefer this as well.

I'll write another patch later today based on your other emails as well.

Collin

Message #64 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 11:06:55 -0700

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

Message #67 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Mon, 28 Jul 2025 21:39:16 -0700

[Message part 1 (text/plain, inline)]

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> 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:

Interesting, I did not know about this part of the GNU Coding Standards.

> (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.

That sounds good to me. I attached a v4 patch that should behave this
way and address the other issues that you mentioned.

> It'd be less useful in practice, but that doesn't matter since the
> practical need for this behavior vanished decades ago.

Thanks for again for the thorough review and explanations. I find it
funny that I assumed this change was simple and learned it's purpose was
for logging in on a teletype. The Model 37 predates me ~30 years, so it
never occured to me that the purpose was to not print logins.

Collin

[v4-0001-pr-implement-p-and-modify-f-conforming-to-POSIX.patch (text/x-patch, attachment)]

Message #70 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Tue, 29 Jul 2025 01:06:37 -0700

On 2025-07-28 21:39, Collin Funk wrote:

> Thanks for again for the thorough review and explanations. I find it
> funny that I assumed this change was simple and learned it's purpose was
> for logging in on a teletype. The Model 37 predates me ~30 years, so it
> never occured to me that the purpose was to not print logins.

Heh, in the 1960s I used a Teletype Model 33, which was so bad that 
nobody ever wanted to print anything nice on it and 'pr' would have 
never gotten these flags if all people had were Model 33s. And that 
wasn't the worst device I used to write programs!

but I digress....

> +  pr now supports the -p option, to pause upon printing each page until
> +  a newline character is read from /dev/tty, as required by POSIX.  The
> +  corresponding long option is --pause.

Change "upon" to "before".

> +After printing each page, print an alert (bell) to standard error and
> +wait for a newline to be read from @file{/dev/tty} before printing the
> +next page.

This sentence should start "Before" not "After", with the rest of the 
sentence changed accordingly. There is no bell printed after the last page.

Looking at the code, it seems that this mistake has leaked into the code 
as well, in that sometimes 'pr' will print an alert and wait for '\n' at 
end of file, when there is no page to print. If I'm right, that needs to 
be fixed; pr should wait for '\n' only if it will actually print 
something afterward.


> +@vindex POSIXLY_CORRECT
> +If the @env{POSIXLY_CORRECT} environment variable is set and standard
> +output is not a tty, this option will be ignored.

Better wording is to start "This option is ignored if...".  And change 
"not a tty" to "not associated with a terminal". Similarly for the other 
"not a tty"s.  (Few people these days know that "tty" is short for 
"Teletype"....)


> +/* If true, pause after each page until a newline is read from /dev/tty.  */

"after" -> "before"

> +static bool pause_option;
> +
> +/* If true, pause on only the first page.  */

The "only" sounds wrong, if both flags are set. I would omit "only". 
Also, change "on" to "before".


> +  /* POSIX states that the pausing behavior of -f and -p should only occur if

"should only occur" -> "should occur only"

> +  if (pause_option && close (tty_fd) < 0)
> +    error (EXIT_FAILURE, errno, "%s", quotef ("/dev/tty"));

Why are these lines useful? As far as I can see they merely add 
complexity for no benefit. How about removing them? (If we kept them we 
would need to fix the bug in them; but let's remove them.)

> +              unsigned char ch;

Make it plain char; there's no reason it needs to be unsigned.

> +          if (putc ('\a', stderr) == EOF || fflush (stderr) != 0)

fputc here; there's no need for efficiency since we're gonna fflush anyway.

More important, this fputc and fflush should be skipped if pause_option 
is false.

You might want to turn this part of the code into a separate static 
function, for clarity. (Or you might not....)

> I assumed this change was simple

And you were right: it will be simple, once we get it done right....

Message #73 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Tue, 29 Jul 2025 10:11:27 -0700

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 2025-07-28 21:39, Collin Funk wrote:
>
>> Thanks for again for the thorough review and explanations. I find it
>> funny that I assumed this change was simple and learned it's purpose was
>> for logging in on a teletype. The Model 37 predates me ~30 years, so it
>> never occured to me that the purpose was to not print logins.
>
> Heh, in the 1960s I used a Teletype Model 33, which was so bad that
> nobody ever wanted to print anything nice on it and 'pr' would have
> never gotten these flags if all people had were Model 33s. And that
> wasn't the worst device I used to write programs!

I'm curious, what is the worst?

>> +After printing each page, print an alert (bell) to standard error and
>> +wait for a newline to be read from @file{/dev/tty} before printing the
>> +next page.
>
> This sentence should start "Before" not "After", with the rest of the
> sentence changed accordingly. There is no bell printed after the last
> page.
>
> Looking at the code, it seems that this mistake has leaked into the
> code as well, in that sometimes 'pr' will print an alert and wait for
> '\n' at end of file, when there is no page to print. If I'm right,
> that needs to be fixed; pr should wait for '\n' only if it will
> actually print something afterward.

Good catch, I guess the logic of checking if there are more pages to
print should be hoisted out of 'print_page ()' or the pausing logic
should be handled there, just before printing. Let me see which one is
less of a chore to read.

>> +  if (pause_option && close (tty_fd) < 0)
>> +    error (EXIT_FAILURE, errno, "%s", quotef ("/dev/tty"));
>
> Why are these lines useful? As far as I can see they merely add
> complexity for no benefit. How about removing them? (If we kept them
> we would need to fix the bug in them; but let's remove them.)

I assume we would want to close the file descriptors that we open at the
end of the program. If so, I guess there is no point in checking for
errors from 'close'. Or is the close not nessecary, similar to calling
'free' on memory just before exit?

>> +          if (putc ('\a', stderr) == EOF || fflush (stderr) != 0)
>
> fputc here; there's no need for efficiency since we're gonna fflush anyway.
>
> More important, this fputc and fflush should be skipped if
> pause_option is false.

That was my interpretation as well. But I noticed that FreeBSD and
NetBSD will print the alert using 'pr -f'. Since both of us agree that
is wrong, I will change it.

> You might want to turn this part of the code into a separate static
> function, for clarity. (Or you might not....)

Yep, at first the conditions were too small to benefit from an extra
function. But over time it is beginning to make more sense...

Thanks,
Collin

Message #76 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Tue, 29 Jul 2025 12:10:26 -0700

On 2025-07-29 10:11, Collin Funk wrote:

>> And that wasn't the worst device I used to write programs!
> I'm curious, what is the worst?

The IBM 029 card punch, introduced in 1964, was worse.

https://en.wikipedia.org/wiki/Keypunch#IBM_029_Card_Punch

Also, the Qume QVT-102, introduced in 1983. Terrible keyboard. Gave me 
carpal tunnel syndrome.

https://terminals-wiki.org/wiki/index.php/Qume_QVT-102


>>> +  if (pause_option && close (tty_fd) < 0)
>>> +    error (EXIT_FAILURE, errno, "%s", quotef ("/dev/tty"));
>>
>> Why are these lines useful? As far as I can see they merely add
>> complexity for no benefit. How about removing them? (If we kept them
>> we would need to fix the bug in them; but let's remove them.)
> 
> I assume we would want to close the file descriptors that we open at the
> end of the program. If so, I guess there is no point in checking for
> errors from 'close'. Or is the close not nessecary, similar to calling
> 'free' on memory just before exit?

Yes, the latter. Files are automatically closed on exit.

We check for error when closing output fds because some filesystems 
delay error reporting until close. There's less of a reason to check for 
closing input fds just before exit. Here, I can't think of any reason.

Message #79 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Tue, 29 Jul 2025 21:51:04 -0700

[Message part 1 (text/plain, inline)]

Paul Eggert <eggert <at> cs.ucla.edu> writes:

>> +After printing each page, print an alert (bell) to standard error and
>> +wait for a newline to be read from @file{/dev/tty} before printing the
>> +next page.
>
> This sentence should start "Before" not "After", with the rest of the
> sentence changed accordingly. There is no bell printed after the last
> page.
>
> Looking at the code, it seems that this mistake has leaked into the
> code as well, in that sometimes 'pr' will print an alert and wait for
> '\n' at end of file, when there is no page to print. If I'm right,
> that needs to be fixed; pr should wait for '\n' only if it will
> actually print something afterward.

Fixing this required a bit more understanding of the code on my part,
but I think the attached patch should address it.

The existing code uses a 'pad_vertically' variable to keep track of
whether the current page has text or a header that needs to be
printed. Therefore, any time we set it to true, we must also pause. But
only once, at the start of the page.

Collin

[v5-0001-pr-implement-p-and-modify-f-conforming-to-POSIX.patch (text/x-patch, attachment)]

Message #82 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Wed, 30 Jul 2025 12:18:16 +0100

On 30/07/2025 05:51, Collin Funk wrote:
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
> 
>>> +After printing each page, print an alert (bell) to standard error and
>>> +wait for a newline to be read from @file{/dev/tty} before printing the
>>> +next page.
>>
>> This sentence should start "Before" not "After", with the rest of the
>> sentence changed accordingly. There is no bell printed after the last
>> page.
>>
>> Looking at the code, it seems that this mistake has leaked into the
>> code as well, in that sometimes 'pr' will print an alert and wait for
>> '\n' at end of file, when there is no page to print. If I'm right,
>> that needs to be fixed; pr should wait for '\n' only if it will
>> actually print something afterward.
> 
> Fixing this required a bit more understanding of the code on my part,
> but I think the attached patch should address it.
> 
> The existing code uses a 'pad_vertically' variable to keep track of
> whether the current page has text or a header that needs to be
> printed. Therefore, any time we set it to true, we must also pause. But
> only once, at the start of the page.

Looking good. A few tweaks...

The NEWS for -p should be in a "New Features" section.

The texinfo for --pause should:
s/before printing the next page/before printing the page/

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.

The write_error() after the putc('\a') should be a plain error (EXIT_FAILURE, ...)

thanks,
Padraig

Message #85 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Wed, 30 Jul 2025 10:31:51 -0700

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.

While I'm bikeshedding :-), one other thought is that if POSIXLY_CORRECT 
is not set we could also be compatible with FreeBSD, and output a bell 
before the first page if -f is specified but -p is not. I suspect that 
this is a more-useful approach (and could well be what System V did, and 
we've merely exposed a bug in POSIX here).

Message #88 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Wed, 30 Jul 2025 19:29:44 +0100

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.

> While I'm bikeshedding :-), one other thought is that if POSIXLY_CORRECT
> is not set we could also be compatible with FreeBSD, and output a bell
> before the first page if -f is specified but -p is not. I suspect that
> this is a more-useful approach (and could well be what System V did, and
> we've merely exposed a bug in POSIX here).
Didn't we discuss that, deciding we need POSIXLY_CORRECT here to gate the incompat behavior.
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?

cheers,
Padraig

Message #91 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org
Subject: Re: bug#47243: pr lacks -p
Date: Wed, 30 Jul 2025 13:12:23 -0700

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.

Message #94 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Wed, 30 Jul 2025 13:13:41 -0700

On 2025-07-29 21:51, Collin Funk wrote:

> +          /* Just exit if the user presses Ctrl-D.  */
> +          if (bytes_read == 0)
> +            return;

This needs reworking now that 'pause_maybe' is a separate function, as 
the code no longer exits, it just keeps going.

One other thought. It may well be better to open /dev/tty lazily, that 
is, inside pause_maybe's 'while (true)' loop, just before the 'read' 
(assuming /dev/tty has not already been opened). That way, pr -p needn't 
unnecessarily fail when printing an empty file (where /dev/tty isn't 
needed after all).

Message #97 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 47243 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#47243: pr lacks -p
Date: Wed, 30 Jul 2025 13:27:31 -0700

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 2025-07-29 21:51, Collin Funk wrote:
>
>> +          /* Just exit if the user presses Ctrl-D.  */
>> +          if (bytes_read == 0)
>> +            return;
>
> This needs reworking now that 'pause_maybe' is a separate function, as
> the code no longer exits, it just keeps going.

Yep, I noticed just after I sent it. I figured that we could just do:

    if (have_read_stdin && fclose (stdin) == EOF)
      error (EXIT_FAILURE, errno, _("standard input"));
    exit (EXIT_SUCCESS);

The same as we do before exiting 'main' (probably make the closing of
standard input a static function).

But didn't bother sending a new patch just for that. :)

> One other thought. It may well be better to open /dev/tty lazily, that
> is, inside pause_maybe's 'while (true)' loop, just before the 'read'
> (assuming /dev/tty has not already been opened). That way, pr -p
> needn't unnecessarily fail when printing an empty file (where /dev/tty
> isn't needed after all).

Good idea. That sounds better to me as well.

I'll have to take a look at Pádraig's and your other messages in a bit.

Thanks,
Collin

Message #100 received at 47243 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 47243 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#47243: pr lacks -p
Date: Wed, 30 Jul 2025 20:02:44 -0700

Pádraig Brady <P <at> draigBrady.com> writes:

> 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.

I don't see much of a point in having the pausing behavior occur when
the output is not a terminal. But the GNU Coding Standards say to avoid
it and I don't expect it cause any issues. Maybe someone more clever
than I will find a use for it...

>> While I'm bikeshedding :-), one other thought is that if POSIXLY_CORRECT
>> is not set we could also be compatible with FreeBSD, and output a bell
>> before the first page if -f is specified but -p is not. I suspect that
>> this is a more-useful approach (and could well be what System V did, and
>> we've merely exposed a bug in POSIX here).
> Didn't we discuss that, deciding we need POSIXLY_CORRECT here to gate the incompat behavior.
> 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.

FWIW, the pausing from '-f' will not occur unless someone has
POSIXLY_CORRECT set. You can see the behavior by applying the v5 patch
and using the following examples:

    # Doesn't require input.
    $ ./src/pr -f HACKING
    # Requires input
    $ POSIXLY_CORRECT=1 ./src/pr -f HACKING

You can also see a mistake I made that I mentioned in a message to Paul.
Doing 'pr -p HACKING' and pressing Ctrl-D prints the next page, but it
should exit.

> Or do you mean output a bell, but not pause? I can't see how that would be useful?

I think Paul was referring to my mention that FreeBSD and NetBSD print an
alert to standard error when doing 'pr -f', when the POSIX description
only mentions this behavior for 'pr -p'. I'm not certain wether or not
this is allowed by POSIX.

Collin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.