bug#58494: touch resists date 2022-09-11T00:00:00

On 2022-10-12 18:58, Felix Freeman via GNU coreutils Bug Reports wrote: $ touch -t 20220911 algo touch: invalid date format ‘20220911’ $ touch -d 2022-09-11T00:00:00 algo touch: invalid date format ‘2022-09-11T00:00:00’ In Santiago, Chile, that timestamp does not exi

bug#58163: coreutils instalation failure x86_64

Thanks for sending the extra data. Oh, I see you are running GCC 5.4. You have run into a GCC bug that I just now filed here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107116 This bug was in GCC 5 and is still present in GCC 12. To work around the GCC bug, please use './configure --disable

bug#58163: coreutils instalation failure x86_64

On 9/29/22 04:38, ripspin-004--- via GNU coreutils Bug Reports wrote:  git submodule foreach git pull origin master  git commit -m 'build: update gnulib submodule to latest' gnulib  ./bootstrap ./configure -quiet make That's a bit too terse, unfortunately. What distro and compiler are yo

bug#58050: [INSTALLED] rm: fix diagnostics on I/O error

Bug#58050. I fixed that by installing the attached into Gnulib.From e00de604fd7012fd912f7580cd658ed9363ed6ad Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 25 Sep 2022 18:33:49 -0700 Subject: [PATCH] fts: fix errno handling if dirfd fails MIME-Version: 1.0 Content-Type: text/plain; charset

bug#58050: [INSTALLED] rm: fix diagnostics on I/O error

I ran into this problem when attempting to recursively remove a directory in a filesystem on flaky hardware. Although the underlying readdir syscall failed with errno == EIO, rm issued no diagnostic about the I/O error. Without this patch I see this behavior: $ rm -fr baddir rm: cannot remove

bug#57946: ls indenting broken if executed without color flag after i set tabs to 4

