bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel

Marking this as done in the coreutils bug tracker, now that this is being tracked in glibc. thank you! On 27/04/2022 13:46, Adhemerval Zanella wrote: On 21/04/2022 14:36, Pádraig Brady wrote: That suggests the kernel (statx) returns fine, but glibc's fstatat64 is returning the EOVE

bug#55029: Simple backup swaps source and destination files

On 21/04/2022 03:53, Paul Eggert wrote: On 4/19/22 16:05, Steve Ward wrote: When doing mv or cp with --backup=simple, if an existing file in DIRECTORY has the same name as SOURCE, the files appear to be swapped instead of an in-place backup of the original file in DIRECTORY being made. Thanks

bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel

On 21/04/2022 18:41, Adhemerval Zanella wrote: On 21/04/2022 12:25, Pádraig Brady wrote: On 21/04/2022 15:53, Arnaud Panaïotis wrote: On 21/04/2022 14:36, Pádraig Brady wrote: On 19/04/2022 16:01, Arnaud Panaïotis wrote: On 19/04/2022 16:00, Pádraig Brady wrote: On 19/04/2022 08:47

bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel

On 21/04/2022 15:53, Arnaud Panaïotis wrote: On 21/04/2022 14:36, Pádraig Brady wrote: On 19/04/2022 16:01, Arnaud Panaïotis wrote: On 19/04/2022 16:00, Pádraig Brady wrote: On 19/04/2022 08:47, Arnaud Panaïotis wrote: Hello, I did not received any feedback from this request right now

bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel

On 19/04/2022 16:01, Arnaud Panaïotis wrote: On 19/04/2022 16:00, Pádraig Brady wrote: On 19/04/2022 08:47, Arnaud Panaïotis wrote: Hello, I did not received any feedback from this request right now. Have you made any progress on this subject ? Please let me know the progress for this, or

bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel

On 19/04/2022 08:47, Arnaud Panaïotis wrote: Hello, I did not received any feedback from this request right now. Have you made any progress on this subject ? Please let me know the progress for this, or contact me for additional information if needed. I'd like to have a ticket link to follow t

bug#50889: Please improve the documentation for install --compare (-C)

On 29/09/2021 12:09, Ian Cross via GNU coreutils Bug Reports wrote: Hi, A while back a request was made to improve the documentation of the `install --compare` cmd: https://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00029.html It seems the wording in `coreutils.texi` has been updated

bug#54521: [PATCH] dircolors: colorize backup files with bright black

