bug#71242: PR: src/stat.c - add magic for bcachefs

On 28/05/2024 12:08, Paul Hedderly via GNU coreutils Bug Reports wrote: Currently stat does not know bcachefs $:~/gits/coreutils$ sudo stat -f -c %T / UNKNOWN (0xca451a4e) But it just needs to know that magic $:~/gits/coreutils$ sudo ./src/stat -f -c %T / bcachefs Please

bug#71242: PR: src/stat.c - add magic for bcachefs

Currently stat does not know bcachefs $:~/gits/coreutils$ sudo stat -f -c %T / UNKNOWN (0xca451a4e) But it just needs to know that magic $:~/gits/coreutils$ sudo ./src/stat -f -c %T / bcachefs Please pull this small commit:

bug#62515: Bug in pr

When the page length is less than 10, pr does not output a header, even one that is explicitly supplied. Stated another way, when page length is <= 10, there is no way to counter implicit -t/-T. Stated another way, -t/-T always (silently) overrides -h, and there is no option to force a

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

bug#47246: pr -f does not pause

POSIX specifies that pr -f shall "[p]ause before beginning the first page if the standard output is associated with a terminal" (see https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pr.html). GNU pr does not do this. [The recently reported bug#47243

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

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On 15/02/2021 07:19, Erik Auerswald wrote: On Sun, Feb 14, 2021 at 11:04:21PM +, Pádraig Brady wrote: On 14/02/2021 19:22, Erik Auerswald wrote: May I ask you to test the new patch (v4) as well? This version looks good. I'll probably apply this after a little more local testing. Pushed

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On Sun, Feb 14, 2021 at 11:04:21PM +, Pádraig Brady wrote: > On 14/02/2021 19:22, Erik Auerswald wrote: > >May I ask you to test the new patch (v4) as well? > > This version looks good. > I'll probably apply this after a little more local testing. Thanks!

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On 14/02/2021 19:22, Erik Auerswald wrote: May I ask you to test the new patch (v4) as well? This version looks good. I'll probably apply this after a little more local testing. Thanks to both of you! Pádraig

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On Sun, 2021-02-14 at 20:22 +0100, Erik Auerswald wrote: > Hi, > > On 13.02.21 21:28, Leonard Janis Robert König wrote: > > On Sat, 2021-02-13 at 21:15 +0100, Erik Auerswald wrote: > > > On 13.02.21 19:29, Leonard Janis Robert König wrote: > > > > [...] > > > > That being said, I don't see this

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

-s and -s$'\t' use different code paths +push @Tests, + ['merge-w-tabs-sepstr', "-m -s'\t' -t", +{IN=>{1=>"a\tb\tc\n"}}, +{IN=>{2=>"m\tn\to\n"}}, +{IN=>{3=>"x\ty\tz\n"}}, + {OUT=>join("\t", qw(a b c m n o x y z)

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On Sat, 2021-02-13 at 21:15 +0100, Erik Auerswald wrote: > Hi, > > On 13.02.21 19:29, Leonard Janis Robert König wrote: > > > > first:  Thank you very much for the work, I really owe you one! > > You're welcome. :-) > > > On Sat, 2021-02-13 at 17:58 +0100, Erik Auerswald wrote: > > > On

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On 13.02.21 19:29, Leonard Janis Robert König wrote: first: Thank you very much for the work, I really owe you one! You're welcome. :-) On Sat, 2021-02-13 at 17:58 +0100, Erik Auerswald wrote: On 13.02.21 15:17, Erik Auerswald wrote: On 11.02.21 20:20, Erik Auerswald wrote: On Thu,

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, first: Thank you very much for the work, I really owe you one! On Sat, 2021-02-13 at 17:58 +0100, Erik Auerswald wrote: > On 13.02.21 15:17, Erik Auerswald wrote: > > On 11.02.21 20:20, Erik Auerswald wrote: > > > On Thu, Feb 11, 2021 at 06:09:28PM +0100, Leonard Janis Robert > > > König >

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

s.pl index b7d868cf8..ed5c61dc9 100755 --- a/tests/pr/pr-tests.pl +++ b/tests/pr/pr-tests.pl @@ -467,6 +467,14 @@ push @Tests, {IN=>{3=>"x\ty\tz\n"}}, {OUT=>join("\t", qw(a b c m n o x y z)) . "\n"} ]; +# Exercise a variant of the bug with pr -

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

8cf8..ed5c61dc9 100755 --- a/tests/pr/pr-tests.pl +++ b/tests/pr/pr-tests.pl @@ -467,6 +467,14 @@ push @Tests, {IN=>{3=>"x\ty\tz\n"}}, {OUT=>join("\t", qw(a b c m n o x y z)) . "\n"} ]; +# Exercise a variant of the bug with pr -m -s (commit 553

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

truncate_lines = true; + if (!parallel_files) + untabify_input = true; tabify_output = true; } else diff --git a/tests/pr/pr-tests.pl b/tests/pr/pr-tests.pl index b7d868cf8..0894d3804 100755 --- a/tests/pr/pr-tests.pl +++ b/tests/pr/pr-tests.pl @@ -474,6 +474,12 @@ push @

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On Thu, 2021-02-11 at 16:45 +0100, Erik Auerswald wrote: > Hi, > > On Thu, Feb 11, 2021 at 04:12:54PM +0100, Leonard Janis Robert König > wrote: > > On Thu, 2021-02-11 at 13:00 +0100, Erik Auerswald wrote: > > > On Wed, Feb 10, 2021 at 01:42:29PM +0100, Leonard Janis Robert > > > König > > >

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On Wed, Feb 10, 2021 at 01:42:29PM +0100, Leonard Janis Robert König wrote: > I'm sorry if I this is not a bug but to be expected, but I thnk pr > doesn't get the alignment of tabs in multicolumn output right. > [...] > This seems *kind* of related to multi-column merged output, as was >

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On Wed, 2021-02-10 at 17:06 +0100, Erik Auerswald wrote: > Hi, > > On Wed, Feb 10, 2021 at 01:42:29PM +0100, Leonard Janis Robert König > wrote: > > I'm sorry if I this is not a bug but to be expected, but I thnk pr > > doesn't get the alignment of tabs in multicolumn output right. > > [...] > >

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On Wed, 2021-02-10 at 16:44 +0100, Erik Auerswald wrote: > Hi, > > On Wed, Feb 10, 2021 at 01:42:29PM +0100, Leonard Janis Robert König > wrote: > > I'm sorry if I this is not a bug but to be expected, but I thnk pr > > doesn't get the alignment of tabs in multicolumn output right. > > > >

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On Wed, Feb 10, 2021 at 01:42:29PM +0100, Leonard Janis Robert König wrote: > I'm sorry if I this is not a bug but to be expected, but I thnk pr > doesn't get the alignment of tabs in multicolumn output right. > [...] > Unfortunately the POSIX spec is, in my reading, a bit unclear here. I

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On Wed, Feb 10, 2021 at 01:42:29PM +0100, Leonard Janis Robert König wrote: > I'm sorry if I this is not a bug but to be expected, but I thnk pr > doesn't get the alignment of tabs in multicolumn output right. > > Consider the following test input, where everything from x->x is a tab > (with

bug#46422: 'pr' screws up tabstops in multicolumn outpt?

I'm sorry if I this is not a bug but to be expected, but I thnk pr doesn't get the alignment of tabs in multicolumn output right. Consider the following test input, where everything from x->x is a tab (with tabs 8): 123456781234567812345678123456781 x x x x x

bug#24996: Bug in PR utility

Marcel Böhme wrote: There is an integer overflow in pr.c:1880 which results in memory exhaustion. The bug was found with AFLFast, a fork of AFL. Did it find only one such problem? I found half a dozen in the neighborhood. I guess it gave up after the first one. I fixed the bugs I found, by

bug#24996: Bug in PR utility

Dear all, There is an integer overflow in pr.c:1880 which results in memory exhaustion. The bug was found with AFLFast, a fork of AFL. How to reproduce: $ pr -l -5 I was actually fuzzing Coreutils 6.10 as part of ongoing experiments. Also confirmed for Coreutils 8.25. Best regards, -

bug#24924: pr has no concept of wide characters

> "AG" == Assaf Gordon writes: AG> I would very much appreciate if you could help me test it as there AG> are many edge-cases with multibyte support and wide-characters. Sure but you need to send me a .deb or $ which pr|xargs file /usr/bin/pr: ELF 32-bit LSB

bug#24924: pr has no concept of wide characters

severity 24924 wishlist tags 24924 wishlist notabug thanks Hello Dan, On 11/11/2016 11:10 AM, 積丹尼 Dan Jacobson wrote: The pr documentation (man, info) doesn't mention how it has no concept of wide characters. $ pr -m --sep-string='^^^' file file Indeed, most of the current coreutils

bug#24924: pr has no concept of wide characters

The pr documentation (man, info) doesn't mention how it has no concept of wide characters. $ pr -m --sep-string='^^^' file file 2016-11-12 00:06 Page 1 http://www.w3.org/TR/html4/strict^^^"http://www.w3.org/TR/html4/strict ^^^

bug#13786: pr command does not fold

Hi, I could not get the pr command to fold the lines. Is this a bug? I am using pr (GNU coreutils) 8.13 under GNU bash 4.2.24. Here is an example - the following pr command produced an output that instead of folding a long line of text in the first column, it cuts it off: $ echo Snow with

bug#13786: pr command does not fold

Hello, Doh Smith wrote, On 02/22/2013 05:14 AM: I could not get the pr command to fold the lines. Is this a bug? I am using pr (GNU coreutils) 8.13 under GNU bash 4.2.24. I think 'pr' does the pagination and columnation, but doesn't actual re-folds (=wraps) lines to your desired length. It is

bug#13786: pr command does not fold

tag 13786 notabug close 13786 stop On 02/22/2013 10:14 AM, Doh Smith wrote: Hi, I could not get the pr command to fold the lines. Is this a bug? I am using pr (GNU coreutils) 8.13 under GNU bash 4.2.24. Here is an example - the following pr command produced an output that instead of folding

bug#9347: PR(1) -t/-T negates :STOP_PAGE

The issue: Running pr(1) with eith the -t or -T options appears to negate the --page option's :LAST_PAGE optional argument. The documentation does not mention this effect; either the documentation or the program should be updated to address this. Illustration of issue: $ wc -l foo 144 foo $ pr

bug#9347: PR(1) -t/-T negates :STOP_PAGE

29 21:08:37 UTC 2011 i686 GNU/Linux This looks like a bug, since `pr +2 -T` does skip the first page. I.E. -tT should be independent of those page ranges. The following seems to work, and pass tests. cheers, Pádraig. diff --git a/src/pr.c b/src/pr.c index 771418c..d1adc55 100644 --- a/src/pr.c

bug#9347: PR(1) -t/-T negates :STOP_PAGE

2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:08:37 UTC 2011 i686 GNU/Linux This looks like a bug, since `pr +2 -T` does skip the first page. I.E. -tT should be independent of those page ranges. The following seems to work, and pass tests. cheers, Pádraig. diff --git a/src/pr.c b/src

bug#9023: pr command does not honor -f or --form-feed option

Conklin,Paul W. wrote: I think that I have found a bug with the pr command Version Info pr 5.97 October 2008PR(1) Thank you for the report. I confirm that GNU pr (even the latest, from coreutils-8.12) is not compatible with the pr from

bug#9023: pr command does not honor -f or --form-feed option

Jim Meyering wrote: Conklin,Paul W. wrote: I think that I have found a bug with the pr command Version Info pr 5.97 October 2008 PR(1) Thank you for the report. I confirm that GNU pr (even the latest, from coreutils-8.12

bug#9023: pr command does not honor -f or --form-feed option

Jim Meyering wrote: Jim Meyering wrote: Conklin,Paul W. wrote: I think that I have found a bug with the pr command Version Info pr 5.97 October 2008 PR(1) Thank you for the report. I confirm that GNU pr (even the latest, from coreutils

bug#9023: pr command does not honor -f or --form-feed option

I think that I have found a bug with the pr command Version Info pr 5.97 October 2008PR(1) root:talinux01@talinux01:/ # rpm -qa --filesbypkg | grep -w /usr/bin/pr coreutils /usr/bin/pr root:talinux01@talinux01:/ # rpm -q

[bug #28492] pr header lacks spaces around long file names

Update of bug #28492 (project coreutils): Status:None = Fixed Assigned to:None = ericb ___ Follow-up Comment #2: Patched in git,

[bug #28492] pr header lacks spaces around long file names

URL: http://savannah.gnu.org/bugs/?28492 Summary: pr header lacks spaces around long file names Project: GNU Core Utilities Submitted by: None Submitted on: Wed 06 Jan 2010 12:53:34 AM UTC Category: None

[bug #28492] pr header lacks spaces around long file names

Follow-up Comment #1, bug #28492 (project coreutils): Thanks for the report (although the mailing list tends to be the preferred medium for potential patches). You are indeed correct that this is a violation of POSIX. Your patch is reversed in sense (you want the original file to be listed

Re: Bug in pr?

Sorry, I see I wasn't clear. By omitting the trailer I meant that GNU pr attempted to print on the very last line of the output page, omitting the usual trailer of 5 blank lines at the bottom of the output page. Ok, I guess we should try that.

Re: Bug in pr?

Richard Stallman [EMAIL PROTECTED] writes: Omitting the trailer causes GNU pr to try to print on the very last line of the output page, which is a portability hassle: some printers and printer emulators ignore newline before formfeed on the last line of a page, while others

Re: Bug in pr?

Paul Eggert [EMAIL PROTECTED] wrote: Here's a patch along the lines I just suggested. It's a bit large since it changes the test cases to match the behavior, and the test cases' file names depend on the behavior! I am enclosing the output of vc-dwim --commit, in the hopes that this captures

Re: Bug in pr?

Omitting the trailer causes GNU pr to try to print on the very last line of the output page, which is a portability hassle: some printers and printer emulators ignore newline before formfeed on the last line of a page, while others don't. Wouldn't the trailer force a move to the

Re: Bug in pr?

Jim Meyering [EMAIL PROTECTED] writes: 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

Re: Bug in pr?

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

Re: Bug in pr?

Jim Meyering scripsit: 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? Historically (and I go back to the days of actual line printers), LF and FF were analogues: one moved the

Re: Bug in pr?

Perhaps you can simply filter the output of pr through a filter to eliminate the offending newline(s)? Maybe I could, but that seems to be an answer to the wrong question. The question is not how I can get good printouts. The question is how to make our various programs work right

[bug #1728] pr header line length sometimes incorrect

Update of bug #1728 (project coreutils): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: I can no longer

[bug #1728] pr header line length sometimes incorrect

Follow-up Comment #1, bug #1728 (project coreutils): Hi Bob, I can't see any details here. Can you add some, or say that it's fixed in coreutlis-6.2? Thanks, Jim ___ Reply to this item at: http://savannah.gnu.org/bugs/?1728

manpage documentation bug for pr

The man page for pr.1 says: The full documentation for pr is maintained as a Texinfo manual. If the info and pr programs are properly installed at your site, the command info coreutils pr should give you access to the complete manual. But on my

Re: manpage documentation bug for pr

Ken Pizzini [EMAIL PROTECTED] writes: The man page for pr.1 says: The full documentation for pr is maintained as a Texinfo manual. If the info and pr programs are properly installed at your site, the command info coreutils pr should give