r FORTRAN 66. Nowadays, not so much.From 4cbe227fa0b1bfd05b10245a3466ed99413e3a15 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 20 Sep 2022 00:09:42 -0700 Subject: [PATCH] doc: warn about tabs command (bug#57946) --- doc/coreutils.texi | 9 + 1 file changed, 9 insertions(+) diff --git a/doc/coreutils.texi b/doc/c

bug#56512: URLs in coreutils manuals documentation should use HTTPS

Thanks, I installed that.

bug#57785: [PATCH] doc: minor grammar correction

Thanks for the fix; I installed it.

bug#57631: Coreutils 9.1 build error with glibc 2.23

Thanks for the bug report. Please try this Gnulib patch, which should appear in the next Coreutils release: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b

bug#56710: ls vs. stat display of st_size

On 7/24/22 01:48, Pádraig Brady wrote: Well ls(1) was explicitly changed to assuming only positive, citing POSIX (though I can't see it in POSIX myself): https://github.com/coreutils/coreutils/commit/67ba4ac01 I vaguely recall being involved with that decades-old change. The POSIX requirement

bug#56710: ls vs. stat display of st_size

ched second patch, which I haven't installed? (I was actually inclined this way originally but got lazy.)From c2056a320b38126bf5566c2ce94e2c2b25243f66 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 23 Jul 2022 12:11:49 -0700 Subject: [PATCH 1/2] =?UTF-8?q?rm:=20don=E2=80=99t=20assume=20st=5F

bug#56710: ls vs. stat display of st_size

Thanks for reporting that. I installed the attached.From 34a93b971dd68ab8ff96aa20bf2f39374ab3a443 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 22 Jul 2022 13:50:31 -0700 Subject: [PATCH] stat: -c %s now prints unsigned * src/stat.c (unsigned_file_size): New static function, copied from

bug#56524: doc: timezone offset conversion/info

be necessary for clarity." <https://www.dailywritingtips.com/hyphenating-more-adjective/>From 5336cb27ab42f27b8b8ac31982e8215fe5af6f34 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 13 Jul 2022 18:54:56 -0700 Subject: [PATCH] * doc/parse-datetime.texi: Tweak wording again.

bug#56524: doc: timezone offset conversion/info

e tzalloc function).From f65d00ebacc891e57cca729041d028d07d1883bb Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 12 Jul 2022 17:11:26 -0700 Subject: [PATCH] parse-datetime: improve doc for TZ="<-07>7" etc. * doc/parse-datetime.texi (Specifying time zone rules): Give examples of

bug#56520: Security vulnerabilities at coreutils version for CentOS 7.9

On 7/12/22 05:43, Meirav Rath via GNU coreutils Bug Reports wrote: It looks like coreutils available rpm for CentOS 7.9 (8.22) has the vulnerability CVE-2017-18018. When can we expect an updated RPM of a more advanced version with fixes for this

bug#54586: dd conv options doc

hed to try to document this better. From 1efce5663554619db34d2722be7d6e5a14404065 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 6 Jul 2022 23:42:19 -0500 Subject: [PATCH] dd: doc improvement (Bug#54586) * doc/coreutils.texi (dd invocation): Explain fdatasync and fsync better. --- doc/core

bug#56391: `cp --reflink=always` creates empty file on failure

l clone. I don't know whether FICLONE can do that, but it sounds like a reasonable worry. If that understanding is correct, then the attached further patch should suffice, so I boldly installed it. From 123ed2df4c23e12b08e1d18245f3a0b47508496f Mon Sep 17 00:00:00 2001 From: Paul Eggert D

bug#56391: `cp --reflink=always` creates empty file on failure

Thanks for reporting that. I installed the attached patch.From 08f14d9492e35188b7ed85eb59b7e605285d8b09 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 5 Jul 2022 09:34:17 -0500 Subject: [PATCH] =?UTF-8?q?cp:=20don=E2=80=99t=20create=20empty=20file=20i?= =?UTF-8?q?f=20cannot=20clone

bug#56017: [gnu.org #1845594] coreutils POC?

Thanks for the proposal. You've obviously spent some time writing it up. However, I'm not entirely sold on the idea being worth the effort. The point of the currently-supported approach is that one can and should communicate checksums by a different (and hopefully more reliable) means than what

bug#55937: [PATCH] touch: create parent directories if needed

On 6/14/22 19:20, Alan Rosenthal wrote: `touch -p a/b/c/d/e` will now be the same as running: `mkdir -p a/b/c/d && touch a/b/c/d/e`. I don't see how this useful enough to merit a change, since one can achieve the effect of the proposed "touch -p" with the already-existing "mkdir -p" followed

bug#55895: [PATCH] maint: Fix ptr_align signature to silence -Wmaybe-uninitialized

On 6/11/22 14:18, Anders Kaseorg wrote: if you align the mutable pointer, you don’t need to separately align a const pointer. Of course one can alter code by aligning a mutable pointer first and then converting it to a const pointer, instead of first converting it to const and then aligning

bug#55910: cp error

Thanks for the bug report. I installed the attached patch, which should fix it. Please give it a try.From b54da709a1f3a6f10ed3150b0ae5269002a1053c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 11 Jun 2022 10:49:18 -0700 Subject: [PATCH] =?UTF-8?q?cp:=20fix=20=E2=80=98cp=20-rx=20/=20/mnt

bug#55895: [PATCH] maint: Fix ptr_align signature to silence -Wmaybe-uninitialized

On 6/11/22 09:30, Anders Kaseorg wrote: A pointer to uninitialized (or zero-initialized) memory that won’t be written is valid but not _useful_. But in the example I gave, the memory *is* written to later. A const * pointer lets a C program have a read-only window into memory that other parts

bug#55895: [PATCH] maint: Fix ptr_align signature to silence -Wmaybe-uninitialized

On 6/10/22 21:11, Anders Kaseorg wrote: It seems the important step I should have included was CFLAGS=-O0. Ah, OK. Since you're building from Git, I can refer you to README-hacking which is intended for that. It says, "If you get warnings with other configurations, you can run './configure

bug#55895: [PATCH] maint: Fix ptr_align signature to silence -Wmaybe-uninitialized

On 6/10/22 15:24, Anders Kaseorg wrote: ptr_align is always called with a pointer to uninitialized memory, so it does not make sense for that pointer to be const. I don't see why not. ptr_align does not modify the referenced storage so "void const *" is appropriate. If we changed the type to "

bug#55724: cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS

On 5/30/22 08:04, Pádraig Brady wrote: Really the kernel has to behave appropriately there and not do the blanket assumption with EXDEV. I agree. VFS should be willing to try a cross-filesystem FICLONE. Not only does copy_file_range not guarantee cloning; it is less efficient even when it doe

bug#55622: Bug in sort with keys and reverse, and version-sort and reverse

I installed the attached spelling fix to a comment in my previous patch.From 8c1a447a3790ec74ef919c60d46673e7be061c72 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 25 May 2022 11:49:13 -0700 Subject: [PATCH] maint: spelling fix --- src/sort.c | 2 +- 1 file changed, 1 insertion(+), 1

bug#55622: Bug in sort with keys and reverse, and version-sort and reverse

lesce duplicate code and explain why it's needed and (2) tweak performance a tiny bit. From 15627794459933d293547c2bf7d77ab196ae73a3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 25 May 2022 11:19:08 -0700 Subject: [PATCH 1/2] sort: refactor tricky diff reversal * src/sort.c

bug#55487: chmod to +w is not defaulting to ALL target in Debian 11.3

On 5/17/22 10:51, Corey H wrote: sudo chmod +w /etc/whatever/whatever.conf #doesn't work sudo chmod a+w /etc/whatever/whatever.conf #does work It sounds like you're misunderstanding what "chmod +w" means. It doesn't mean "turn on all the w bits". It means "turn on the w bits enabled by the cu

bug#55212: GNU Linux "sort -g" can hang indefinitely when run on standard input if NaNs are involved

On 5/10/22 12:08, coreut...@tlinx.org wrote:    Unless there is some magic about -n1238095, The test is random and there's no magic, just luck. The larger the random test, the more likely you'll run into the unlucky situation where the unpatched 'sort' infloops.

bug#55225: GNU Linux "sort -g" can hang indefinitely when run on standard input (on Ubuntu)

Thanks for reporting that. Fixed as described here: https://bugs.gnu.org/55212

bug#55226: Bug Found at Uname at Red hat linux

On 5/2/22 04:43, Sasi Kiran wrote: Respected GNU Team *Iam K.sasi kiran* While iam executing uname -v itself shows the Date of the linux But has i seen on uname --help it shows the *uname -v* gives the* kernel version..*... The kernel version contains the date, so there's no bug here.

bug#55212: GNU Linux "sort -g" can hang indefinitely when run on standard input if NaNs are involved

On 5/2/22 06:31, Pádraig Brady wrote: This is a bit slower of course, but since an edge case not a big concern: Yes, my thoughts too. There are ways to speed up common lots-o-NaN cases portably (I toyed with the idea of using ieee754.h), but I went with the simple approach for now. A nit: '

bug#55212: GNU Linux "sort -g" can hang indefinitely when run on standard input if NaNs are involved

Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 1 May 2022 22:46:21 -0700 Subject: [PATCH] sort: fix sort -g infloop again Problem reported by Giulio Genovese (Bug#55212). * src/sort.c (nan_compare): To compare NaNs, simply printf+strcmp. This avoids the problem of padding bits and unspecifi

bug#54785: for floating point, printf should use double like in C instead of long double

On 4/30/22 05:48, Vincent Lefevre wrote: Yes, but to be clear, POSIX says: shall be evaluated as if by the strtod() function if the corresponding conversion specifier is a, A, e, E, f, F, g, or G so the number should be regarded as a double-precision number (type double). Yes, but POSIX

bug#54785: for floating point, printf should use double like in C instead of long double

On 4/29/22 13:04, Chet Ramey wrote: I think I'm going to stick with the behavior I proposed, fixing the POSIX conformance issue and preserving backwards compatibility, until I hear more about whether backwards compatibility is an issue here. Come to think of it, as far as POSIX is concerned Ba

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

On 4/27/22 09:42, Pádraig Brady wrote: Marking this as done in the coreutils bug tracker, now that this is being tracked in glibc. This could also be worked around Gnulib for the benefit of 32-bit apps running with unpatched glibc 2.34 and 2.35, or glibc older than 2.34. Not sure it's worth t

bug#54785: for floating point, printf should use double like in C instead of long double

On 4/27/22 05:10, Glenn Golden wrote: Ok, I see what you mean, thanks for the explanation. I'll pose the question (or maybe file a bug report) on the glibc list. By the way I now think I see a reason for why glibc does things the way it does: it minimizes output size. 'double' has 53 bits c

bug#54785: for floating point, printf should use double like in C instead of long double

On 4/25/22 16:50, Glenn Golden wrote: On Mon, Apr 25, 2022, at 13:06, Paul Eggert wrote: I'd like coreutils printf to stay compatible with Bash printf. Thanks. Is there any interest/motivation for consistentizing {coreutils printf, bash printf} with glibc printf? There's a

bug#54785: for floating point, printf should use double like in C instead of long double

On 4/25/22 11:22, Chet Ramey wrote: Thanks for the input. You're welcome. Whenever you decide what to do about this, could you please let us know? I'd like coreutils printf to stay compatible with Bash printf. Thanks.

bug#54785: for floating point, printf should use double like in C instead of long double

On 4/11/22 11:52, Chet Ramey wrote: On 4/9/22 3:31 PM, Paul Eggert wrote: It sounds like there are three cases. 1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow    length modifiers for the printf utility), use long double. This would    work in both d

bug#55093: "split -n K/N " BUG: Last Chunk incomplete if input file >= 262144 bytes

On 4/24/22 07:40, Adam Holt wrote: split (GNU coreutils) 8.32 That's an old version, dated 2020. Please try the current version coreutils 9.1, which has bug fixes in this area. Also, there's no need to cc. rms and tg; they're not working on 'split' any more. Thanks.

bug#55029: Simple backup swaps source and destination files

he latest Gnulib, and to add a test case for the bug.From 7347caeb9d902d3fca2c11f69a55a3e578d93bfe Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 20 Apr 2022 19:34:57 -0700 Subject: [PATCH] backupfile: fix bug when renaming simple backups * lib/backupfile.c (backupfile_internal): Fix bug w

bug#55010: Compiling from git clone

On 4/19/22 22:54, Ken Ingram wrote: So I guess I'm on an "old" compiler compared to 11.2.1 Yes, so let's not worry about the warning, as it suggests adding clutter unnecessary in modern compilers, it's easy to ignore the warnings in older compilers, and this is an issue only when using --ena

bug#55010: Compiling from git clone

On 4/18/22 14:47, Ken Ingram wrote: Making all in . make[2]: Entering directory '/home/kingram/src/coreutils' CC lib/libcoreutils_a-randperm.o lib/randperm.c: In function 'sparse_new': lib/randperm.c:111:1: error: function might be candidate for attribute 'malloc' if it is known to retur

bug#40586: date and '%-N' does not appear to remove leading zeros anymore, but trailing zeros.

On 4/14/22 09:48, joerg.boeh...@snafu.de wrote: %N nanoseconds (0..9) The current description gives the impression that nanoseconds are an integral quantity like seconds and minutes. This leads the user to assume that leading zeros are being removed. Similar wording is u

bug#54916: 4 invalid dates reported by "date"

On 4/13/22 06:30, Martins Ozolins via GNU coreutils Bug Reports wrote: ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1981-04-01" date: invalid date ‘1981-04-01’ This is because your invocation is equivalent to: date +%s --date="1981-04-01 00:00:00" and there was no midnight at that dat

bug#54785: for floating point, printf should use double like in C instead of long double

Vincent Lefevre wrote in : $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))' 0xa.c00025cp-20 instead of 0xa.cp-20 To summarize, this test case is: printf '%a\n' 1.0251998901367188e-05 and the problem is that converting 1.0251998901367188e-05 to long doub

