Hi,
On Sat, Aug 02, 2025 at 09:33:15PM -0700, Collin Funk wrote:
> Hi Eric,
>
> You said:
>
> > Among other things, I can see the following changes that coreutils
> > will need to make to become compliant, or else we need to push back on
> > the POSIX folks if we have strong reasons to complain
On 2025-08-03 12:47, Collin Funk wrote:
How about the wording and formatting of the attatched patch?
Thanks, looks good.
-*- outline -*-
'factor' is now much faster at identifying large prime numbers,
and significantly faster on composite numbers greater than 2^128.
- readlink will behave as if the -v option is used if the
- POSIXLY_CORRECT environment variable is defined.
+ readlink no
Pádraig Brady writes:
>> Done, v2 attached.
>
> Looks good.
Pushed, thanks to you and Dmitry for the review.
Leaving this bug open for realpath. I'll have a look at that as well,
just requires some more reading than readlink did. :)
Collin
On 2025-08-03 11:08, Collin Funk wrote:
+ readlink will behave as if the -v option is used if the
+ POSIXLY_CORRECT environment variable is defined.
This isn't true if -q/--quiet/-s/--silent is specified. I would reword
this to something like "readlink now defaults to being verbose if
POSI
On 03/08/2025 19:08, Collin Funk wrote:
Hi Pádraig,
Pádraig Brady writes:
I'd say any option apart from -n implicitly disables strict POSIX conformance,
since those options are not in POSIX at all.
It seems like this was my misunderstanding. I thought non-POSIX options
couldn't change:
b87 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,9 @@ GNU coreutils NEWS-*- outline -*-
'factor' is now much faster at identifying large prime numbers,
and significantly faster on composite numbers greater than 2^128.
+ readlink will behave as if the -v option is used if the
+ POSIXL
On 03/08/2025 05:33, Collin Funk wrote:
Hi Eric,
You said:
Among other things, I can see the following changes that coreutils
will need to make to become compliant, or else we need to push back on
the POSIX folks if we have strong reasons to complain that their
specification will break things:
-*- outline -*-
'factor' is now much faster at identifying large prime numbers,
and significantly faster on composite numbers greater than 2^128.
+** New Features
+
+ readlink will print a diagnostic message to standard error and exit
+ with a non-zero status when given a file
Sam James writes:
> if that is ever useful. The changes themselves look good. Really, c_f_r
> has been an API plagued with problems :(
To be fair this is not the fault of copy_file_range itself. Not that it
makes the situation any better. :)
Collin
is
> serious business (e.g., malloc misbehavior). So far, nobody has
> reported an issue for this. Maybe people who build for older kernels
> (which is dubious if you ask me) aren't building for older glibcs
> (which is even more dubious).
>
> [2. text/x-patch; 0001-More-cop
eeds @code{INT_MAX} on systems using glibc version 2.41 or 2.42.
+See @url{glibc bug 33245,
+https://sourceware.org/bugzilla/show_bug.cgi?id=33245}.
@item
This function is provided on GNU/Hurd but it is only a stub: It always
@@ -43,4 +46,9 @@ fails with error @code{ENOSYS}.
Portability problems
On 02/08/2025 10:43, Martin D Kealey wrote:
On Thu, 31 Jul 2025 at 07:51, Pádraig Brady wrote:
For consistency it probably makes sense for `chmod -h` to also
not follow a symlink given as --reference=.
I know mode bits are less supported on symlinks on various systems,
but for consistency it p
On Thu, 31 Jul 2025 at 07:51, Pádraig Brady wrote:
> For consistency it probably makes sense for `chmod -h` to also
> not follow a symlink given as --reference=.
> I know mode bits are less supported on symlinks on various systems,
> but for consistency it probably makes sense.
>
[and I wrote]
>
On 02/08/2025 05:39, Collin Funk wrote:
Bruno Haible writes:
+ /* Work around glibc bug 33245
It would be good to document the workaround in
doc/glibc-functions/copy_file_range.texi.
Yep, I noticed as well. Just wanted to make sure I wasn't
misunderstanding the versions before
On 2025-08-01 20:56, Collin Funk wrote:
Also, I assume this bug will cause problems in any syscall returning
ssize_t (e.g. read, write, send).
It could well do that, yes. I suspect I haven't run into it because the
programs I help maintain respect SYS_BUFSIZE_MAX in their calls to
Bruno Haible writes:
>> + /* Work around glibc bug 33245
>
> It would be good to document the workaround in
> doc/glibc-functions/copy_file_range.texi.
Yep, I noticed as well. Just wanted to make sure I wasn't
misunderstanding the versions before doing it myself. Do
Paul Eggert wrote:
> +# if defined __GLIBC__ && ! (2 < __GLIBC__ + (43 <= __GLIBC_MINOR__))
This line is mis-indented.
> + /* Work around glibc bug 33245
It would be good to document the workaround in
doc/glibc-functions/copy_file_range.texi.
Collin Funk wrote:
. But we can more thorougly stubify the old Linux kernel bug
> workaround while we're in the neighborhood. Probably best not to
> remove it entirely as RHEL 8 still uses the no-longer-supported
> kernel.
Good point. I agree.
> +# if defined __GLIBC__ && ! (2 < __GLIBC__ +
On 2025-08-01 15:05, Collin Funk wrote:
I was hoping that file could be made a tiny stub, due to the
workarounds for Linux 4.19 being mostly unnecessary now that it is EOL.
But now we have a new problem to deal with. :)
That we do. But we can more thorougly stubify the old Linux kernel bug
Paul Eggert writes:
> On 2025-08-01 14:40, Pádraig Brady wrote:
>> Could you log this with https://sourceware.org/bugzilla/
>
> He already did that, here:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=33245
That is an unfortunate bug. Thanks and good catch Leah.
>
On 2025-08-01 14:40, Pádraig Brady wrote:
Could you log this with https://sourceware.org/bugzilla/
He already did that, here:
https://sourceware.org/bugzilla/show_bug.cgi?id=33245
I should have a Gnulib fix shortly.
> Could you log this with https://sourceware.org/bugzilla/
> and reference the bug number here?
>
> thank you,
> Padraig
This is https://sourceware.org/bugzilla/show_bug.cgi?id=33245
and a patch is at
https://sourceware.org/pipermail/libc-alpha/2025-August/169096.html
--
an do is limit copy_max to INT_MAX for now.
Could you log this with https://sourceware.org/bugzilla/
and reference the bug number here?
thank you,
Padraig
I debugged this further:
The issue boils down to several things that happen rarely:
- source and destination must be on different mountpoints, so FICLONE fails
- the fallback copy_file_range usually copies at most 2GB segments on ZFS,
however it seems to be able to copy more at once when copying
ation agree in the end.
Likewise for xcp(1), which uses copy_file_range in 1MB blocks by
default and does not care for holes.
Thus I think this is a logic bug in cp and not a ZFS issue.
Do not hesitate to contact me if you inquire further details.
I haven't tried to repro yet.
The syscalls
which uses copy_file_range in 1MB blocks by
default and does not care for holes.
Thus I think this is a logic bug in cp and not a ZFS issue.
Do not hesitate to contact me if you inquire further details.
Thanks,
--
Leah Neukirchenhttps://leahneukirchen.org/
tags 79118 fixed
close 79118
stop
Collin Funk writes:
> Bruno Haible writes:
>
>> There are basically two ways to fix this:
>> (a) set the appropriate environment variables (instead of setlocale calls),
>> (b) add an nstrftime_l and fprintftime_l variant and pass a locale that
>> has
Bruno Haible writes:
> There are basically two ways to fix this:
> (a) set the appropriate environment variables (instead of setlocale calls),
> (b) add an nstrftime_l and fprintftime_l variant and pass a locale that
> has "C" for the LC_TIME category.
>
> (b) is more hairy, when it com
Collin Funk wrote in
https://lists.gnu.org/archive/html/bug-gnulib/2025-07/msg00214.html:
> This part of the function body of
> gl_locale_name_environ should make it clear:
>
> /* Setting of LC_ALL overrides all other. */
> retval = getenv ("LC_ALL");
>
On 30/07/2025 22:51, Pádraig Brady wrote:
On 30/07/2025 09:05, Martin D Kealey wrote:
I would like the 'chown -h' and 'chcon -h' to work the same way as
'touch -h': as well as not following symlinks for targets, they should also
not follow a symlink given as --reference=.
For consistency it pr
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
On 30/07/2025 09:05, Martin D Kealey wrote:
I would like the 'chown -h' and 'chcon -h' to work the same way as
'touch -h': as well as not following symlinks for targets, they should also
not follow a symlink given as --reference=.
For consistency it probably makes sense for `chmod -h` to also
n
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
On 2025-07-30 01:05, Martin D Kealey wrote:
I would like the 'chown -h' and 'chcon -h' to work the same way as
'touch -h': as well as not following symlinks for targets, they should also
not follow a symlink given as --reference=.
Makes sense to me. Let's see what others think.
If the patch is
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
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
e 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
ther 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).
I searched the archives and it appears there was a related discussion in
bug#61720 <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61720>, but that
focused on aligning the documentation with the behaviour rather than the
other way around.
I've been using touch+chown+chmod+chc
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
S
+++ b/NEWS
@@ -7,6 +7,9 @@ GNU coreutils NEWS-*- outline -*-
'factor' is now much faster at identifying large prime numbers,
and significantly faster on composite numbers greater than 2^128.
+ 'pr -f' with the POSIXLY_CORRECT enviro
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 checkin
LURE, 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 a
On 29/07/2025 06:02, Jeffery Palm wrote:
I took a look at this bug, and believe I have a patch that will resolve it.
$ ../src/date --debug -d '2024-01-01 8:00:00PM -0500'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00pm UTC-05
date: input timezone: parsed
ur 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 bene
I took a look at this bug, and believe I have a patch that will resolve it.
$ ../src/date --debug -d '2024-01-01 8:00:00PM -0500'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00pm UTC-05
date: input timezone: parsed date/time string (-05)
date: using specifi
6 +7,9 @@ GNU coreutils NEWS-*- outline -*-
'factor' is now much faster at identifying large prime numbers,
and significantly faster on composite numbers greater than 2^128.
+ 'pr -f' with the POSIXLY_CORRECT environment variable set wi
On Tue, 29 Jul 2025 at 06:12, Pádraig Brady wrote:
>
> On 28/07/2025 20:13, Pádraig Brady wrote:
> > On 28/07/2025 18:49, Nicolas Boichat wrote:
> >> I could have been clearer for this last one, I mean that the command
> >> line error text for `du` could mention that +FORMAT is supported:
> >>
> >
Hi Collin,
What if you replace
setlocale (LC_TIME, "C");
with
{
xsetenv ("LC_TIME", "C", 1);
setlocale (LC_TIME, "");
}
? I'm asking because in localename-unsafe.c, HAVE_LOCALE_NULL is not set
on macOS. Does that make any difference?
Bruno
Hi Bruno,
Collin Funk writes:
> The issue is that they return the non-C locale date. The code we use
> when --iso-8601 or --rfc-3339 is in use is the following:
>
> if (use_c_locale)
> setlocale (LC_TIME, "C");
>
> bool ok = show_date (format, when, tz);
>
> I wonder if the issue i
Collin Funk writes:
>> + case $(date --iso-8601=hours) in
>> ++ date --iso-8601=hours
>> + fail=1
>> + case $(date --rfc-3339=date) in
>> ++ date --rfc-3339=date
>> + fail=1
>
> My guess is that `date ...` or a separate assignment will be needed
> here. Will experiment later.
Scratch that, I rea
On 28/07/2025 20:13, Pádraig Brady wrote:
On 28/07/2025 18:49, Nicolas Boichat wrote:
I could have been clearer for this last one, I mean that the command
line error text for `du` could mention that +FORMAT is supported:
Comparing du and ls output with a bad timestyle:
```
$ du --time --time-st
Hi Bruno,
Bruno Haible via GNU coreutils Bug Reports
writes:
> Today's CI run reports that the new tests
> tests/date/date-ethiopia
> tests/date/date-iran
> tests/date/date-thailand
> fail on OpenBSD and macOS.
Thanks for the report. I'll fix them later tod
Hi Collin,
Today's CI run reports that the new tests
tests/date/date-ethiopia
tests/date/date-iran
tests/date/date-thailand
fail on OpenBSD and macOS.
On OpenBSD, that's expected, because gnulib/lib/strftime.c does not
enable the non-Gregorian calendars on that system (because retrieving
th
On 28/07/2025 18:49, Nicolas Boichat wrote:
I could have been clearer for this last one, I mean that the command
line error text for `du` could mention that +FORMAT is supported:
Comparing du and ls output with a bad timestyle:
```
$ du --time --time-style=xyz blob
du: invalid argument ‘xyz’ for
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
On Tue, 29 Jul 2025 at 00:07, Pádraig Brady wrote:
>
> tag 79113 notabug
> close 79113
> stop
>
> On 28/07/2025 15:44, Nicolas Boichat wrote:
> > Hi,
> >
> > Version: env du --version => du (GNU coreutils) 9.7
> > OS: archlinux, x86-64
> >
> > The GNU coreutils manual says
> > (https://www.gnu.org
XLY_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
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.opengro
ehavior 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 b
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
---^^^
tag 79113 notabug
close 79113
stop
On 28/07/2025 15:44, Nicolas Boichat wrote:
Hi,
Version: env du --version => du (GNU coreutils) 9.7
OS: archlinux, x86-64
The GNU coreutils manual says
(https://www.gnu.org/software/coreutils/manual/coreutils.html#index-_002d_002dtime_002dstyle-1):
- "You can
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
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
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
Hi,
Version: env du --version => du (GNU coreutils) 9.7
OS: archlinux, x86-64
The GNU coreutils manual says
(https://www.gnu.org/software/coreutils/manual/coreutils.html#index-_002d_002dtime_002dstyle-1):
- "You can specify the default value of the --time-style option with
the environment variabl
>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
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
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 '
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
>>As this is not a bug I'll be bold and close the bug report.
>
> Quite so. It'd be nice if there as some way to prevent the system from
> assigning a
> bug number. I.e., some kind of code you could put in your email to say "This
> is not
> a bug; it is
On 2025-07-27 18:10, Stan Marsh wrote:
Just out of curiosity, why is shred obsolete?
Oh, that's a long story. Some of it is covered in the manual here:
https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html
but that's a bit out of date. Here's something that's more up-t
t being actively maintained and improved".
I really don't think any of these utilities are "obsolete" (by my definition).
>As this is not a bug I'll be bold and close the bug report.
Quite so. It'd be nice if there as some way to prevent the system from
assigning
On 2025-07-27 17:26, Stan Marsh wrote:
Just out of curiosity, I note that you (Paul) say that "pr" is "obsolete".
This surprises me, since I still use it every day.
I'm not proposing that we remove pr, just that it's not high priority.
As this is not a bug
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
Just out of curiosity, I note that you (Paul) say that "pr" is "obsolete".
This surprises me, since I still use it every day. I find that, like a lot
of the old style Unix utilities, it does what it says it does and that's
good enough for me.
In other words, you might then say the same thing (th
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
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
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
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
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
time saved by not
proving primality of found factors.
You might want mention that in the header about the 2025 improvements.
Thanks for the review and for the kind words. I installed the attached
further doc fix and am closing this bug report.
From 4a2402dcfa8b705b63f43b76d7be8418e08f8f8f Mon
Thank you for merging the new mpn-based factoring code!
The code looks good, I did not see anything which needs improvements.
I believe the factoring speedup for numbers of 3 or more limb is quite
significant (2x-3x), even when not considering the time saved by not
proving primality of found fact
>Maybe the -d option better suits your case then?
> $ du -xchd 1 ~
Yes, that is nice. Thanks!
(So many options; so little time to learn them all...)
>Arguably, this doesn't skip "dot" files and directories, as the usual shell
>globbing with '*' does.
True, but I think I can live with that.
On 7/25/25 20:25, Stan Marsh wrote:
With "du", I prefer using ~/* instead of just ~ because then you get totals for
each
(top-level) directory instead of just one grand total. And you get output as
you go,
not just at the very end (after a long wait/delay).
With 'du -sxc ~/*', you explicitly
Hi,
I think this test might often be skipped due to lack of filesystem
support? Let's try a bit harder to run it.
And let's test past timestamps too.
Thanks!
Log:
## tests: du/bigtime: Try harder to find a suitable filesystem
At least on Linux, the "usual" filesystem (ext4) doesn't support
such
Hi Paul,
Paul Eggert writes:
> +case NT_BINOP: case OT_BINOP:
> + {
> +if (l_is_l | r_is_l)
> + test_syntax_error (_("%s does not accept -l"), argv[op]);
This causes 'make syntax-check' to fail with the following:
error_quotes
test.c:332: test_synta
but still exclude
things
sub-mounted under /mountpoint.
Or there could an entirely new options - maybe -X (capital X).
Anyway, just an idea. My specific problem is solved and is not a bug.
>It sounds like we have a feature request here for a new option, which would
>behave
>the way you lik
a feature request here for a new option, which
would behave the way you like. So I have marked the bug report as a
wishlist item. Not sure whether it's worth implementing
Thanks for checking that. I installed your patch into the master branch
on savannah.gnu.org, and am marking this bug report as done.
To help make this sort of auditing easier in the future, I installed the
attached followup patch too.From 3c40470c5da5cdfdc3dd94d4d820df873898ad43 Mon Sep 17 00
> When the glob is expanded, $HOME/sshfs_mount ends up being one of the args
> to `du' so it seems not surprising that the directory is processed.
Yeah, you're probably right, now that I think about it.
With "du", I prefer using ~/* instead of just ~ because then you get totals for
each
(top-lev
Hi Stan,
Haven't gotten a chance to read through the original report yet, but...
Stan Marsh writes:
> By the way, and just out of curiosity, what method does "du" use to figure
> out if
> something is a mountpoint (and thus to be skipped if -x was supplied on the
> cmd line) ?
We have a func
> Thanks for reporting it. Can you use 'strace' to find out which system call is
> hanging? That would help isolate whether the bug is in 'du' or is in the
> kernel.
It may have been imprecise of me to say it "hung" - in the sense of hanging on a
singl
On Fri, Jul 25, 2025, 12:02 Stan Marsh wrote:
>
> I used the following command to check disk usage in ~:
>
> $ du -sxc ~/*
>
> Unfortunately, this hung when it hit the directory ~/sshfs_mount, which is
> sshfs
> mounted to my home dir on some other system.
>
When the glob is expanded, $HOME/ssh
Thanks for reporting it. Can you use 'strace' to find out which system
call is hanging? That would help isolate whether the bug is in 'du' or
is in the kernel.
At some point we might ask whether you can reproduce the bug with the
latest stable Coreutils
<https://ft
mitted by law.
Written by Torbjorn Granlund, David MacKenzie, Paul Eggert,
and Jim Meyering.
$
Admittedly, this is pretty old. If the bug I am about to describe is already
fixed,
please let me know.
I used the following command to check disk usage in ~:
$ du -sxc ~/*
Unfortunately, thi
Hello,
This is my first patch contribution to GNU coreutils. It removes dead code
related to unrecognized binary operators in test.c. The fallback error was
unreachable because invalid binary operators are filtered earlier in the
logic.
I’ve attached the patch file to this email.
Please let me k
On 2025-07-23 08:25, Kent Dorfman wrote:
feel free to call this tabs issue closed/shelved.
Thanks, closing.
On 7/21/25 10:39, Paul Eggert wrote:
I can't reproduce the problem with coreutils 9.7, the current version.
Please try the following:
* Run "tabs -4" *after* changing the xterm window size.
* Upgrade to Coreutils 9.7.
* Run 'stty -a' and make sure its output agrees with the actual xterm
siz
1 - 100 of 17484 matches
Mail list logo
