bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin

Hi Sergei, On Fri, Apr 19, 2024 at 10:33:00PM +0100, Sergei Trofimovich wrote: > On Fri, 19 Apr 2024 00:33:52 -0700 > Paul Eggert wrote: > > > On 2024-04-18 14:52, Sergei Trofimovich wrote: > > > $ clang simple.c -o simple && echo 42 | ./simple > > > 1: ino=3009428657538693161 > > > 2: ino=30094

bug#79301: fold-spaces test failure

Collin Funk wrote: > I pushed the attached patch. Tested > in an alpine container, but I am confident it will fix the > others. Confirmed: The CI builds on Alpine Linux, macOS 15, FreeBSD 15 succeed now. Bruno

bug#79300: fold-nbsp test failure

Hi Collin, > Pushed the attatched two patches. The second fixes a 'make syntax-check' > failure. Will close this bug now. Thanks. I confirm (via today's CI run) that bug #79300 is fixed. > P.S. I actually just noticed this unchanged hunk in my diff: > > $ git ls-files | grep -E '\.[ch]' | xargs

bug#79301: fold-spaces test failure

Hi, On 2025-08-24 I wrote: > Today's CI reports a test failure > FAIL: tests/fold/fold-spaces > on several systems: > - Alpine Linux, > - macOS 13..15, > - FreeBSD 14. Sorry for the incorrect reporting: macOS 13 and 14 failed with a fold-nbsp failure (bug #79300), not a fold-spaces failur

bug#79381: patch needed after gnulib changed

Hi, There was a change today in gnulib, that requires a small change in packages that use gnulib-tool --with-tests with --makefile-name. GNU coreutils is one such package. Currently, './bootstrap' fails like this: ... autoreconf: running: automake --add-missing --copy --force-miss

bug#79366: paste -d option not accepting UTF-8

$ paste -d "␞" file1 file2 results in ␞ (U+241e) character being converted to � (U+FFFD) paste command doesn't seem to support UTF-8 characters. Regards, Avid

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On Mon, 2025-08-25 at 15:20 -0700, Paul Eggert wrote: > > > > Are you inclined to accept the time format of ISO 8601 for the display of > > UTC - or no? > > We should not change the behavior of plain 'date -u' based on any > arguments presented so far in this thread. The current behavior is >

bug#79300: fold-nbsp test failure

Collin Funk wrote: > My initial idea was to check if U+2007 FIGURE SPACE and U+00A0 NO-BREAK > SPACE are blank using grep. But apparently Solaris grep does not handle > multibyte characters. Therefore, FIGURE SPACE cannot be checked. :( I'm not sure we are talking about the same thing. I reported

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

Hey Martin On Mon, 2025-08-25 at 20:10 +1000, Martin D Kealey wrote: > Hi James > > On Mon, 25 Aug 2025, 07:33 James Feeney via GNU coreutils Bug Reports, > wrote: > > it must also be noted that "UTC" is in *Great Britain*,  > > To be honest, referring to U

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

Hi Paul, I tested with the code currently in the master branch in coreutils - top of tree respec is 4bfcf62f74b38d762ee06ceef582c326023635a9. This current code still fixes my testcase thanks ! For full reference, it contains the 3 relevant patches: commit

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

By the way, aside from properly reading what is actually on the screen, or not, it must also be noted that "UTC" is in *Great Britain*, where the local "locale" is "en-GB", and the standard time format in Great Britain is 24 hour, not 12 hour. Thereby, it seems to me that reporting UTC in 12 ho

bug#79301: fold-spaces test failure

[CCing bug-gnulib] Collin Funk wrote: > On Alpine this is because iswblank in UTF-8 locales is the same as > isblank in the C locale. This means it only returns 1 for U+0009 TAB and > U+0020 SPACE. It is allowed to behave this way. https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/func

bug#79299: nproc-quota test failure

Collin Funk wrote: > The CentOS 7 one fails because SCHED_DEADLINE is not defined by > sched.h. But it is defined in linux/sched.h. The second patch, which is > for Gnulib, fixed it in my CentOS 7 container. This patch would be fine to apply in Gnulib, except that the rationale (why do we include

bug#79301: fold-spaces test failure

Today's CI reports a test failure FAIL: tests/fold/fold-spaces on several systems: - Alpine Linux, - macOS 13..15, - FreeBSD 14. Here are the relevant parts of the log files. Alpine Linux: FAIL: tests/fold/fold-spaces + initial_cwd_=/work/coreutils-20

bug#79300: fold-nbsp test failure

Today's CI run reports FAIL: tests/fold/fold-nbsp on NetBSD 10 and Solaris 11.4. The log output in both cases is: FAIL: tests/fold/fold-nbsp == --- exp12025-08-24 06:57:52.605590760 + +++ out12025-08-24 06:57:52.607333160 + @@ -1,3 +1,3 @@ abcde

bug#79299: nproc-quota test failure

Today's CI run produces a FAIL: tests/nproc/nproc-quota on CentOS 7 and on Alpine Linux. Here are the two relevant log file portions. CentOS 7: FAIL: tests/nproc/nproc-quota = ++ initial_cwd_=/work/coreutils-2025-08-24/build +++ testdir_prefix_ +++ prin

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

Yes - that seems to fix the problem ! Thanks Paul. On Thu, Aug 21, 2025 at 4:03 PM Paul Eggert wrote: > > Thanks for the bug report. Although this part of the code is messy and > needs a revamp, in the meantime I installed the attached into the master > branch on Savannah; please give it a try.

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

Hey Pádraig On Mon, 2025-08-18 at 10:26 +0100, Pádraig Brady wrote: > tag 79261 notabug > close 79261 > stop > > ... > > I think you missed the "PM" in the output above. > > cheers, > Pádraig Yes, that's it, along with the coincidence that MDT relative to UTC is exactly 12 hours. Thanks for

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

_file.bin is sparse: ls -lh /mnt/output_file.bin du -sh /mnt/output_file.bin (the second value should be less). Now use a newly built cp command from coreutils to copy this file to a local filesystem. mkdir ~/tmp cd ~/tmp ~/src/coreutils/src/cp --reflink=never /mnt/output_file.bin nonsparse Eve

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

Arch Linux coreutils 9.7-1 $ timedatectl;date;date -u Local time: Sun 2025-08-17 09:50:24 MDT Universal time: Sun 2025-08-17 15:50:24 UTC RTC time: Sun 2025-08-17 15:50:24 Time zone: US/Mountain (MDT, -0600) System clock synchronized: yes

bug#79221: basenc triggers undefined-behaviour in mini-gmp

The CI this week reports a new test failure of the tests/basenc/basenc test, when compiled with sanitizers. How to reproduce: 1. Build the current coreutils with CC="clang -fsanitize=address,undefined,signed-integer-overflow,shift,integer-divide-by-zero -fno-sanitize-recover=unde

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

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: > Can't we make this condi

bug#79118: CI test failures

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"); > if (retval != NULL && retval[0

bug#79118: CI test failures

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

bug#79118: CI test failures

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

bug#79078: date command: Relative dates fail with ISO 8601 time format and no zone

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 specifications used with ISO 8601 base dates can give incorrect results. All tests below were run with a time zone of

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

Hi Collin, On Mon, Jul 21 2025 23:10:09 -0700, Collin Funk wrote: > diff --git a/lib/mkdir-p.c b/lib/mkdir-p.c > index f5df9843e4..fc83434655 100644 > --- a/lib/mkdir-p.c > +++ b/lib/mkdir-p.c > @@ -182,8 +182,8 @@ make_dir_parents (char *dir, > return true; > >

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

Hi, saw this on coreutils 9.7 on Alpine Linux, but it also reproduces on commit 027855dcad52d718927c3405bc7d605143e2a625. # mount -t tmpfs -o ro none /mnt # ./src/ginstall -d /mnt/foo ginstall: cannot change permissions of ‘/mnt/foo’: No such file or directory I would

bug#78960: VPATH build fails

Pádraig Brady wrote: > `make distcheck` passes here with the following, which I've just pushed. I confirm that the CI now passes again. Bruno

bug#78960: VPATH build fails

# Generates a list of macro invocations like: > # SINGLE_BINARY_PROGRAM(program_name_str, main_name) > # once for each program list on $(single_binary_progs). Note that > That's better. But now, "make distcheck" fails in a different way, namely in dist-check.mk line 127

bug#78960: VPATH build fails

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 $ ./configure $ make $ make dist 2) Unpack the tarball, cd into its dir

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

On Tue, Jul 01, 2025 at 07:07:45PM +0200, Bernhard Voelker wrote: > On 6/28/25 00:21, Pádraig Brady wrote: > > I wouldn't be rushing to implement it TBH. > > Furthermore, -r clashes with the existing -f,--follow ... hence it's even more > surprising that POSIX does not specify what should happen f

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

On Tue, Jul 01, 2025 at 02:28:48PM -0500, Eric Blake wrote: > On Fri, Jun 27, 2025 at 08:51:10AM -0700, Jim Meyering wrote: > > > > > > > > [1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/tail.html > > > > > > tail -r comes from the BSDs. > > > Also the BSDs don't have tac(1) which o

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

On Fri, Jun 27, 2025 at 08:51:10AM -0700, Jim Meyering wrote: > > > > > > [1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/tail.html > > > > 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 add

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

After this week's changes in 'od', the CI reports a test failure on OpenBSD and Solaris: FAIL: tests/od/od = od (GNU coreutils) 2025-06-30 Copyright (C) 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/

bug#78933: compilation error after recent 'od' changes

After this week's changes in 'od', the CI reports a compilation error on macOS: gcc -I. -I.. -I./lib -Ilib -I../lib -Isrc -I../src -I/Users/runner/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/opt/libiconv/include -Wall -Wno-format-extra-args -Wno-implicit-const-int-float-conver

bug#78932: Bug report: fold does not correctly handle last word in line with -s option

Hi everyone! When the -s option is enabled (break at spaces), fold does not correctly handle the case in which the last character that should be on the folded line is a word's last character. In other words, the issue happens when the line's last character is a non-blank character, followed by

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

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 tail -n$n | tac and tac | head -n$n can be used to output a fi

bug#78882: stty.c compilation error

Collin Funk wrote: > Perhaps it is worth documenting somewhere? I think Autoconf's manual has > a section of shell portability gotchas. Yes, I had the same thought. Done through . Bruno

bug#78882: stty.c compilation error

H. Peter Anvin wrote: > Do the shells on these systems support $'\n' constants? Sure. Dollar-single-quote strings in sh are quote portable. > There is also the option of simply putting a newline in the string, I > believe. The best way to include a newline in a sed script is not to use a litera

bug#78882: stty.c compilation error

Hi, The coreutils CI fails today on OpenBSD and Solaris. (The previous build, a week ago, succeeded.) Compilation error on OpenBSD: cc -I. -I.. -I./lib -Ilib -I../lib -Isrc -I../src -I/usr/local/include -Wall -Wno-format-extra-args -Wno-implicit-const-int-float-conversion -Wno-tautological

bug#78857: shred bug

Hi! I've started shredding a drive /dev/sdc on the latest stable linux mint (debian), then I've connected another drive for work, and the shredding command was cancelled with an error "Error writing at offset [offset]: No such device". Apparently, Mint has automounted and assigned the name /dev/

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

> Am 30.05.2025 um 18:46 schrieb Paul Eggert : > > touch -t 20250529 a b > gls -l --time-style=full a b > echo 'b: a; echo ouch; false' >Makefile > make On PPC Mac OS X 10.4.11, Tiger, this sequence also produces: make: `b' is up to date. gls reports: -rw-r--r-- 1 pete ad

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

On PPC Mac OS X 10.5.8, Leopard, Coreutils-9.5 already worked OK, coreutils-9.7.39-c8d75.tar.gz does the same, and tests show only one failure in env-S with __CF_USER_TEXT_ENCODING, as on Tiger, PPC Mac OS X 10.4.11. -- Greetings Pete The future will be much better tomorrow

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

> Am 30.05.2025 um 18:46 schrieb Paul Eggert : > > What happens on your platform when you run the following shell commands in a > fresh directory? > > touch -t 20250529 a b > gls -l --time-style=full a b > echo 'b: a; echo ouch; false' >Makefile > make On PPC Leopard, Mac OS X 10.5.8:

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

what John Siracusa writes in the article you cite. I found something in configure's output: checking filesystem timestamp resolution... 2 And coreutils-9.7.39-c8d75 find this too! Looking into the code it's stated that a 1 sec resolution is expressed as 2 sec for practical rea

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

it cannot be created! >> cd . && /bin/sh >> /opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7.39-c8d75/build-aux/missing >> automake-1.17 --gnu > > This suggests that you updated configure.ac or m4

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

> Am 28.05.2025 um 21:58 schrieb Paul Eggert : > > https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz This is the result of testing: GNU coreutils 9.7.39-c8d75: ./tests/test-

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

> Am 29.05.2025 um 16:47 schrieb Paul Eggert : > > On 2025-05-29 03:16, Peter Dyballa wrote: >> gpg: Can't check signature: No public key > > You can fix that by importing the public key of whoever signed the compressed > tarball. See . > > E.g.: > >

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

> Am 29.05.2025 um 13:28 schrieb Pádraig Brady : > > It would be worth double checking if you can, Applying your patch AND configuring with "utils_cv_avx512_pclmul_intrinsic_exists=no" brings successful build. So your patch does not hurt… -- Greetings Pete ~ 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

> Am 29.05.2025 um 13:28 schrieb Pádraig Brady : > > It would be worth double checking if you can, Applying it does not change the output of "grep 'CACHE.*utils_cv.*intrins' configure.ac" when configure'd with "utils_cv_avx512_pclmul_intrinsic_exists=no". Result is the usual error. -- Greet

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

ocal/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7.39-c8d75" && ./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g --with-openssl=no --disable-year2038 utils_cv_avx512_pclmul_intrinsic_exists=no

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

> 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 *with* your patch applied? > You might have

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

> Am 28.05.2025 um 21:58 schrieb Paul Eggert : > > https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz Solves the problem: ./mv -v k out succeeds: k vanishes and out is still a file! (Now testing.) -- Greetings Pete No matter which way you ride, it's uphill a

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

gpg: key 0716748A30D155AD: no user ID gpg: Total number processed: 1 gpg: Can't check signature: No public key Exit 2 Build and install of automake 1.18 succeed (test has problems, including endless halt), but coreutils-9.7.39-c8d75 still do not build, the err

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

8' +am__api_version='1.17' But that's over, I managed to install automake 1.18. (I'll try the same on my old PowerBook G4 as well to test the new version of coreutils! Only that the configure step seems to take hours now… And the warnings continue to exist.) -- Greetings ~ O Pete ~~_\\_/% ~ O 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

First try with coreutils-9.7.39-c8d75 and Apple LLVM version 10.0.0 (clang-1000.11.45.5) AND without Pádraig's patch from a few days ago. I have to change 1.18 to 1.17 in aclocal.m4 and configure (for which I prepared patches to automate this). At the end of configure step

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

> Am 28.05.2025 um 21:58 schrieb Paul Eggert : > > You can get it temporarily from: > > https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz I fetched it! I'll try tomorrow on both Macs. I'll also check with diffutils, https://debbugs.gnu.org/db/77/77840.h

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

> Am 24.05.2025 um 21:33 schrieb Paul Eggert : > > Can you verify that a simple program like the following triggers this macOS > bug? If so, we might be able to work around it. The output is: "O_DIRECTORY incorrectly succeeded!" > You may need to munge this program a bit to get it to compile

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

> Am 24.05.2025 um 10:36 schrieb Paul Eggert : > > On 2025-05-24 00:51, Peter Dyballa wrote: >> You are saying that the GNUlib function target_directory_operand() is known >> to fail when the target of cp or mv is a file? So I do not need to debug >> further? > > No, I'm saying that target_di

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

12_CRC32_TRUE ./configure~:93229:printf '%s\n' "#define USE_AVX512_CRC32 1" >>confdefs.h ./configure~:93233: USE_AVX512_CRC32_TRUE= ./configure~:93234: USE_AVX512_CRC32_FALSE='#' ./configure~:93236: USE_AVX512_CRC32_TRUE='#' ./configure~:93237: USE_AVX

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

> Am 24.05.2025 um 10:24 schrieb Paul Eggert : > > Does the attached patch work around the problem? Yes, it does! It also build fine with -Os. -- Greetings Pete "Indentation?! I will show you how to indent when I indent your skull!" – Unknown Klingon typist

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

> Am 24.05.2025 um 10:24 schrieb Paul Eggert : > > On 2025-05-23 01:17, Peter Dyballa wrote: >> Undefined symbols: >> "_fchownat", referenced from: >> _chownat in libstdbuf_so-libstdbuf.o >> _lchownat in libstdbuf_so-libstdbuf.o >> "_fchmodat", referenced from: >> _chmodat

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

> 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-tautological-constant-out-of-range-compare -pipe -

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

atus: creating po/Makefile Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled: alignof: found in coreutils-9.7/config.log __GNUC_PREREQ: found in coreutils-9.7/config.log unreac

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

nd is supposed to fail (i.e., return a > value for which target_dirfd_valid is false) if LASTFILE is not a directory, > and LASTFILE is "out" here. You are saying that the GNUlib function target_directory_operand() is known to fail when the target of cp or mv is a fil

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

> Am 23.05.2025 um 16:52 schrieb Peter Dyballa : > > So presumingly it's not renameatu() but rather > lib/targetdir.c:61:target_directory_operand (char const *file, struct stat > *st) that is faulty… In modern macOS target_directory_operand() returns -1, target_dirfd_valid(-1) evaluates to F

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

Having finally managed to codesign Gdb! On macOS Sonoma 14.7.4 (intel) mv starts as on PPC Tiger. It reaches lines #457 and #459, but "target_dirfd_valid (fd)" delivers here FALSE, deduced from the fact that line #478 gets executed with errno presumingly 20 (on line #480 I can print err, which

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

um_pclmul.Tpo src/.deps/libcksum_pclmul_a-cksum_pclmul.Po mv -f src/.deps/libcksum_avx512_a-cksum_avx512.Tpo src/.deps/libcksum_avx512_a-cksum_avx512.Po mv -f src/blake2/.deps/cksum-blake2b-ref.Tpo src/blake2/.deps/cksum-blake2b-ref.Po make[2]: Leaving directory `/opt/loc

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

(renameatu (AT_FDCWD, file[0], AT_FDCWD, lastfile, 455 RENAME_NOREPLACE) RENAME_NOREPLACE should not be passed to the function here. Anyway, lib/renameatu.c is divided into two parts, one for systems with renameat() family of library functions and another

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

Paul, I have a strange effect when building coreutils 9.7 with MacPorts. Yesterday I tried to build with -O0 – and it failed! This morning I repeated it – with same result: /opt/local/bin/gcc-apple-4.2 -std=gnu99 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -fPIC

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

Hello Pádraig! Yesterday coreutils did not build because of use of -O0 instead of -Os before. This morning I am using simply -O, and the tests stop at the test after existing-perm-dir.sh (last line in build log), which is existing-perm-race.sh. coreutils-9.7/tests/cp has: -rw-r--r-- 1

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

structed to watch over a variable – but have no idea how. Is this a watchpoint? For today I am going rebuild coreutils 9.7 with -O0 and am going to check all tests, checking particularly how patched existing-perm-race.sh will perform. -- Greetings Pete Specifications are for the weak and timid!

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

I think I have a clue here: last_component (name=0xbfffd607 "k") at lib/basename-lgpl.c:30 Run till exit from #0 last_component (name=0xbfffd607 "k") at lib/basename-lgpl.c:30 0x42ac in main (argc=, argv=) at src/mv.c:532 Value returned is $3 = 0xbfffd607 "k"

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

Sorry! I made a fault! I was still looking into the previously built and renamed tree. (Removed now.) The two patch files are applied correctly to existing-perm-race.sh + file-perm-race.sh, and to Makefile.in. And I am being now in the proper tree… -- Greetings Pete "Free markets would be

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

After returning home 'make check' is frozen at: PASS: tests/cp/cp-parents.sh FAIL: tests/cp/debug.sh FAIL: tests/cp/deref-slink.sh PASS: tests/cp/dir-rm-dest.sh PASS: tests/cp/dir-slash.sh PASS: tests/cp/dir-vs-file.sh PASS: tests/cp/existing

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

angs similarly in future: > https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=dc4e6b670 I fetched your patch and let MacPorts apply it at start, which worked. I rebuilt coreutils with -ggdb -gdwarf-2 in order to be able to debug with Gdb, while 'make check' was running in the background. But,

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

Hello! Here's a first result, got from using ktrace and kdump – and deleting almost ½ MB of text output: 17186 mv CALL geteuid 17186 mv RET geteuid 501/0x1f5 17186 mv CALL ioctl(0,0x4004667a ,0xbfffd498) 17186 mv RET ioctl 0 17186 mv CALL lstat(0xbfffd87

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

> 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 remember a test which was logging that the user per

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

> 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_ fifo + test 1 = 1 + mkfifo fifo + t

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

> Am 20.Mai.2025 um 19:10 schrieb Paul Eggert : > > First, please build and run coreutils 9.7 and try that instead. Building with GCC 14.2 yields the same as reported before for diffutils 3.12, bug#77840: /opt/local/bin/gcc-mp-14 -std=gnu23 -pipe -Os -arch ppc -L/opt/

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

> Am 20.Mai.2025 um 19:10 schrieb Paul Eggert : > > First, please build and run coreutils 9.7 and try that instead. If it works, > we're done. (For what it's worth, I just now built and ran coreutils 9.7 on > macOS 12.6 (ARM) and it worked fine.) They built! Tests

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

Hello! Working on a problem with diffutils 3.12 on the same platform (bug#77840) I see in the log file of the basic diffutils tests (with vi, because GNU Emacs has a problem with millions of NUL characters): 126 + mv k out 127 mv: cannot stat 'out/k': Not a directory It comes from this t

bug#78398: sc_gitignore_missing failure

Following the addition of file lib/fts.in.h in gnulib, the coreutils CI fails. To reproduce the failure: $ make sc_gitignore_missing gitignore_missing /lib/fts.h maint.mk: Add above entries to .gitignore make: *** [cfg.mk:813: sc_gitignore_missing] Error 1 The rule in cfg.mk apparently assumes

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

  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: md5sum --version md5sum (GNU coreutils) 8.32   * Set of commands to reproduce: $ touch hello $ touch hello\t\\t

bug#77771: coreutils 9.7 printf crashes on Solaris 11

> Running the attached script on Solaris 11.4 or Solaris 11 OpenIndiana, > in the coreutils-9.7 build tree, produces a crash: > > $ sh ~/cmd > 42 351 ... > 4 235 ... > 42 351 ... > /home/bruno/cmd: line 4: 18141: Memory fault(coredump) > Segmentation Fault (core dum

bug#77771: coreutils 9.7 printf crashes on Solaris 11

Running the attached script on Solaris 11.4 or Solaris 11 OpenIndiana, in the coreutils-9.7 build tree, produces a crash: $ sh ~/cmd 42 351 ... 4 235 ... 42 351 ... /home/bruno/cmd: line 4: 18141: Memory fault(coredump) Segmentation Fault (core dumped) What triggers the crash is a %'g dire

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

> 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 "--%'10f--" 5 > --50�000-- > whereas > $ LC_ALL=en_U

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

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

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

width() returns -1, and no padding characters are added. The fix belongs in Solaris 11 or Gnulib; the numfmt source code should not need any changes. I'll deal with that; this should not delay the coreutils release. Bruno ==

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

Pádraig Brady wrote: > I'll also apply this logic to has_capability_cache(). Yes, the same mistake is lurking there as well. Bruno

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

rg/archive/html/coreutils/2025-01/msg00051.html Apparently this bug has reappeared, at least on OpenBSD. Bruno ==== GNU coreutils 9.6.53-14af8: ./tests/test-suite.log # TOTAL: 658 #

bug#77509: 1 failure with "make check"

“make check” failure: Testsuite summary for GNU coreutils 9.6 # TOTAL: 657 # PASS: 483 # SKIP: 173 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR

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

Eric Blake wrote: > > Let me document this limitation. > > > > > -This function returns the value of the @env{LOGNAME} environment variable: > > +This function returns the value of the @env{LOGNAME} environment variable > > +and this therefore arbitrarily fakeable: > > s/this/thus/ ? Oops, than

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

On Mon, Mar 10, 2025 at 06:24:45AM +0100, Bruno Haible via GNU coreutils Bug Reports wrote: > I wrote: > > Thus, on Linux systems, a correct implementation of getlogin() can not > > distinguish different users with the same uid (with reasonable effort). > > This applies to b

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

I wrote: > Thus, on Linux systems, a correct implementation of getlogin() can not > distinguish different users with the same uid (with reasonable effort). > This applies to both glibc and the new code in gnulib. Let me document this limitation. 2025-03-10 Bruno Haible getlogin, getl

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

Bruno, thank you for all these clarifications. Regarding cases such as "su --login" and users who share the same uid, it might be interesting to add a few lines to the logname documentation. It's still very confusing to have $LOGNAME with one value and the output of logname with another. NB

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

Nicolas Boos wrote: > This page says that the result of the logname command and the LOGNAME > variable must be the same: > https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command An AIX man page is not a specification for what we run on GNU systems. > Thus, getlogin() implementations that use

bug#76897: id improvements

Context: $ cat /etc/passwd nicolas:x:1000:2001::/home/nicolas:/bin/bash claude:x:1000:2002::/home/claude:/bin/zsh $ cat /etc/group gnicolas:x:2001: gclaude:x:2002: Test case: localhost login: claude $ getent passwd claude claude::1000:2002::/home/claude:/bin/zsh $ id claude uid=1000(nicolas) gi

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

login: claude Password: $ echo $LOGNAME claude $ logname (glibc) nicolas $ logname (musl) claude $ logname (uclibc) claude I'm not really convinced that these fixes make things better. NB > I wrote: > > With this, coreutils should be fine, since it already imports the 'getlogin

  1   2   3   >