bug#54587: chroot: incorrectly reporting ": no such file or directory"

On 3/26/22 18:54, Kyle Glaws wrote: When the shared library is missing, execvp will set errno to ENOENT. In that event, it might be possible to stat the path to the command to confirm that the command does not exist. That would lead to a race condition, in case the file in question is removed

bug#54587: chroot: incorrectly reporting ": no such file or directory"

On 3/26/22 16:16, Kyle Glaws wrote: Looking at the source code in chroot.c, it doesn't seem impossible to add some logic that makes this error message more accurate (i.e. that a shared library is missing, not the executable itself). How? More details, please.

bug#54519: YES

On 3/22/22 06:16, bdmalex--- via GNU coreutils Bug Reports wrote: yes | zypper up; yes y | zypper up; yes 'y' | zypper up; Surely this is a problem with zypper, not with 'yes'. If it is a problem with 'yes', please give a way to reproduce the problem that doesn't involve zypper (a progr

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

On 3/7/22 06:08, Pádraig Brady wrote: * lib/fcntl.in.h: Define AT_NO_AUTOMOUNT to 0 where not defined. This is available on Linux since 2.6.38. Looks good. Please feel free to install this sort of thing without waiting for review.

bug#44770: chown: warn when encountering deprecated dot separator

Thanks for the suggestion. I installed the attached patches to do that.From 320b3f8c96fc69670475c7a39d5818c5b4755912 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 24 Feb 2022 18:05:03 -0800 Subject: [PATCH 1/2] build: update gnulib submodule to latest --- gnulib | 2 +- 1 file changed

