bug#62385: POSIX behavior of readlink, realpath

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

bug#62385: POSIX behavior of readlink, realpath

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:

bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch

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

bug#79139: cp --reflink truncates sparse files on ZFS

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 doing i

bug#79139: cp --reflink truncates sparse files on ZFS

On 01/08/2025 18:33, Leah Neukirchen wrote: 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 see

bug#79139: cp --reflink truncates sparse files on ZFS

On 01/08/2025 16:00, Leah Neukirchen wrote: Hello, I found the following issue with coreutils 9.7, Linux 6.12.40-1-lts, zfs 2.3.3 on Arch x86_64, glibc 2.42: Copying a file with sparse holes using "cp --reflink=auto" truncates the file before the final segment. The relevant strace is: openat(

bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch

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

bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch

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

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 standard

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#18328: can't say date -d '8pm -0500' though other combos work

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 date/time s

bug#79113: du --time-styles inconsistencies between manual and behaviour

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

bug#79113: du --time-styles inconsistencies between manual and behaviour

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

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#79113: du --time-styles inconsistencies between manual and behaviour

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

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

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

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#79078: date command: Relative dates fail with ISO 8601 time format and no zone

tag 79078 notabug close 79078 stop Notes below... On 23/07/2025 08:56, Geoff Kuenning via GNU coreutils Bug Reports wrote: Tested on coreutils 9.5 (gentoo) and 8.32 (OpenSuSE). There seems to be an interesting interaction in the code that parses relative dates in the --date switch; relative sp

bug#79072: install -d onto readonly fs prints the wrong error

On 22/07/2025 20:17, Paul Eggert wrote: Thanks for reporting that inaccurate diagnostic. Sorry about the tricky code; it's a tricky situation. Looks like Collin's patch is not quite right. I installed the attached patches into Gnulib. The first one fixes the two cases you mentioned, the second a

bug#79034: id -nG not working nor id USERNAME

On 16/07/2025 11:22, Michael Colvin wrote: [image: image.png] Hope this helps So `id` is behaving like `id --help`. That suggests the getopt_long() used on your system is returning CHAR_MIN-2 always. thanks, Padraig.

bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

On 12/07/2025 16:53, Paul Eggert wrote: On 2025-07-12 04:45, Pádraig Brady wrote: -  : a == b ? 0 +  : a == b ? numcompare (sa, sb) That fails for string pairs like "10" and "1e1". Hah I thought of that but missed this impacts the --unique case. I added a

bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

On 12/07/2025 04:59, Collin Funk wrote: Collin Funk writes: Oh, right. Thanks. I installed the attached further patch to fix that. This is cleaner anyway. This test still fails on cfarm110 for me, logs attached. I was looking at it the other day, but was unable to get a working version. I'

bug#78960: VPATH build fails

On 05/07/2025 15:54, Bruno Haible wrote: Pádraig Brady wrote: I pushed the following which passes both types of builds here. Marking this as done. cheers, Padraig diff --git a/src/local.mk b/src/local.mk index 537032578..fb763c4db 100644 --- a/src/local.mk +++ b/src/local.mk @@ -708,7 +708,7

bug#78960: VPATH build fails

On 05/07/2025 10:59, Bruno Haible via GNU coreutils Bug Reports wrote: Hi, The coreutils CI build part that does a "make distcheck" today fails, whereas on 2025-06-30 it succeeded [1]. The problem can be reproduced as follows: 1) $ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR $ ./config

bug#76255: cat: error without arguments

On 15/02/2025 06:22, Paul Eggert wrote: On 2025-02-12 22:45, lilydjwg wrote: cat: -: input file is output file Thanks for the bug report. The symptoms you observe are a bug in 'cat'. I also see a bug in Gawk which I reported to the Gawk maintainer

bug#78934: test failure after recent 'od' changes

On 30/06/2025 20:47, Bruno Haible via GNU coreutils Bug Reports wrote: After this week's changes in 'od', the CI reports a test failure on OpenBSD and Solaris: FAIL: tests/od/od Ah right, strerror(ERANGE) varies by platform. I'll push the attached later to address this. Marking this as done.

bug#78880: od Heap-buffer overflow

On 30/06/2025 01:25, Paul Eggert wrote: On 2025-06-29 12:59, Pádraig Brady wrote: I've manually suppressed that error instance in our coverity instance. Maybe the change I just installed removed the need for that manual suppression? Indeed it does. I checked with ./conf

