bug#47243: pr lacks -p

Pádraig Brady 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 d

bug#47243: pr lacks -p

Paul Eggert 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 keep

bug#47243: pr lacks -p

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 ma

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, b

bug#47243: pr lacks -p

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

bug#47243: pr lacks -p

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 c

bug#47243: pr lacks -p

On 30/07/2025 05:51, Collin Funk wrote: Paul Eggert 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 sentenc

bug#47243: pr lacks -p

Paul Eggert 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 i

bug#47243: pr lacks -p

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

bug#47243: pr lacks -p

Paul Eggert 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 o

bug#47243: pr lacks -p

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 t

bug#47243: pr lacks -p

Paul Eggert 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 GN

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

bug#47243: pr lacks -p

Pádraig Brady writes: > Reading POSIX more closely I see there is also pause logic for the first page > only: > -f[XSI] [Option Start] Use a for new pages, instead of the > default behavior that uses a sequence of characters. > Pause before beginning the first page if the standa

bug#47243: pr lacks -p

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

bug#47243: pr lacks -p

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 c

bug#47243: pr lacks -p

On 28/07/2025 17:06, Stan Marsh wrote: Paul wrote: ThenPá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 for new pages, instead of the ---^^^

bug#47243: pr lacks -p

Paul wrote: >ThenPá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 for new pages, instead of the ---^^^ (!) >>default >>behavior that uses

bug#47243: pr lacks -p

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

bug#47243: pr lacks -p

On 2025-07-28 07:41, Stan Marsh wrote: Paul Eggert 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 out

bug#47243: pr lacks -p

>Paul Eggert 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 /de

bug#47243: pr lacks -p

On 28/07/2025 11:22, Pádraig Brady wrote: On 28/07/2025 03:21, Collin Funk wrote: Hi Paul, Paul Eggert 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 i

bug#47243: pr lacks -p

On 28/07/2025 03:21, Collin Funk wrote: Hi Paul, Paul Eggert 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 '

bug#47243: pr lacks -p

Hi Paul, Paul Eggert 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

bug#47243: pr lacks -p

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

bug#47243: pr lacks -p

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

bug#47243: pr lacks -p

Collin Funk writes: > I have attached the V2 patch [...] Oops, forgotten patch attached here. Collin >From 6927ed786c87d0849f70e20459672fcff0d114bd Mon Sep 17 00:00:00 2001 Message-ID: <6927ed786c87d0849f70e20459672fcff0d114bd.1753659226.git.collin.fu...@gmail.com> From: Collin Funk Date: Sun

bug#47243: pr lacks -p

Hi Pádraig, Pádraig Brady 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

bug#47243: pr lacks -p

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

bug#47243: pr lacks -p

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 >From 5b4a

bug#47243: pr lacks -p

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 surpri

bug#47243: pr lacks -p

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 altogeth