bug#54124: fmt inserts garbage in certain cases?

On 2/23/22 17:29, Pádraig Brady wrote: Given isspace('\n') returns true, then it makes some sense that isspace("Next Line") would return true, POSIX says that the application must insure that argument to isspace is either EOF or "a character representable as an unsigned char", and arguably s

bug#46808: Man page of "tail"

On 2/26/21 23:32, Reuti wrote: I noticed some formatting issues in the man page of `tail`, and I wonder whether they are intentional as they occur at some places. They happen up to version 8.32: line: "-c, --bytes=[+]NUM" the "[" is in italic: \fB\-c\fR, \fB\-\-bytes\fR=\fI\,[\/\fR+]NUM line

bug#54112: dd seek_bytes etc. is confusing

155cc945db54ab541594f3a59cfe808bc9aea3fd Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 22 Feb 2022 18:27:09 -0800 Subject: [PATCH] dd: counts ending in "B" now count bytes This implements my suggestion in Bug#54112. * src/dd.c (usage): Document the change. (parse_integer, scanargs):

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

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,

bug#54112: dd seek_bytes etc. is confusing

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 instead say that if you want to use byte cou

bug#47151: closed (Re: bug#47151: cp --recursive funky behaviour)

On 2/21/22 10:49, Tomas wrote: I found this, I am not sure whether it's the right specs. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ Yes, or more precisely for 'cp': https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html "2) f) The files in the directory sourc