bug#78910: tail does not support -r added by POSIX.1-2024

On 30/06/2025 00:42, Bruno Haible via GNU coreutils Bug Reports wrote: Jim Meyering wrote: That is an option no GNU system needs, since they've all had tac since before 1992-era textutils. But 'tac' does not have a line-number-limit argument. The POSIX rationale [1] has "While both

bug#78880: od Heap-buffer overflow

On 29/06/2025 13:17, Pádraig Brady wrote: On 29/06/2025 05:25, Paul Eggert wrote: > od: omit some duplicate code > On x86-64 (for example) print_long, print_long_long, and > print_intmax all behave identically, so give GCC enough info so > that it generates code for just

bug#78880: od Heap-buffer overflow

On 29/06/2025 05:25, Paul Eggert wrote: > od: omit some duplicate code > On x86-64 (for example) print_long, print_long_long, and > print_intmax all behave identically, so give GCC enough info so > that it generates code for just one of these functions. > * src/od.c (enum size_spec): Arrange for

bug#78910: tail does not support -r added by POSIX.1-2024

On 27/06/2025 20:16, Collin Funk wrote: Hi Jim and Pádraig, Jim Meyering writes: tail -r comes from the BSDs. Also the BSDs don't have tac(1) which overlaps in functionality quite a bit. I'm a bit surprised -r was added by POSIX, but fair enough. "Surprised" is putting it lightly. I am disa

bug#78910: tail does not support -r added by POSIX.1-2024

On 27/06/2025 10:10, Pádraig Brady wrote: On 27/06/2025 06:36, Collin Funk wrote: Creating this bug report since I have not been able to create a working implementation yet, and perhaps my looking into this will inspire others thoughts... POSIX-1.2024 adds the following SYNOPSIS for 'tai

bug#78910: tail does not support -r added by POSIX.1-2024