On 23/03/2022 23:53, Pádraig Brady wrote: On 22/03/2022 18:24, Ville Skyttä wrote: Useful as it makes them stand out less than non-backup files. --- src/dircolors.hin | 19 +++ 1 file changed, 19 insertions(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index

bug#54681: timeout: Program called by timeout cannot interact with tty stdin when timeout is called by exec()

tag 54681 notabug close 54681 stop On 02/04/2022 11:22, Zhaofeng Yang wrote: Hi GNU Team, I found that program called by timeout cannot interact with tty stdin when timeout is called by exec(). A simplest example is `timeout 10 timeout 5 cat`. cat cannot read input from tty stdin. I also trie

bug#54625: Why do I need to specify `-o auto` for join's `-e` option to work?

On 29/03/2022 09:07, Iago-lito wrote: Hello,     This is a follow-up to this (yet) unanswered post on SE U&L: https://unix.stackexchange.com/q/696259/87656, which I'm cross-posting here. Don't hesitate to fire if it's the wrong place. With the following two simple files: |a.txt| |1 a 2 b 5

bug#54521: [PATCH] dircolors: colorize backup files with bright black

On 22/03/2022 18:24, Ville Skyttä wrote: Useful as it makes them stand out less than non-backup files. --- src/dircolors.hin | 19 +++ 1 file changed, 19 insertions(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index 673835201..6dc5a2d74 100644 --- a/src/dircolors.hin

bug#54388: printf doesn't handle multi-byte values

On 18/03/2022 14:59, Pádraig Brady wrote: The attached should fix this up. The following should make this more efficient for the normal unibyte case, as one can't have NUL chars in any multi-byte encodings. - if (MB_CUR_MAX > 1) \ +

bug#54388: printf doesn't handle multi-byte values

On 14/03/2022 15:38, Pádraig Brady wrote: On 14/03/2022 03:27, Christoph Anton Mitterer wrote: Hey Pádraig. I just wanted to ask, whether the following could be a bug in printf: POSIX says[0], that e.g.: printf '%d\n' \"3 should give the numeric value of the character,

bug#54388: printf doesn't handle multi-byte values

On 14/03/2022 03:27, Christoph Anton Mitterer wrote: Hey Pádraig. I just wanted to ask, whether the following could be a bug in printf: POSIX says[0], that e.g.: printf '%d\n' \"3 should give the numeric value of the character, and that "in a locale with multi-byte characters, the value of

bug#54338: enhancement (documentation): explain permission tests in "test"

On 11/03/2022 10:42, Ulrich Windl wrote: I noticed that "test -r file" returns success when called as root for a file with these permissions: "--w---" (see also https://stackoverflow.com/q/71435657/6607497) The documentation simply states: ‘-r FILE’ True if FILE exists and read permiss

bug#54287: [PATCH] Fix stat command triggering automount.

New stat patch attached to apply AT_NO_AUTOMOUNT unless --cached=never is specified. See https://bugs.gnu.org/54286 for more general discussion. Marking this as done. cheers, PádraigFrom 3fddd0f4eb0eb9b47294f951195233e1c5f12e72 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Dat

bug#54286: [PATCH] Fix ls -l triggering automounts.

Updated patch for ls attached as per discussion. Added a NEWS entry.From e4c7fccc0c057a772b6be3f002003ba005cc89d7 Mon Sep 17 00:00:00 2001 From: Rohan Sable Date: Mon, 7 Mar 2022 14:14:13 + Subject: [PATCH] ls: avoid triggering automounts statx() has different defaults wrt automounting compa

bug#54286: [PATCH] fcntl-h: add AT_NO_AUTOMOUNT

/ChangeLog @@ -1,3 +1,9 @@ +2022-03-07 Pádraig Brady + + fcntl-h: add AT_NO_AUTOMOUNT + * lib/fcntl.in.h: Define AT_NO_AUTOMOUNT to 0 where not defined. + This is available on Linux since 2.6.38. + 2022-03-01 Paul Eggert Create lib/Makefile.am after gnulib-comp.m4 diff

bug#54286: [PATCH] Fix ls -l triggering automounts.

On 07/03/2022 07:54, Rohan Sable wrote: Running ls -l on a path that has autofs mounts, triggers a mount or in case of unmountable shares, triggers errors : ~~~ [root@rsablerhel85 mnt2]# ll ls: cannot access 'testshare2': No such file or directory < Error total 0 drwxrwxrwx. 3 1000 1000 1

bug#54189: [PATCH] dircolors: add hterm

On 27/02/2022 21:08, Mike Frysinger wrote: * src/dircolors.hin: Add hterm*. --- src/dircolors.hin | 1 + 1 file changed, 1 insertion(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index 673835201311..fa01192bf7e5 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -23,6 +23,7 @@

bug#45648: `dd` seek/skip which way is up?

On 22/02/2022 17:12, Paul Eggert wrote: On 1/4/21 20:08, Paul Eggert wrote: On 1/4/21 7:44 PM, Bela Lubkin wrote: TLDR: *huge* existing presence of 'iseek' and 'oseek'; most OSes document them as pure synonyms for 'skip' and 'seek'. Thanks for doing all that research. It's compelling, and I t

bug#54124: fmt inserts garbage in certain cases?

On 23/02/2022 17:55, Pádraig Brady wrote: I think isspace(x85) returning true on macOS is a bug, Bug is a bit of a strong word here. A digression into why 0x85 is being treated specially here. Note Cyrillic kha "х" is encoded in UTF-8 as: $ printf '\u0445' | od -tx1 0

bug#54124: fmt inserts garbage in certain cases?

On 23/02/2022 10:58, JD wrote: Hi! I have fmt from coreutils 8.32.1 installed via MacPorts. If I run the following command: `echo х х х х х х х х х х х х х х х х х х х х х х х х х х | gfmt -sw 10` (which is just echoing 26 Cyrillic 'х' ('kha') letters), I get the following results: https://i

bug#54112: dd seek_bytes etc. is confusing

On 22/02/2022 17:03, Paul Eggert wrote: While looking into Bug#45648 I noticed that the GNU extensions count_bytes, seek_bytes, and skip_bytes are confusing, and the proposed fix to bug#45648 would make them even more confusing. To fix this confusion, we should deprecate these options, and instea

bug#53977: Improve markup in man pages

On 14/02/2022 13:52, Mario Blättermann wrote: Hello Pádraig, Am Mo., 14. Feb. 2022 um 13:15 Uhr schrieb Pádraig Brady : On 13/02/2022 13:19, Mario Blättermann wrote: Hello, the SEE ALSO sections in the man pages contain links which will be pulled in from *.x files by help2man. While

bug#53977: Improve markup in man pages

On 13/02/2022 13:19, Mario Blättermann wrote: Hello, the SEE ALSO sections in the man pages contain links which will be pulled in from *.x files by help2man. While help2man evaluates the Groff markup from --help and --version output, it doesn't bother with the markup in the *.x files. See the at

bug#49239: Unexpected results with sort -V

On 13/02/2022 05:31, Paul Eggert wrote: On 6/28/21 10:54, Kamil Dudka wrote: You are right. The matching algorithm was not implemented correctly and the patch you attached fixes it. I looked into Bug#49239 and found some more places where the documentation disagreed with the code. I installed

bug#53631: coreutils id(1) incorrect behavior

On 04/02/2022 22:59, Paul Eggert wrote: Thanks for the bug report. I installed the attached patch, which I hope fixes things for you, and am boldly closing the bug report. This fix depends on the latest lib/userspec.c from Gnulib; see .

bug#53946: Errors in man pages of GNU_coreutils

On 12/02/2022 05:57, Helge Kreutzmann wrote: Dear coreutils maintainer, the manpage-l10n project maintains a large number of translations of man pages both from a large variety of sources (including coreutils) as well for a large variety of target languages. During their work translators notice

bug#53574: csplit: help document: +/- is not required before OFFSET

On 27/01/2022 07:28, Jun-T wrote: 'csplit --help' (and 'man csplit') says: A line OFFSET is a required '+' or '-' followed by a positive integer. But I think the '+' or '-' is optional, not required. 'info csplit' just says: The optional OFFSET is an integer I think this is correct sin

bug#53400: base64: decode Base64URL

On 20/01/2022 21:31, Sergey Ponomarev wrote: Package: coreutils Currently the base64 util can't parse base64 url safe. RFC 3548 Base 64 Encoding with URL and Filename Safe Alphabet https://datatracker.ietf.org/doc/html/rfc3548#page-6 But basically this is the same encoding: just two symbols di

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

On 15/01/2022 01:09, Paul Eggert wrote: Thanks for reporting that. This is a duplicate of bug#50784[1], which was fixed[2] in September. Perhaps we should generate a new Coreutils soon, since this bug has been reported three times now. [1]: https://bugs.gnu.org/50784 [2]: https://git.savannah.g

bug#53025: Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior

On 05/01/2022 08:44, Joerg M. Sigle wrote: Dear coreutils developers Thank you very much for your efferts in trying to provide and maintain fine tools that help millions or billions of users every day. I'm one who appreciates that (and I try to do something similar as well). Still, sometimes th

bug#52800: [PATCH] maint: fix prctl arguments

On 26/12/2021 05:17, Max Filippov wrote: When configured with --enable-single-binary tools issue incorrect prctl: prctl(PR_SET_KEEPCAPS, 1071091381) = -1 EINVAL (Invalid argument) PR_SET_MM_ARG_START is not a prctl 'option' parameter, it's 'arg2' parameter for the option PR_SET_MM. It a

bug#52343: Sentry kafka bug

tag 52343 notabug close 52343 stop On 07/12/2021 03:13, 许慧良 wrote: tail: unrecognized file system type 0x794c7630 for ‘kafkaServer-gc.log.0.current’. please report this to bug-coreutils@gnu.org. reverting to polling 2021-12-07T03:03:51Z [relay_server::endpoints::common] ERROR: error handling

bug#52077: tail: a case where -n is not taken as implicit

tag 52077 notabug close 52077 stop On 24/11/2021 07:38, Shehu Dikko wrote: Package: coreutils Version: 9.0 Do please take a look at this example: % printf '%s\n' just three lines | tee >f1 f2 % tail -n1 f1 lines % tail -n1 f* ==> f1 <== lines ==> f2 <== lines % tail -1 f1 lines % tail -1 f* t

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 15/11/2021 18:37, Sudhip Nashi via GNU coreutils Bug Reports wrote: On Nov 15, 2021, at 11:33, Paul Eggert wrote: Is the source file on a ZFS file system by any chance? See my lseek comment below. On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: stat64("/tmp/test\

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 15/11/2021 04:02, Sudhip Nashi via GNU coreutils Bug Reports wrote: Hello, Cross-filesystem copying seems to have been broken in the latest coreutils release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ appears to return successfully, but if one analyzes /tmp/test, it’s fi

bug#51793: FAIL: tests/misc/env-signal-handler

On 13/11/2021 09:46, Andreas Schwab wrote: On Nov 12 2021, Pádraig Brady wrote: I've never seen this, and I can't see the race. There is an obvious race: if env needs more than .1 seconds to set the SIGINT handler. Indeed. That fits the pattern where we need a certain delay to p

bug#51793: FAIL: tests/misc/env-signal-handler

On 12/11/2021 19:25, Andreas Schwab wrote: --- exp-err6 2021-11-11 22:58:04.360716802 + +++ err6 2021-11-11 22:58:04.752716821 + @@ -1,2 +1 @@ timeout: sending signal INT to command 'env' -timeout: sending signal KILL to command 'env' The above is for the previous command not

bug#51792: coreutils - csplit - feature request

On 12/11/2021 17:05, Rodolfo Aramayo wrote: Dear Coreutils Maintainers, First, thank you for your work. I use coreutils daily both for my research and teaching. It is a great set of tools. Second, I recently needed to extract Coding Sequences information from a GenBank file. GenBank files are u

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 27/10/2021 11:00, Janne Heß wrote: Hi everyone, I packaged coreutils 9.0 for NixOS and we found breakages that seemed to be very random during builds of packages that use the updated coreutils in their build process. It's really hard to tell the main cause but it seems like the issues are c

bug#51569: tail -f reports unrecognized file system type

tag 51569 notabug close 51569 stop On 02/11/2021 16:01, Tom Barringer wrote: Received this error: tail: unrecognized file system type 0x53464846 for ‘ads0.exp’. please report this to bug-coreutils@gnu.org. reverting to polling Environment: Win10 with all updates Using Windows Subsystem for Linux

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 01/11/2021 05:52, Paul Eggert wrote: On 10/31/21 09:13, Pádraig Brady wrote: The attached uses statfs()->f_type which is usually available, to avoid using SEEK_DATA on ZFS.  This should be fairly lightweight I think, and only used for files that might be sparse. Couldn't we be eve

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

On 11/10/2021 02:54, Pádraig Brady wrote: On 11/10/2021 00:34, Paul Eggert wrote: The warnings look good, except that this one:   $ printf '1.0\n0.9\n' | sort -s -k1,1g --debug   sort: numbers use ‘.’ as a decimal point in this locale   0.9   ___   1.0   ___ seem

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 30/10/2021 03:04, Paul Eggert wrote: On 10/28/21 13:59, Pádraig Brady wrote: I wonder after getting a SEEK_DATA ENXIO, might we correlate we really are at end of file by checking SEEK_HOLE also returns ENXIO? Wouldn't SEEK_HOLE return the current offset, instead of ENXIO? That is, i

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 28/10/2021 20:11, Paul Eggert wrote: On 10/28/21 06:54, Pádraig Brady wrote: Further debugging from Nix folks suggest ZFS was in consideration always, as invalid artifacts were written to a central cache from ZFS backed hosts. So we should at least change the comment in the patch to only

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 30/10/2021 02:24, Paul Eggert wrote: On 10/28/21 12:11, Paul Eggert wrote: Wait - lseek returns a number less than -1?! We could easily check for that FreeBSD bug, perhaps as an independent patch; this shouldn't require any extra syscalls. I installed the attached patch to do this. This doe

bug#51345:

On 28/10/2021 22:59, Sworddragon wrote: Despite I'm not using Linux as main system anymore and wanted to avoid getting into too much work I found some time to do some tests as this issue bugs me just too much. You could try running the following immediately after, to see if it also returns quic

bug#51345:

On 28/10/2021 22:59, Sworddragon wrote: Despite I'm not using Linux as main system anymore and wanted to avoid getting into too much work I found some time to do some tests as this issue bugs me just too much. You could try running the following immediately after, to see if it also returns quic

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 28/10/2021 20:11, Paul Eggert wrote: On 10/28/21 06:54, Pádraig Brady wrote: Further debugging from Nix folks suggest ZFS was in consideration always, as invalid artifacts were written to a central cache from ZFS backed hosts. So we should at least change the comment in the patch to only

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 28/10/2021 08:56, Paul Eggert wrote: On 10/27/21 03:00, Janne Heß wrote: Building another package (peertube) on x86_64-linux on ext4 also fails with strange errors in the test suite, something about "Error: The service is no longer running". This does not happen when the mentioned coreutils

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 27/10/2021 11:00, Janne Heß wrote: Hi everyone, I packaged coreutils 9.0 for NixOS and we found breakages that seemed to be very random during builds of packages that use the updated coreutils in their build process. It's really hard to tell the main cause but it seems like the issues are c

bug#51345: dd with conv=fsync sometimes returns when its writes are still cached

On 23/10/2021 09:18, Sworddragon wrote: On Knoppix 9.1 with the Linux Kernel 5.10.10-64 x86_64 and GNU Coreutils 8.32 I wanted to overwrite my USB Thumb Drive a few times with random data via "dd if=/dev/random of=/dev/sdb bs=1M conv=fsync". While it usually takes ~2+ minutes to perform this acti

bug#51311: [PATCH] echo: update --help to document edge cases

On 21/10/2021 21:54, Bernhard Voelker wrote: On 10/21/21 15:14, Florent Flament wrote: Pádraig Brady writes: +NOTE: printf(1) is a preferred alternative, with more standard option handling.\ I believe that it misses the point. It is still not clear that the echo command doesn't beha

bug#51311: [PATCH] echo: update --help to document edge cases

On 20/10/2021 22:50, Florent Flament wrote: * src/echo.c (usage): Document edge cases when displaying arbitrary strings with the echo command. --- src/echo.c | 8 1 file changed, 8 insertions(+) diff --git a/src/echo.c b/src/echo.c index 18513398a..73b44660b 100644 --- a/src/echo.c

bug#51128: timeout --kill-after=0 seems to not send a kill 0s after the initial signal

On 12/10/2021 02:21, Christoph Anton Mitterer wrote: Hey. One more thing on this, since I've just read through: https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation That does IMO *not* document the behaviour: --kill-after=duration says: This optio

bug#51135: timeout: --foreground causes exit status 124, even if KILL was used

On 12/10/2021 02:55, Christoph Anton Mitterer wrote: Thinking again about this: Don't you think one looses quite something if, with --foreground, one cannot differ (via the exit status) between a timeout that allowed the program to clean up and one (when KILLing) that didn't? Even if the KILL

bug#51135: timeout: --foreground causes exit status 124, even if KILL was used

On 11/10/2021 22:11, Christoph Anton Mitterer wrote: On Mon, 2021-10-11 at 22:04 +0100, Pádraig Brady wrote: +However if the @option{--foreground} option is specified then +@command{timeout} will not send any signals to its own process, +and so it will exit with one of the other exit status

bug#51135: timeout: --foreground causes exit status 124, even if KILL was used

On 11/10/2021 19:01, Christoph Anton Mitterer wrote: Hey. This time I've also checked the 9.0 documentation (hopefully I wasn't just too blind). I noticed that whenever --foreground is used, timeout exits with a 124 status (instead of the documented 128+9) regardless of whether the KILL is se

bug#51128: timeout --kill-after=0 seems to not send a kill 0s after the initial signal

On 11/10/2021 16:59, Christoph Anton Mitterer wrote: On Mon, 2021-10-11 at 16:49 +0100, Pádraig Brady wrote: Well that wouldn't be that useful functionality, as why not just send a single kill signal in that case. Well with the same argumentation one could say that timeout 0 command do

bug#51128: timeout --kill-after=0 seems to not send a kill 0s after the initial signal

tag 51128 notabug close 51128 stop On 11/10/2021 02:28, Christoph Anton Mitterer wrote: Hey. The timeout(1) manpage says: -k, --kill-after=DURATION also send a KILL signal if COMMAND is still running this long after the initial signal was sent My naive ass

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

On 11/10/2021 00:34, Paul Eggert wrote: The warnings look good, except that this one:   $ printf '1.0\n0.9\n' | sort -s -k1,1g --debug   sort: numbers use ‘.’ as a decimal point in this locale   0.9   ___   1.0   ___ seems overkill if we're in the C locale. Also, shouldn't simila

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

On 10/10/2021 22:20, Bernhard Voelker wrote: On 10/10/21 19:57, Pádraig Brady wrote: sort: numbers use ‘.’ as a decimal point in this locale What about adding the hint to that message that this an "ambiguity warning"? sort: ambiguity warning: numbers use ‘.’ as a decima

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

On 09/10/2021 23:29, Paul Eggert wrote: On 10/9/21 5:00 AM, Pádraig Brady wrote: On 09/10/2021 04:48, Paul Eggert wrote: 'sort' could determine the group sizes from the locale, and reject digit strings that are formatted improperly according to the group-size rules. (Not that I pla

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

On 09/10/2021 04:48, Paul Eggert wrote: On 10/8/21 7:32 PM, Pádraig Brady wrote: it's not a thousands separator, rather a grouping character, and groups can be in 2, 3, 4, and even 5. Sure, but 'sort' could determine the group sizes from the locale, and reject digit strings tha

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

On 08/10/2021 21:48, Paul Eggert wrote: On 10/8/21 6:37 AM, Pádraig Brady wrote: The difference here is due to ',' being treated as a thousands sep, not a decimal point. Oh, thanks. Of course! I should have figured that out myself. It is unfortunate that "," is tr

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

On 04/10/2021 21:01, Paul Eggert wrote: On 10/4/21 08:58, Pádraig Brady wrote: The --debug option points out the issue:   $ printf '%s\n' 1,a 0,9 | sort --debug -nk1 -t ,   sort: key 1 is numeric and spans multiple fields   1,a   _   ___   0,9   ___   ___ As Junch

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

tag 51011 notabug close 51011 stop On 04/10/2021 15:36, Juncheng Yang wrote: Hi coreutils developers, I have encountered a bug in GNU sort in which sort produces incorrect results when numerical sort with delimiters. For example, sort -nk1 -t , file cannot sort the a file with the followin

bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not defined (e.g., OpenBSD)

On 03/10/2021 03:07, Paul Eggert wrote: On 10/2/21 7:44 AM, Brian Callahan wrote: Once this fix is done, the rest of coreutils-9.0 builds and works OK. Thanks for letting us know, as it's been a while since I tried building coreutils on OpenBSD. I just now tried it on OpenBSD 6.9 and found som

bug#50940: how df utility displays sizes - GB vs GiB

On 01/10/2021 14:28, Danie de Jager wrote: Hi, The output from df -h and df -H is always G or M. Depending on who sends me usage stats I have to ask how the command was run to make sure I calculate usage correctly. Systems like Amazon EC2 use the explicit GiB suffix. Making it easier to know wha

bug#50797: Question about whether Korean translation can be applied into version 9.0 or not

On 25/09/2021 07:45, Seong-ho Cho wrote: Many thanks in advance, I have submitted a brand-new Korean translation via translationproject.org and I also sent before for version 8.31.90 lately. our translation team did not manage the translation of coreutils before, due to huge changes of translati

bug#50791: Recursive chmod exit status in coreutils-9.0

On 25/09/2021 07:07, Chris Webb wrote: Thanks for the analysis and patch. I've already pushed a very similar patch at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e8b56ebd5 Many thanks! With the above fix, do we also need something like @@ -300,7 +300,7 @@ process_file (FTS

bug#50791: Recursive chmod exit status in coreutils-9.0

forcemerge 50791 50784 stop On 24/09/2021 22:16, Chris Webb wrote: Since bbb19b, chmod has started returning EXIT_FAILURE after skipping a symlink during a recursive change. This affects chmod in the newly released coreutils-9.0 vs the previous coreutils-8.32 and older versions: # mkdir t

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 24/09/2021 22:42, Daniel Schepler wrote: On Fri, Sep 24, 2021 at 1:02 PM Pádraig Brady wrote: Could you try with the following untested diff: Tested equivalent patch is attached. Yes, with chmod-fix-symlink-exit.patch applied and the resulting packages installed for testing, the issue

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 24/09/2021 20:29, Pádraig Brady wrote: On 24/09/2021 19:21, Daniel Schepler wrote: After I upgraded my system (locally built) to coreutils 9.0, I noticed that my lightly modified sbuild started getting build failures when it tries to run "chmod -R g+w /<>" (as root) in the

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 24/09/2021 19:21, Daniel Schepler wrote: After I upgraded my system (locally built) to coreutils 9.0, I noticed that my lightly modified sbuild started getting build failures when it tries to run "chmod -R g+w /<>" (as root) in the chroot. I'm not sure exactly what combination of files trigger

bug#50746: coreutils-8.32 test results on hppa hpux11.11

On 22/09/2021 23:48, John David Anglin wrote: See attached. A quick scan suggests these are mostly test issues, rather than issues with the utils themselves. For example a `sed 2q` that doesn't quit soon enough, or missing /dev/urandom etc. cheers, Pádraig

bug#50714: OS X, one failure: tests/tail-2/pipe-f.sh

On 21/09/2021 16:50, Paul Eggert wrote: On 9/21/21 6:08 AM, Pádraig Brady wrote: The attached fixes this on my testing on macOS. Thanks fixing this portability bug that I introduced. I also suggest changing this: #ifdef _AIX - /* select on AIX was seen to give a readable event

bug#50714: OS X, one failure: tests/tail-2/pipe-f.sh

On 21/09/2021 05:34, Jim Meyering wrote: Uname -v reports this: Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 Sorry, I don't have time to delve into this, but here's the log from the sole test failure: This looks to be an instance I was worrie

bug#50611: one-byte (write) heap-buffer-underrun

On 16/09/2021 19:51, Paul Eggert wrote: On 9/16/21 4:34 AM, Pádraig Brady wrote: It got me thinking though, that we should not we warning/failing on blank lines. I.e., we should be treating blank lines like comments. The attached does that. Thaks, a good improvement. The nerd in me also

bug#50611: one-byte (write) heap-buffer-underrun

On 16/09/2021 08:26, Paul Eggert wrote: Thanks for reporting that. I installed the attached to fix it. Thanks to you both. The fix looks good. It got me thinking though, that we should not we warning/failing on blank lines. I.e., we should be treating blank lines like comments. The attached do

bug#48894: ambiguous descriptions of logname and whoami

On 07/06/2021 02:49, Christoph Anton Mitterer wrote: Hey. Man page of logname say: "Print the name of the current user." IMO that's ambiguous as it's probably ought to be the name returned by getlogin(). So when I login as normal user, and "su -" to root, logname won't print "root" but the nor

bug#49745: [PATCH] dircolors: add *direct* to TERM matching

unarchive 39827 forcemerge 39827 49745 close 39287 stop On 27/07/2021 14:29, nl6720 wrote: * src/dircolors.hin: Add *direct* to match terminals that support direct colors (24-bit color / TrueColor). --- Resending this, since it seems to have been forgotten. src/dircolors.hin | 1 + 1 file ch

bug#50336: Width format specifier is calculated wrong for nb_NO locale

tag 50336 notabug close 50336 stop On 02/09/2021 13:49, Carl-Erik Kopseng wrote: I just noticed that the width specifier for numeric parameters does some weird calculations when the specified locale is `nb_NO.utf8`. For instance, the number formatting rules for US and NO both result in the same

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

On 17/08/2021 16:16, Pádraig Brady wrote: On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote: I receive the following error when using make with coreutils in a alpine based docker container: #10 304.5 parse-datetime.tab.c:658:10: fatal error: parse-datetime.tab.h

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote: I receive the following error when using make with coreutils in a alpine based docker container: #10 304.0 CC lib/mkdir-p.o #10 304.1 CC lib/modechange.o #10 304.1 CC lib/mpsort.o #10 304.2 CC lib/nproc.o #10 304.2 CC

bug#49741: basenc --base64url decoding bug

On 16/08/2021 22:17, Assaf Gordon wrote: Hello Emil and all, Thanks for the clear and easily reproducible bug report. Attached a suggested fix. Comments very welcomed, minor nit in NEWS: s/silently discard/silently discards/ Otherwise it looks good. thanks! Pádraig

bug#49925: cat -E interprets sentinel newline at the end of buffer as an actual newline after a \r

On 07/08/2021 14:07, Michael Debertol wrote: Hi, after https://lists.gnu.org/archive/html/coreutils/2021-02/msg3.html (unreleased), the behavior of cat -E was changed so that it prints "^M$" for "\r\n" line endings. Whenever it sees a \r "cat -E" checks if the byte after is a \n, however th

bug#49764: tr invocation INFO page missing list of options

On 29/07/2021 01:41, 積丹尼 Dan Jacobson wrote: (info "(coreutils) tr invocation") all the options don't appear together on the same page. Only the man page's DESCRIPTION has them all together. Yes the aggregated list is useful. I've added that in: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=

bug#49716: no -print0 for ls?

On 28/07/2021 02:14, Paul Eggert wrote: On 7/26/21 8:00 AM, Pádraig Brady wrote: So I'd have a slight preference for --zero. Also what about having --zero imply:   --quoting-style=literal --show-control-chars --format=single-column That seems like a fine shortcut given that would be co

bug#49716: no -print0 for ls?

On 26/07/2021 09:05, Paul Eggert wrote: On 7/25/21 10:10 AM, Pádraig Brady wrote: Right we should be especially careful of short options with ls. A long only option should suffice OK, I installed the attached to implement 'ls --null'. (The last patch is the actual change; the oth

bug#49716: no -print0 for ls?

On 25/07/2021 16:28, Paul Eggert wrote: On 7/25/21 7:43 AM, Pádraig Brady wrote: I would use the more consistent option for this though, i.e.:   -z, --zero    end each output line with NUL, not newline That's a different option, no? My proposal was something that

bug#49716: no -print0 for ls?

On 24/07/2021 20:26, Paul Eggert wrote: On 7/24/21 10:48 AM, Vito Caputo wrote: Couldn't we make -0 and any aliases shorthand for a new --format=WORD where WORD is names0 or something. That way it's automatically mutually exclusive with the other formats? It would make sense to invent a new -

bug#49716: no -print0 for ls?

On 24/07/2021 17:34, Vito Caputo wrote: On Sat, Jul 24, 2021 at 02:22:14PM +0100, Pádraig Brady wrote: On 24/07/2021 08:03, Vito Caputo wrote: Am I going senile here or does ls really not have a `find -print0` equivalent? This was previously discussed as noted at: https://www.gnu.org

bug#49716: no -print0 for ls?

tag 49716 notabug close 49716 stop On 24/07/2021 08:03, Vito Caputo wrote: Am I going senile here or does ls really not have a `find -print0` equivalent? This was previously discussed as noted at: https://www.gnu.org/software/coreutils/rejected_requests.html#ls In summary, ls output is mainly

bug#49340: small sort takes hours for UTF-8 locale

On 02/07/2021 20:32, Jon Klaas wrote: Hello, I encountered a file that was taking hours to sort that was expected to take negligible time. This seems to be due to the locale LANG=en_US.UTF-8. I've worked around the problem by using LC_ALL=C, but thought I would report this, as I didn't see a r

bug#49335: v.8.32 - stat(1) | Symbolic link interpreted as hard link

tag 49335 notabug close 49335 stop On 02/07/2021 17:32, Ricky Tigg wrote: Hello, symbolic link counted as hard link. To reproduce: $ touch t; ln -sr t l; stat -c '%i %h %n %F' t l 4172493 1 t regular empty file 4172494 1 l symbolic link '%h' reports *1* despite no hard link is involved. Isn't

bug#49298: [PATCH] df: do not print duplicated entires with NFS and bind mounts

On 30/06/2021 16:53, Kamil Dudka wrote: As originally reported in , df invoked without -a printed duplicated entries for NFS mounts of bind mounts. This is a regression from commit v8.25-54-g1c17f61ef99, which introduced the use of a hash table. The proposed

bug#49209: coreutils: stack out-of-bounds write in tail --follow

On 27/06/2021 02:47, Paul Eggert wrote: On 6/24/21 8:50 AM, Paul Eggert wrote: inotify_init can return 1025 even if called first thing, so we also need to dup2 the result of early inotify_init down to 3 (or whatever), or at least to check that it's less than 1024. Choosing 3 is a tricky busines

<    1   2   3   4   5   6   7   8   9   10   >