bug#47151: cp --recursive funky behaviour

On 3/14/21 17:47, Tomas wrote: cd /tmp mkdir src touch src/a cp -r src dest #damn, I forgot a file touch src/b cp -r src dest ls dest # a dest cp has behaved that way for ages, and is required to behave that way by POSIX, so this is not a bug. To sidestep the issue, you can use the -T option

bug#47891: sort --numeric-sort-Extra-Strength

On 4/19/21 06:15, 積丹尼 Dan Jacobson wrote: Let's face it, sort, no matter what --option, or LC_... value, just can't achieve this order: 3－1號邊 3號之1 3號之2 30 Plain 'sort -n' works for me, in my en_US.utf8 locale. :-) I do take your point, though, that GNU 'sort' does not support sorting by Taiw

bug#47059: bug in cp removing destination file when it can't be replaced due to cross-volume linking

I can't reproduce the problem with either coreutils 8.23 or 9.0. Unfortunately, the original bug report does not have a recipe for reproducing the problem from scratch, without having access to your system. If you could come up with the a self-contained way to reproduce the problem with current

bug#48002: unmerging separate bug reports about cp etc.

A while back I merged GNU Coreutils bug reports 47059, 47883, and 48002. I now see that that was a mistake as they're about three different issues. So, I'm unmerging the bug reports and will look at each separately. The main topic of bug#48002 is not a bug in Coreutils; it's about the bug-repo