On 27/06/2025 06:36, Collin Funk wrote: Creating this bug report since I have not been able to create a working implementation yet, and perhaps my looking into this will inspire others thoughts... POSIX-1.2024 adds the following SYNOPSIS for 'tail' [1]: tail [-f] [-c number|-n number] [fil

bug#78880: od Heap-buffer overflow

On 24/06/2025 15:27, Grisha Levit wrote: This part: tryline: + idx_t i = 0; + int c = 1; /* Init to 1 so can distinguish if NUL read. */ triggers warning: label followed by a declaration is a C23 extension [-Wc23-extensions] OK version 3 attached which simplif

bug#78879: Potential Out-of-Memory in coreutils od

On 24/06/2025 16:29, Philip Rowlands wrote: Small typo in + 'od -w foo' will now issue a diagnostic an exit. Cool, I'd already changed that locally to: 'od -w0' will now issue a diagnostic and exit gracefully. Marking this bug done. thanks! Padraig

bug#78879: Potential Out-of-Memory in coreutils od

On 23/06/2025 09:21, Jaehoon Jang wrote: Potential Out-of-Memory Risk in coreutils od Due to Inadequate Argument Validation for -w Option *Description* ``` $ src/od -w0 /bin/ls Aborted ``` Well we shouldn't be aborting at least. The attached patch should avoid that. thanks, Padraig From 7778

bug#78880: od Heap-buffer overflow

On 24/06/2025 01:16, Pádraig Brady wrote: On 23/06/2025 09:24, Jaehoon Jang wrote: = ==1151699==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615004f9 at pc 0x004d153f bp 0x7fff937f0410 sp 0x7fff937f0408 WRITE

bug#78880: od Heap-buffer overflow

On 23/06/2025 09:24, Jaehoon Jang wrote: = ==1151699==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615004f9 at pc 0x004d153f bp 0x7fff937f0410 sp 0x7fff937f0408 WRITE of size 1 at 0x615004f9 thread T0 #

bug#78882: stty.c compilation error

On 23/06/2025 22:14, Bruno Haible via GNU coreutils Bug Reports wrote: Hi, The coreutils CI fails today on OpenBSD and Solaris. (The previous build, a week ago, succeeded.) With OpenBSD sed and Solaris sed: $ echo 100 | sed -e 's/^.*$/# ifdef B&\n case B&: return &;\n# endif/' # ifde

bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On 04/06/2025 12:55, Gael Donval wrote: On 30/05/2025 18:16, Paul Eggert wrote: On 2025-05-30 02:37, Pádraig Brady wrote: we only have this issue with --preserve=xattr which diagnoses any issues. Perhaps we would benefit from a --preserve=supported-xattr option? If we go that route, it might

bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On 30/05/2025 18:16, Paul Eggert wrote: On 2025-05-30 02:37, Pádraig Brady wrote: we only have this issue with --preserve=xattr which diagnoses any issues. Perhaps we would benefit from a --preserve=supported-xattr option? If we go that route, it might be a bit better if the new option-arg

bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On 30/05/2025 10:02, Gael Donval wrote: Ok, I've done that and you were right. I guess BTRFS implements its file attributes as extended attributes. The relevant part of the strace is this: openat(AT_FDCWD, "btrfs/baz", O_RDONLY) = 4 openat(3, "baz", O_WRONLY|O_CREAT|O_EXCL, 0644) = 5 flistxattr(

bug#78628: Typo in cat synopsis?

On 29/05/2025 14:39, A Kiloev wrote: Hi, i am not sure is it a typo, but shouldn't be ellipsis after OPTION in cat synopsis* https://www.gnu.org/software/coreutils/manual/coreutils.html#cat-invocation ?* I asked before

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 29/05/2025 12:20, Peter Dyballa wrote: Am 29.05.2025 um 13:08 schrieb Pádraig Brady : OK that does suggest the configure test isn't sufficient here (Nor the patch to that I sent previously). I built *without* it, assuming the updated sources would contain it. Should I try again

bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On 29/05/2025 10:56, Gael Donval wrote: On Thu, 2025-05-29 at 10:10 +0100, Pádraig Brady wrote: On 28/05/2025 16:14, Gael Donval wrote: Dear list, We've unearth an odd behaviour in cp: `cp --preserve=xattr` tries to copy both attributes of the chattr kind and extended attributes o

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 29/05/2025 10:54, Peter Dyballa wrote: Am 29.05.2025 um 11:06 schrieb Pádraig Brady : :59:2: error: instruction requires: AVX-512 ISA vmovdqa64 lC0(%rip), %zmm0 ^ The above suggests that `/opt/local/bin/gcc-mp-14 -std=gnu23 ... -mavx512bw

bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On 28/05/2025 16:14, Gael Donval wrote: Dear list, We've unearth an odd behaviour in cp: `cp --preserve=xattr` tries to copy both attributes of the chattr kind and extended attributes of the getfattr kind with apparently no way to disable either one of them (it's all or nothing). This is prob

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 29/05/2025 09:12, Peter Dyballa wrote: /opt/local/bin/gcc-mp-14 -std=gnu23 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx512bw -mavx512f -mvpclmulqdq -pipe -Os -arch x86_64 -MT src/libcksum_avx512_a-cksum_avx512.o -MD -MP -MF src/.deps/libcksum_avx512_a-cksum_avx512.Tpo

bug#78562: bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 28/05/2025 20:58, Paul Eggert wrote: On 2025-05-24 12:57, Peter Dyballa wrote: The output is: "O_DIRECTORY incorrectly succeeded!" Thanks for checking. I installed fixes to Autoconf, Gnulib and Coreutils to try to address the two bug reports and

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 24/05/2025 10:29, Peter Dyballa wrote: Am 24.05.2025 um 01:37 schrieb Pádraig Brady : I suspect the following will avoid the issue: It does not: /usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx -mpclmul -Wno-format-extra-args -Wno

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 23/05/2025 14:20, Peter Dyballa via GNU coreutils Bug Reports wrote: Hello! The compile used is Clang, Apple LLVM version 10.0.0 (clang-1000.11.45.5). The CPU built into the Mac is Intel(R) Core(TM) i7-2860QM CPU @ 2.50GHz. The error is: mv -f src/blake2/.deps/cksum-b2sum.Tpo src/b

bug#77597: listxattr() should return ENOTSUP for sysfs / tmpfs entries, not 0

On 23/04/2025 13:22, Pádraig Brady wrote: Older coreutils was less efficient and always called getxattr("security.selinux"), and thus shows the SELinux context as expected: $ coreutils-9.3/src/ls -lZd /run/initramfs drwxr-xr-x. 3 root root system_u:object_r:tmpfs_t:s0 60 Ap

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 21/05/2025 22:02, Peter Dyballa wrote: Am 21.Mai.2025 um 22:46 schrieb Pádraig Brady : I've pushed this change Some more changes might be useful: A few tests use the programme getent that neither exists in old Mac OS X nor in modern macOS… (same for diffutils, I think, I do remem

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 21/05/2025 20:13, Peter Dyballa via GNU coreutils Bug Reports wrote: Am 20.Mai.2025 um 19:10 schrieb Paul Eggert : First, please build and run coreutils 9.7 The tests stop in PASS: tests/cp/dir-vs-file.sh PASS: tests/cp/existing-perm-dir.sh at + mkfifo_or_skip_

bug#78507: [Security] Heap Buffer Overflow in GNU Coreutils sort (CWE-122)

On 20/05/2025 19:24, Paul Eggert wrote: On 2025-05-20 10:15, Pádraig Brady wrote: The attached patch addresses the issue here, and includes a test verified to trigger with ASAN or valgrind available. Thanks. A nit: the patch doesn't include the change to NEWS. Good spot. Fixed and p

bug#78507: [Security] Heap Buffer Overflow in GNU Coreutils sort (CWE-122)

On 20/05/2025 16:15, Pádraig Brady wrote: Indeed. I introduced this in coreutils 7.2 (2009). One can repro on Fedora for e.g. with: _POSIX2_VERSION=200809 LC_ALL=C valgrind sort +0.18446744073709551615R poc_input.txt ==984625== Memcheck, a memory error detector ==984625== Using Valgrind-3.24.0

bug#78507: [Security] Heap Buffer Overflow in GNU Coreutils sort (CWE-122)

On 20/05/2025 10:31, Med Maatallah wrote: Dear GNU Coreutils Maintainers, I am reporting a heap buffer overflow vulnerability (CWE-122) I've discovered in the GNU Coreutils sort utility. This issue affects the traditional key specification syntax processing and leads to an out-of-bounds read. Vu

bug#78377: Cross-Compile - "src/make-prime-list: cannot execute: required file not found"

On 17/05/2025 04:21, Collin Funk wrote: Hi Pádraig, Pádraig Brady writes: Well given we also need to call gl_BUILD_CC perhaps the best way would be to have a separate build-cc gnulib module and have the crc module depend on that. I'm fine just depending on crc for now though, though

bug#78377: Cross-Compile - "src/make-prime-list: cannot execute: required file not found"

On 16/05/2025 06:36, Collin Funk wrote: Hi Paul, Paul Eggert writes: Yes, that should work, so long as the build host isn't a Microsoft Windows platform that would require $(BUILD_EXEEXT). And that should be good enough; we don't need the full power of AX_PROG_CC_FOR_BUILD from the Autoconf A

bug#78431: Unclear patch submission address

On 14/05/2025 21:40, Paul Eggert wrote: On 2025-05-14 12:53, Collin Funk wrote: I think that adding an email regardless would be good Yes, now's a good time to revisit the decision in 2013 to remove the bug-reporting email address[1]. Plus, the current code is confusing. How about the attache

bug#78377: Cross-Compile - "src/make-prime-list: cannot execute: required file not found"

forcemerge 12741 78377 stop On 11/05/2025 16:26, NR wrote: It'd be nice to be able to cross-compile coreutils. It could be done by detecting if `--host=` is different from the build system. If it is different, then make the `src/primes.h` target natively (specifically the `src/make-prime-list`

bug#78398: sc_gitignore_missing failure

ommit bd8be6b99ed73df0e055ba4e12bbf78c41a472c6 (HEAD -> master)Author: Pádraig Brady Date: Mon May 12 23:20:43 2025 +0100 maint: avoid sc_gitignore_missing failure * .gitignore: Add the soon to be generated lib/fts_.h * cfg.mk (sc_gitignore_missing): Special case the mapping of fts.in.h to fts_.h. Fix

bug#78328: Copy fails setting system.nfs4_acl extended attribute [cp (GNU coreutils) 9.7.7-6218c]

On 09/05/2025 06:06, Ian Dall wrote: Here, /var/tmp is on an nfs4 filesystem and /tmp is a tmpfs filesystem. $ touch /var/tmp/foo $ cp -p /var/tmp/foo /tmp cp: preserving permissions for ‘/tmp/foo’: Operation not supported --preserve=mode has the same result --no-preserve=xattr has n

bug#78245: rm -d fails to remove non-empty directory

On 04/05/2025 11:35, Yannick Le Pennec wrote: Dear Maintainer, On CephFS, creating a snapshot is done suchly: $ mkdir .snap/snapshot-name This creates a directory which contains a view of the current directory at the time the snapshot was created, and is therefore non-empty if the current di

bug#78244: Exit code 4 whilst installing util-linux-selinux on arch

On 04/05/2025 10:49, Jdj asd wrote: Hello! I was trying to install util-linux-selinux which would've replaced a core package when I got exit code 4. I tried running it as root and with git clone but I was always getting this error and this email to report the issue to. Thanks for the help in adva

bug#78225: Testsuite failure relating to chgrp in (unprivileged) user namespaces

On 03/05/2025 04:38, keinflue wrote: Hello, noticed this on Guix (https://issues.guix.gnu.org/77862#5) with coreutils 9.1 and also verified with latest release 9.7. When building and running the testsuite of coreutils on Linux in a user namespace as unprivileged user the latter may fail chgrp t

bug#77597: listxattr() should return ENOTSUP for sysfs / tmpfs entries, not 0

Older coreutils was less efficient and always called getxattr("security.selinux"), and thus shows the SELinux context as expected: $ coreutils-9.3/src/ls -lZd /run/initramfs drwxr-xr-x. 3 root root system_u:object_r:tmpfs_t:s0 60 Apr 19 14:52 /run/initramfs $ coreutils-9.3/src/ls -lZd /sy

bug#77934: bug: md5sum: Escaped backslashes in filename got in stdout

tag 77934 notabug close 77934 stop On 20/04/2025 00:44, William Johnson via GNU coreutils Bug Reports wrote: Hello. I would like to report a bug for md5sum coreutil. If filename has ‘\t’ in filename, stdout for md5sum result will start with backslash symbol. * My version of md5sum util: md

bug#77622: coreutils-9.6.53-14af8 on Solaris 11 OpenIndiana

On 11/04/2025 23:22, Bruno Haible via GNU coreutils Bug Reports wrote: On Solaris OpenIndiana, there is one test failure: FAIL: tests/misc/numfmt Specifically, the tests lcl-fmt-2, lcl-fmt-3 fail. See the attached log file. I can easily reproduce it: $ LC_ALL=fr_FR.UTF-8 src/numfmt --format

bug#77621: coreutils-9.6.53-14af8 on OpenBSD 7.6

On 08/04/2025 11:22, Bruno Haible wrote: Paul Eggert wrote: I don't see the problem on cfarm220.cfarm.net with the current coreutils That's because you are not on the /dev/wd0a disk on that machine. What I see by single-stepping through "ls -Z ." in gdb is: 1. f->scontext gets set to "?". 2.

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 08/04/2025 08:06, Paul Eggert wrote: On 2025-04-07 15:52, Pádraig Brady wrote: So maybe we class this as a kernel bug and have the kernel return non 0 for this case, or even ENOTSUP. Yes, this sounds right to me. The kernel should not pretend that there are no attributes when there are

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 07/04/2025 19:22, Pádraig Brady wrote: On 07/04/2025 19:03, Pádraig Brady wrote: On 06/04/2025 02:49, Rahul Sandhu wrote: Hey, coreutils 9.6 appears to have a regression in `ls(1)` for SELinux-aware builds. `ls -Z` fails to obtain the security context for certain filesystem objects (e.g

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 07/04/2025 23:10, Paul Eggert wrote: On 4/5/25 18:49, Rahul Sandhu wrote: the security context xattr only shows when specifically requesting it by passing the arguments -n 'security.selinux' to the command line: rsandhu@graphite ~ $ getfattr -d -m '' /run/credentials rsandhu@graphite ~ $ ge

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 08/04/2025 08:06, Paul Eggert wrote: On 2025-04-07 15:52, Pádraig Brady wrote: So maybe we class this as a kernel bug and have the kernel return non 0 for this case, or even ENOTSUP. Yes, this sounds right to me. The kernel should not pretend that there are no attributes when there are

bug#77621: coreutils-9.6.53-14af8 on OpenBSD 7.6

On 07/04/2025 23:41, Bruno Haible via GNU coreutils Bug Reports wrote: On OpenBSD 7.6 there is a test failure: FAIL: tests/ls/selinux-segfault Find attached the log file. To reproduce the issue, just run $ src/ls -Z . Segmentation fault (core dumped) It crashes at strlen(), due to a NULL arg

bug#77535: timeout treats very short durations as `0`

On 07/04/2025 09:08, Paul Eggert wrote: On 2025-04-05 13:56, Pádraig Brady wrote: I'm going to apply the attached later to remove the libm dependency. It's just too much of a dependency for minimal functionality. Thanks, agreed about the dependency. Still, 'timeout' (a

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 07/04/2025 19:03, Pádraig Brady wrote: On 06/04/2025 02:49, Rahul Sandhu wrote: Hey, coreutils 9.6 appears to have a regression in `ls(1)` for SELinux-aware builds. `ls -Z` fails to obtain the security context for certain filesystem objects (e.g. `/sys`). Example to reproduce on Gentoo with

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 06/04/2025 02:49, Rahul Sandhu wrote: Hey, coreutils 9.6 appears to have a regression in `ls(1)` for SELinux-aware builds. `ls -Z` fails to obtain the security context for certain filesystem objects (e.g. `/sys`). Example to reproduce on Gentoo with refpolicy: rsandhu@graphite ~ $ ls -alZ /r

bug#77535: timeout treats very short durations as `0`

On 07/04/2025 09:23, Paul Eggert wrote: On 2025-04-05 12:41, Pádraig Brady wrote: +Note it's best to avoid combining suffixes with hexadecimal arguments, +as any @samp{d} will @emph{not} be interpreted as a suffix. But 'd' is interpreted as a suffix with hexadecimal argumen

bug#77535: timeout treats very short durations as `0`

On 05/04/2025 12:03, Pádraig Brady wrote: On 05/04/2025 09:03, Paul Eggert wrote: On 2025-04-04 12:27, Pádraig Brady wrote: +  /* Clamp underflow to 1ns, as 0 disables the timeout.  */ +  if (duration == 0 && errno == ERANGE) +    duration = 1e-9; That isn't exactly right as th

bug#77535: timeout treats very short durations as `0`

On 05/04/2025 19:45, Pádraig Brady wrote: On 05/04/2025 19:02, Philip Rowlands wrote: I was interested to see that the code makes uses of strtod, and how this interacts with the minute / hour / day suffix. $ strace -e trace=clock_nanosleep sleep 3 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=3

bug#77535: timeout treats very short durations as `0`

On 05/04/2025 19:02, Philip Rowlands wrote: I was interested to see that the code makes uses of strtod, and how this interacts with the minute / hour / day suffix. $ strace -e trace=clock_nanosleep sleep 3 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=3, tv_nsec=0}, $ strace -e trace=clock_nanosl

bug#77252: 回复： bug#77252: cat lost content when used in cmd.exe

tag 77252 notabug close 77252 stop On 26/03/2025 07:43, anmikf wrote: 在Git for windows的Git Bash里面执行`cat catbug`,文件内容能完全显示。 但是在Win10的cmd.exe里面执行`"C:\Program Files\Git\usr\bin\cat.exe" catbug`,文件内容不能完全显示，会丢失第51367行的字符'B'，经过测试发现会丢失第1900544个字节。 Execute `cat catbug` in Git B

bug#77535: timeout treats very short durations as `0`

On 05/04/2025 09:03, Paul Eggert wrote: On 2025-04-04 12:27, Pádraig Brady wrote: +  /* Clamp underflow to 1ns, as 0 disables the timeout.  */ +  if (duration == 0 && errno == ERANGE) +    duration = 1e-9; That isn't exactly right as the 1e-9 double-rounds to 2e-9 when we compu

bug#77509: 1 failure with "make check"

h the following should avoid. Marking this as done. thanks, Padraig. commit 9ed5770b5e86bd765c607bc9375f0db78acf4687 (HEAD -> master) Author: Pádraig Brady Date: Fri Apr 4 11:53:10 2025 +0100 tests: fix false failure with multi-byte thousands separators * tests/sort/sort-h-thousand

bug#77535: timeout treats very short durations as `0`

On 04/04/2025 16:26, Nicolas Boichat wrote: Hi, Version: timeout (GNU coreutils) 9.6, Archlinux, x86-64. While playing with different duration parameters to `timeout`, I noticed that extremely short durations, like `1e-3000`, are rounded down to `0`. The problem is that `0` has a special meanin

bug#77252: cat lost content when used in cmd.exe

On 25/03/2025 07:55, anmikf via GNU coreutils Bug Reports wrote: English is not my native language; please excuse typing errors.please read attachment "catbug" That's too large a file to send to a mailing list really. In essence the data is this I think: { yes 88

bug#77179: seq incorrectly(?) pads output when last parameter magnitude larger than last printed number

On 22/03/2025 12:36, Nicolas Boichat wrote: Hi, Version: seq (GNU coreutils) 9.6; OS: Archlinux, x86-64 When adding `-w` parameter, we want numbers to be padded with leading 0s, e.g. this looks correct: $ seq -w 0 5 10 00 05 10 However, the behaviour is perhaps incorrect when the last printed

bug#77163: id --name

On 22/03/2025 05:50, Dan Jacobson wrote: $ id --name id: cannot print only names or real IDs in default format Say: id: --name needs --user or ... https://github.com/coreutils/coreutils/commit/3160f8bfa Marking this as done. thanks, Pádraig

bug#77162: man id -ugG

On 22/03/2025 05:48, Dan Jacobson wrote: Man id says: -n, --name print a name instead of a number, for -ugG -r, --real print the real ID instead of the effective ID, with -ugG Better say: -n, --name print a name instead of a

bug#77129: Upgrade security in who.c

On 20/03/2025 07:42, Alex PWN wrote: Hi, my name is Alex Feklin (PwnToday). In coreutils I found interesting vulnerability in who.c " err = asprintf (&buf, "%-8s" "%s" " %-12s" " %-*s" "%s" "%s" " %-8s" "%s" , user ? user : " .", include_mes

bug#76876: logname output is often wrong when linked with glibc

On 09/03/2025 11:08, Bruno Haible via Gnulib discussion list wrote: I wrote: With this, coreutils should be fine, since it already imports the 'getlogin' module from gnulib. Verified by comparing coreutils-9.5 with coreutils-HEAD on Alpine Linux 3.20: With coreutils-9.5: $ logname bruno $ su

bug#76743: BUGGY "cut" and "printf" with func arg $@

tag 76743 notabug close 76743 stop On 04/03/2025 14:24, G.K. wrote: HI THERE any bash code to described the buggy form attachment pic displayed standardout https://www.facebook.com/100013673347475/posts/2029907180808374 I'AM USED TERMUX , ANDROID 11 ON FON GS4 #1 echo -e "1\n2\n3\n4"''

bug#76702: coreutils 9.1 cp --parents --preserve /dir/file fstat relative dir

On 02/03/2025 15:18, Alan J. Goalby wrote: When "cp --parents --preserve /dir/file /target/" needs to create /target/dir/, it appears to try to Fstat information from relative path "dir", not the actual parent path "/dir". E.g., "cd /tmp && mkdir NewDir && cp -a --parents /etc/passwd NewDir" wil

bug#76409: Failure in parallel make?

On 19/02/2025 00:29, Collin Funk wrote: "Philip Rowlands" writes: Is there a dependency problem in the generated Makefile? FWIW I see similar errors trying to build src/cp and src/mv. src/sort$(EXEEXT): $(src_sort_OBJECTS) $(src_sort_DEPENDENCIES) $(EXTRA_src_sort_DEPENDENCIES) src/$(am__di

bug#74107: bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On 03/02/2025 06:24, Brendan O'Dea wrote: On Fri, Dec 13, 2024 at 02:13:44PM -0700, Glenn Golden wrote: While the patient is on the table, might it be possible to also look into this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74107 From what Padraig said in his response to the above re

bug#75994: "seq -w" is broken for large enough numbers

On 01/02/2025 17:43, Alexey Dobriyan wrote: coreutils 9.3, 9.5 Steps to reproduce: # 21 digits $ seq 1 1 3 1 2 3 With no -w, seq doesn't use floating poi

bug#75916: Making ls(1)'s --format clearer

On 28/01/2025 20:00, Samuel Thibault wrote: Hello, ls(1) says this about --format: --format=WORD across -x, commas -m, horizontal -x, long -l, single-column -1, verbose -l, vertical -C It was not clear at all for my students (and not for me either, actually), that it's the wo

bug#75763: is the "note " particle in sort.c needed?

On 22/01/2025 15:31, Benno Schulenberg wrote: Hi, In src/sort.c there is this piece of code: error (0, 0, _("%snumbers use %s as a decimal point in this locale"), tab == decimal_point ? "" : _("note "), quote (((char []) {decimal_point, 0}))

  1   2   3   4   5   6   7   8   9   10   >