bug#48085: date -d greater than 23 years ago gives error invalid date

ep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 19 Feb 2022 15:04:43 -0800 Subject: [PATCH] mktime: improve heuristic for ca-1986 Indiana DST Problem reported by Mark Krenz <https://bugs.gnu.org/48085>. * lib/mktime.c (__mktime_internal): Be more generous about accepting arguments with the

bug#53977: Improve markup in man pages

On 2/14/22 15:00, Pádraig Brady wrote: I see Paul added the grep markup recently in a seemingly unrelated change: https://git.savannah.gnu.org/gitweb/?p=grep.git;a=commit;h=fe630c9f In the old days man pages' SEE ALSO sections mostly didn't use markup for references to other man pages. I see on

bug#48248: tr docs: mention what to expect now vs. future

ighborhood.From 8d3dce9861c15f06a014c91fa29c15143fd27127 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 14 Feb 2022 12:00:16 -0800 Subject: [PATCH 1/2] tr: improve multibyte etc. doc Problem reported by Dan Jacobson (Bug#48248). * doc/coreutils.texi (tr invocation): Improve documentation for tr'

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

On 2/14/22 01:41, Stéphane Archer wrote: is +'%Y-%m-%dT%H:%M:%S.0Z' do what I want To format an arbitrary timestamp you want "+%Y-%m-%dT%H:%M:%S.%1NZ", unless you always want a zero after the period. Closing the bug report as there's no bug here.

bug#49239: Unexpected results with sort -V

s. Thanks, Michael, for reporting the problem. I'm boldly closing the Coreutils bug report as fixed.From 9f48fb992a3d7e96610c4ce8be969cff2d61a01b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 12 Feb 2022 16:27:05 -0800 Subject: [PATCH] filevercmp: fix several unexpected results Pro

bug#49503: Mention workarounds, so one could achieve the Debian version sorting algorithm

o use dpkg --compare-versions (on pairs only.) Thanks for mentioning that. I looked over the version-sort doc and fixed that problem along with some other stuff I noticed while in the neighborhood, by installing the attached patch.From cedf627a901e067ad3a63f0fc20f3376ed59786e Mon Sep 17 00:0

bug#50694: ls and cpio's idea of "six months ago" are slightly different

io on Savannah. If you give me privileges I can install these patches; otherwise, please take a look and install if you like. Thanks.) In the meantime I'll close the coreutils bug report, as I don't think we need to change GNU 'ls'.From d2e015a718edb00dfe35d641354c5adb85fb5a

bug#50115: date command arithmetic involving the epoch produces "invalid date"

Thanks for the bug report. I installed the attached patches to Gnulib and to Coreutils, and the fix should be in the next Coreutils release.From aa0d1e7800903f2d75432d78aa64a0e9770e83f2 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 5 Feb 2022 11:05:44 -0800 Subject: [PATCH] parse

bug#51288: Break date SYNOPSIS into two sections

and but we might as well be clear about it, if only for nostalgia's sake.From 45f8f2dd2b54c7f4745c277e3f52f3c99cea5b57 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 4 Feb 2022 18:21:06 -0800 Subject: [PATCH] date: improve doc Problem reported by Dan Jacobson (Bug#51288). * doc/coreu

bug#53631: coreutils id(1) incorrect behavior

;.From 1204c5132d61efbb966fb2a94b4dc7463beddfe1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 4 Feb 2022 14:43:31 -0800 Subject: [PATCH] id: print groups of listed name Problem reported by Vladimir D. Seleznev (Bug#53631). * src/id.c (main): Do not canonicalize user name before deciding what groups the user belongs to. ---

bug#50745: coreutils-8.32 gnulib test results on hppa HP-UX 11.11

Thanks, that's a Gnulib report so I've forwarded it to bug-gnulib here: https://lists.gnu.org/r/bug-gnulib/2022-01/msg00177.html and am closing the Coreutils bug.

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

I found a bit of time to work on this and installed the attached patch, which should address the issue. Thanks for reporting it.From 3368b8745046aeaa89f418f560e714b374f1a560 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 28 Jan 2022 00:01:07 -0800 Subject: [PATCH] dd: synchronize output

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

On 11/7/21 23:04, Paul Eggert wrote: https://github.com/openzfs/zfs/issues/11900#issuecomment-962812974 Apparently the OpenZFS bug has been fixed, as behlendorf closed it 20 days ago. Since there doesn't seem to be a good way for coreutils to work around the bug, and the bug potent

bug#51482: dd with status=progress does not update its output when the main writing is finished

:00 2001 From: Paul Eggert Date: Thu, 27 Jan 2022 18:34:09 -0800 Subject: [PATCH] dd: output final progress before syncing Problem reported by Sworddragon (Bug#51482). * src/dd.c (reported_w_bytes): New var. (print_xfer_stats): Set it. (dd_copy): Print a final progress report if useful before

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

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.gnu.org/cgit/coreutils.git/commit/?id=

bug#53037: df/total-verify fail with cephfs

On 1/5/22 15:25, Dylan Simon wrote: Hrm, no, with this patch it still fails, but differently (sorry so many filesystems): OK, then perhaps someone with a bit more free time will have to look at it - unless you can propose a patch that passed "make check".

bug#53037: df/total-verify fail with cephfs

On 1/5/22 14:11, Dylan Simon wrote: Then it will look like this (I'm inferring, haven't actually tried it): I'm still not quite following, but does the attached patch address the problem?diff --git a/src/df.c b/src/df.c index b803fc73b..8a0293ca9 100644 --- a/src/df.c +++ b/src/df.c @@ -127,6

bug#53037: df/total-verify fail with cephfs

On 1/5/22 11:27, Dylan Simon wrote: Only adding rows with all known values might make sense but would still break the test (wrong total total instead): if (known_value (iv->total) && known_value (iv->available)) { grand_fsu.fsu_files += iv->total; grand_fsu.fsu_ffree += iv->availabl

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

On 1/5/22 00:44, Joerg M. Sigle wrote: "When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not." By that standard it'll be a bug no matter what the maintainers do, since feelings are strong on both sides of the issue. So by this reasoning, maintaine

bug#17774: AIX and lbracket ([) program - will not install on AIX using installp

On 6/14/14 10:28, Paul Eggert wrote: That part of POSIX has been standardized since POSIX.2 (IEEE Std 1003.2-1992), and the wording hasn't changed since then if I recall correctly, so AIX has had this conformance bug for decades and nobody has cared I just ran into a related pr

bug#52873: expr unexpected syntax error

On 12/29/21 12:01, Martin Rixham wrote: What nonsense. I want to parse source code. ')' is not an uncommon line of source code. It should work. Unfortunately, you're asking for what is in general impossible. If the left argument of ':' could be any string, then the grammar for 'expr' would be

bug#52873: expr unexpected syntax error

On 12/29/21 08:31, Davide Brini wrote: I think you need to use '+' before the offending token Yes. That's a GNU extension. If you want to be portable to any POSIX implementation, you can use this instead: expr "X(" : '.*' - 1 A similar example is given in the POSIX spec for 'expr': https:/

bug#52844: missing perl not recognized properly by configure

that's wrong we can reopen it. From c7bbfeb80c4be8d55074214e98c236eed8015a15 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 28 Dec 2021 01:53:44 -0800 Subject: [PATCH 1/2] build: update gnulib submodule to latest --- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --gi

bug#52782: Man Page: Incorrect Summary of --color Option

eport.From 2269ea5aa2b8579ed2ec22407f55de4fd7218e4b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 24 Dec 2021 15:25:29 -0800 Subject: [PATCH] ls: improve doc for =WHEN * src/ls.c (usage): Improve clarity of =WHEN args (Bug#52782). --- src/ls.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) di

bug#52782: Man Page: Incorrect Summary of --color Option

could chip in. In the meantime I noticed that the documentation uses the word "colorize" when it should say "color", so I installed the attached.From 2b30312f77f99efc8c56804424c4a317e25953f1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 24 Dec 2021 09:47:18 -0800 Subj

bug#52656: (id) utility bug found

On 12/19/21 06:58, Glenn Golden wrote: Possibly the man page could be updated to say the same. Thanks for the suggestion. I installed the attached documentation patch and am closing the bug report.From d3beb53be64a958988a94ed86e6246a21dc95a9c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

On 12/15/21 14:24, Mike Marchywka wrote: if date is going to be a swiss army knife for date conversions it makes some sense to allow user selection of ambiguity resolution doesn't it? There are thousands of possible data conversions and I'm not sure we want to head down the road of trying to

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

On 12/15/21 12:39, Mike Marchywka wrote: $echo 2000 | date +%Y -f- 2021 How about this instead? The idea is to avoid adding features if they can easily be implemented with some other standard utility. This way, you can write your shell scripts now rather than waiting for a future fix (plus,

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

he attached to implement this fix, the first patch into Gnulib, the second into coreutils.From dd474e50930ea00910631eb1b77ff4270d7b02c0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 14 Dec 2021 12:32:30 -0800 Subject: [PATCH] renameatu: port to macOS tmpfs MIME-Version: 1.0 Content-Type:

bug#52453: Full timezone name

On 12/12/21 07:27, 積丹尼 Dan Jacobson wrote: Also mention something about how to get the full timezone name. Unfortunately at the coreutils level that information is not available in any portable or reliable way.

bug#52410: "mv -T --backup=numbered hello world/" renameat2 infinite loop

coreutils and add a regression test.From d1b9e7c84959fb0f7014f03fc8746caa125f3d55 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 10 Dec 2021 13:31:02 -0800 Subject: [PATCH 1/3] backupfile: fix numbered backups for XXX/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

From 9fe50d31aa75dd2d896225c2d1993f0b8eef2f26 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 8 Dec 2021 19:14:25 -0800 Subject: [PATCH] renameatu: port to macOS tmpfs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Sudhip Nashi (Bug#52193). * lib/rename

bug#52330: Different processor architecture on Apple M1 CPU

On 12/7/21 15:33, Jakub Sokołowski via GNU coreutils Bug Reports wrote: when is a new release planned for? I guess not before 2022? No current plans as far as I know.

bug#52330: Different processor architecture on Apple M1 CPU

Thanks for checking. I installed the patch and am closing the bug report.

bug#52330: Different processor architecture on Apple M1 CPU

On 12/7/21 04:03, Jakub Sokołowski wrote: src/uname.c:170:41: error: unknown type name 'MAYBE_UNUSED' I suspect you applied the patch to coreutils 9.0, which doesn't work. The patch needs to be applied to bleeding-edge coreutils built from Git

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

On 12/6/21 20:40, Sudhip Nashi wrote: The issue should be reproducible when moving directories and files within ~/mntpnt, but not between that filesystem and the parent APFS one, and vice versa. Thanks, but as I don't have access to a macOS machine I don't know what "the issue" is. What are

bug#52330: Different processor architecture on Apple M1 CPU

t the default uname utility on MacOS returns arm. Does the attached patch fix things for you? Unfortunately I don't have access to macOS to test it.From 202befd373ea4c851e4c3be85c52eeb108c6c7be Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 6 Dec 2021 14:39:22 -0800 Subject: [PATCH] unam

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