bug#46048: split -n K/N loses data, sum of output files is smaller than input file.

On 1/24/21 8:52 AM, Pádraig Brady wrote: -  if (lseek (STDIN_FILENO, start, SEEK_CUR) < 0) +  if (lseek (STDIN_FILENO, start, SEEK_SET) < 0) Dumb question: will this handle the case where you're splitting from stdin and stdin is a seekable file and its initial file offset is nonzero?

bug#45924: RFE: rmdir -r: recursively remove [empty] directories under the target.

On 1/18/21 8:08 AM, Bernhard Voelker wrote: On 1/17/21 11:18 PM, Paul Eggert wrote: find DIR -depth -type d -exec rmdir {} + find(1) can also find empty directories and delete them: $ find DIR -type d -empty -delete Thanks, I'd forgotten about that. I added the attached to the manual

bug#45924: RFE: rmdir -r: recursively remove [empty] directories under the target.

On 1/18/21 2:53 AM, L A Walsh wrote: Except that 'find DIR -depth -type d -exec rmdir {} +' is anything but simple and not something anyone outside of a minority of *nix users would have a clue about how to create, whereas 'rmdir -r DIR' is both direct and simple and more easily understandable

bug#45924: RFE: rmdir -r: recursively remove [empty] directories under the target.

On 1/16/21 4:29 PM, L A Walsh wrote: Yes, you could do it some other way, like by using 'find' That's what I'd do, yes. 'find DIR -depth -type d -exec rmdir {} +'. I doubt whether it's worth hacking on this at the C level (complicating the documentation too) when there's such a simple and

bug#14371: bug#45886: mkdir -m argument does not work correctly, applies incorrect permissions

Thanks for the bug report. I reproduced the problem and installed the attached patch to fix it. >From b8375c422ffe0e018cbb4cad187d1e909195d263 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 15 Jan 2021 02:57:59 -0800 Subject: [PATCH] mkdir: fix bug when -m's more generous than um

bug#45749: [gnu.org #1673209] [Coreutils manual] Broken page link (from and to gnu.org)

rom: Paul Eggert Date: Sat, 9 Jan 2021 13:04:40 -0800 Subject: [PATCH] doc: modernize and fix regexp xref MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * doc/coreutils.texi: Fix regexp cross-reference that had become out-of-date (Bug#45749). Also, fix s

bug#45700: rm should not prompt if ! isatty(2)

On 1/6/21 10:56 AM, John Wiersba via GNU coreutils Bug Reports wrote: $ touch asdf && chmod a-w asdf && rm asdf 2>&1 | catrm: remove write-protected regular empty file 'asdf'?  # should*not* prompt If the prompt cannot be seen, then it can't be properly answered, so there is no point

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

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 think your patch (or something like it) should go in. I'll wait for a bit to

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

On 1/4/21 3:07 PM, Bernhard Voelker wrote: I previously encountered a `dd` implementation which also accepted 'oseek=N' and 'iseek=N', which I found far more natural and easy to remember. What 'dd' implementation was this specifically? Solaris dd has iseek and oseek. However, they are not

bug#45258: mkdir man page unclear in describing -m flag

Thanks for your bug report. I installed the attached patch; although it doesn't use the exact wording you proposed, I hope it works well enough. >From 3ee0e25426a513c5da891ce6a370abed156a3b83 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 15 Dec 2020 11:52:19 -0800 Subject: [PATCH]

bug#45093: Character 149 causing ASCII BEL output to console in Windoze port of Gnu CoreUtils

On 12/7/20 11:38 AM, Robert S. Kissel wrote: If you could possibly direct me to the maintainers of the pre-compiled Windoze port (I'm certain that I downloaded it from the gnu.org Web-site) Sure about that? I'm not aware of any. At any rate, whereever you downloaded it from should have

bug#45093: Character 149 causing ASCII BEL output to console in Windoze port of Gnu CoreUtils

On 12/6/20 8:23 PM, Robert S. Kissel wrote: I'm pretty sure this is a bug in the Windoze port of head and tail, You should have better luck writing directly to the people who prepared that port, as they don't hang out on this mailing list and we largely don't worry about MS-Windows.

bug#44763: Error when 'make'ing latest version of coreutils

Thanks for reporting your recipe for working around all these problems. I've installed patches for the problems into coreutils and gnulib and am closing the bug report. On 11/21/20 3:45 PM, Chris Elvidge wrote: git commit -m 'build: update gnulib submodule to latest' gnulib 2>&1 | tee -a

bug#44763: Error when 'make'ing latest version of coreutils

| 5 + lib/parse-datetime.y | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index de92d102e..229945e86 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2020-11-21 Paul Eggert + parse-datetime: fix printf format typo + * lib/parse-d

bug#44763: Error when 'make'ing latest version of coreutils

On 11/21/20 5:17 AM, Pádraig Brady wrote: The info in https://bugs.gnu.org/44739 must be incorrect, and we've two counter checks to it now. Yes, that sounds right. Closing that bug report.

bug#44704: uniq: replace repeated lines with a message about how many repeated lines

On 11/17/20 5:32 AM, Brian J. Murrell wrote: > [previous line repeated 4 times] uniq -c already does something like that, though it outputs "5" instead of "4". Not sure it's worth gussying up 'uniq' to provide exactly the functionality requested, as output reformatting is easy enough to do

bug#44695: error - GraphClust2 docker

On 11/16/20 10:58 AM, Christina Palka via GNU coreutils Bug Reports wrote: I got the following error when attempting to install GraphClust2 using Docker on Mac. tail: unrecognized file system type 0x794c7630 for ‘/home/galaxy/logs/uwsgi.log’. please report this to bug-coreut...@gnu.or Thanks

bug#44587: ls prints garbage when listing contents of a directory without exec permissions

On 11/11/20 3:24 PM, Jan Schaumann wrote: $ ls -la dir ls: cannot access dir/.: Permission denied ls: cannot access dir/..: Permission denied ls: cannot access dir/file: Permission denied total 0 d? ? ? ? ?? . d? ? ? ? ?? .. -? ? ? ? ??

bug#44248: Indentation of --help and --version

One way to attack the problem is (1) use only one-liners for option help, and (2) not worry about indentation so much (either in English or in German) as the excess indenting doesn't help readability enough to justify the translation hassle. To do that, I propose changes like the attached for

bug#43828: invalid date converting from UTC, near DST

On 10/6/20 4:24 AM, Martin Fido wrote: I have version 8.25: Seems to have been fixed by coreutils 8.30: $ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z' Sun 04 Oct 2020 01:00:00 PM AEDT

bug#43657: rm does not delete files

On 9/27/20 8:58 PM, Amit Rao wrote: There's a limit? My first attempt didn't use a wildcard; i attempted to delete a directory. 'rm dir' fails because 'rm' by default leaves directories alone. My second attempt was rm -rf dir/* If "dir" has too many files that will fail due to shell

bug#43657: rm does not delete files

On 9/27/20 1:00 PM, Amit Rao wrote: rm /path/* does not delete files if there are a lot (say 2000) of them in a single directory What does the command do instead? There is a limit as to how many arguments you can pass to 'rm'. If that's what you ran into, it's a problem with your kernel or

bug#43497: ls exit status on removed directory

On 9/18/20 4:15 PM, Philip Rowlands wrote: $ mkdir /tmp/abc $ cd /tmp/abc $ rmdir /tmp/abc $ ls What happened: no output, successful exit status What was expected: no output, unsuccessful exit status POSIX says that the rmdir command is supposed to behave like the rmdir syscall. For the

bug#43415: coreutils 8.32: install: fchmod fails with EBADF

On 9/14/20 6:31 PM, Cameron Nemo via GNU coreutils Bug Reports wrote: It seems like relying on the /proc link is not ideal, and a bug is being hidden by such behavior. Is there any chance that this can be resolved? It really should be fixed in the Linux kernel: it needs a proper way to

bug#43162: chgrp clears setgid even when group is not changed

On 9/1/20 3:30 PM, Karl Berry wrote: I was on centos7. (I don't observe your problem on my Fedora 31 box, for example). Maybe there is hope for a future centos, then. Maybe. Or it could be a filesystem or mounting issue. My filesystem was ext4 mounted rw,relatime,seclabel, for what

bug#43162: chgrp clears setgid even when group is not changed

On 9/1/20 2:25 PM, Karl Berry wrote: Is it necessary for chgrp to clear setgid on directories even when the group is not actually changed? In my life at least, it is rather annoying. The chgrp command isn't doing that directly; it's merely invoking the fchownat syscall, and the syscall is

bug#42804: mkdir saying it can't create folder although it created it

On 8/11/20 3:03 PM, Nick Levinson via GNU coreutils Bug Reports wrote: I don't know what an example transcript is Ah, I was asking for the output of a shell session (or however you invoked 'mkdir'). The idea is that we would like to reproduce the bug, and need a recipe to do that. If

bug#42804: mkdir saying it can't create folder although it created it

On 8/10/20 11:48 AM, Nick Levinson via GNU coreutils Bug Reports wrote: When I use mkdir, when it succeeds sometimes it has no message, which is acceptable, but sometimes it says this: mkdir: cannot create directory '': File exists But the directory didn't exist before I used mkdir to make it,

bug#42766: file names with spaces are quoted in the output from ls

On 8/8/20 9:09 AM, David Thomas wrote: If most people think things are a bad idea, why do them? I don't see any real evidence that most people think the change is a bad idea. Although there have been complaints, that doesn't mean most people are complaining, or that most people are unhappy

bug#42470: Help text update suggestion for "date" util

On 7/25/20 8:07 AM, Wes Novack wrote: Thank you! For future reference, what is the PR process? See: https://debbugs.gnu.org/ and look for "read more" if you're interested.

bug#42358: mv w/mkdir -p of destination

On 7/14/20 3:36 PM, L A Walsh wrote: But I've found asking for features usually doesn't work and sometimes results in work to preclude future implementation of the feature. Reporting bugs also, often gets ignored until some large company reports the same problem or until it causes a serious

bug#42269: Remove non-GMP code from coreutils factor.c

>From ba1489d763b66dd1fcec08ecb4cba5917745f6bf Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 8 Jul 2020 18:58:18 -0700 Subject: [PATCH] factor: explain why non-GMP code (Bug#42269) * doc/coreutils.texi (factor invocation): * src/factor.c: Explain why the two-word algorithm is useful.

bug#42269: Remove non-GMP code from coreutils factor.c

On 7/8/20 9:57 AM, Torbjörn Granlund wrote: The non-GMP code of coreutils was extremely well-tuned by me and Niels Möller a couple of years ago. How time flies! The code was merged in 2012. By leaving just the GMP code, you would create a pretty useless factor command. Any naive old factor

bug#42211: Problem in sort

On 7/5/20 9:53 PM, Richard Freedman wrote: > I discovered that trying to use -c with --debug causes an error - but not in > the version that I have > on my mac laptop ! Ah, I had meant to suggest using --debug without -c. > when I try to specify a "key" even for a file with only 1 column - the

bug#42211: Problem in sort

On 7/4/20 2:39 PM, Richard Freedman wrote: > When I use sort -n -c on a specified column in a file sort reports an error > and then stops if two numbers are exactly the same. Could you send us the input, and the output of "sort --debug -n -c -k3" (assuming you're using column 3)? My guess is

bug#8061: Introduce SEEK_DATA/SEEK_HOLE to extent_scan module

ic use of the copy_file_range syscall introduced in Linux kernel 4.5 (2016) and reworked in 5.3 (2019). This should improve 'cp' performance on kernels and file systems that support copy_file_range. >From 4fe5259ab6c9e459a6db5938d143a9c65be113d9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 25 Jun 2020

bug#41944: cp: default to --reflink=auto, revisted

Thanks, I'd forgotten that. The performance improvement is long overdue, so I installed the attached. >From 25725f9d41735d176d73a757430739fb71c7d043 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 18 Jun 2020 22:16:24 -0700 Subject: [PATCH] cp: default to COW MIME-Version: 1.0 Content-T

bug#41664: du give file not accessible

On 6/2/20 2:42 AM, Sumit Gupta wrote: > Is this expected or shall the command be modified to ignore such files? It does seem reasonable that 'du' should ignore a file when the system call says ENOENT, since the file isn't there and cannot be consuming disk space.

bug#37702: Suggestion for 'df' utility

On 5/30/20 4:49 AM, Erik Auerswald wrote: > I concur that a command line option to override config file (or env var) > settings seems useful if a config file and/or env var approach is used. In other utilities we've been moving away from environment variables and/or config files for the usual

bug#41554: chmod allows removing x bit on chmod without a force flag, which can be inconvenient to recover from

On 5/26/20 6:30 PM, Will Rosecrans wrote: > The underlying safety logic is similar to that behind the > existing "--(no-)preserve-root" I think not. There are all sorts of other things one shouldn't chmod either, but we can't and shouldn't maintain a long list. Let's stop with "/".

bug#41480: Chars out of order in date.c string

On 5/23/20 4:41 AM, Anders Jonsson wrote: > I noticed one thing when having a look at the Swedish translation of > coreutils. > >>#: src/date.c:196 >>msgid "" >>"  %F   full date; like %+4Y-%m-%d\n" There must be some confusion here, because this translation is for coreutils 8.31 and later. >

bug#41001: mkdir: cannot create directory ‘test’: File exists

On 5/7/20 7:06 PM, Eric Blake wrote: > > (My personal wish: I would love a variation of mkdir that returns an open fd > on > the just-created directory on success in a single syscall, Yes! That would be a worthy addition.

bug#41001: mkdir: cannot create directory ‘test’: File exists

On 5/2/20 3:41 PM, Jonny Grant wrote: > Is a more accurate strerror considered unreliable? > > Current: > mkdir: cannot create directory ‘test’: File exists > > Proposed: > mkdir: cannot create directory ‘test’: Is a directory I don't understand this comment. As I understand it you're proposing

bug#41001: mkdir: cannot create directory ‘test’: File exists

On 5/2/20 6:26 AM, Jonny Grant wrote: > If developers have race conditions in their shell scripts I've personally fixed a bug in the GNU mkdir command that was triggered by such races. Core utilities should be reliable even when these races are happening.

bug#41001: mkdir: cannot create directory ‘test’: File exists

On 5/1/20 1:21 PM, Jonny Grant wrote: > yes, the fix pretty trivial for mkdir as you highlight EISDIR: > stat(), S_ISDIR(sb.st_mode), and set errno to EISDIR or output > strerror(EISDIR) That would introduce a race condition, and wouldn't behave correctly if some other process changes the

bug#41001: mkdir: cannot create directory ‘test’: File exists

On 5/1/20 9:16 AM, Jonny Grant wrote: > rm: cannot remove 'test': Is a directory That's because rm used unlink which failed with EISDIR, which is a different error number. Consider this example: $ >d # Create an empty regular file. $ mkdir d mkdir: cannot create directory ‘d’: File

bug#40904: listing multiple subdirectories places filenames in different columns between each subdirectory

On 4/27/20 7:36 AM, Jim Clark wrote: > When I list a hard drive "ls -AR > list.txt" and import it into Libreoffice > Calc, then break the lines using "text-to-columns", I am not able to > perform a fixed format break so that the filenames are placed in their own > column. I can't reproduce the

bug#40509: Use of fsetxattr() in cp tickles an EXT leak (possibly unnecessarily so)

On 4/15/20 7:11 AM, Gregg Leventhal wrote: +xattr_size = flistxattr(src_fd, list, size); +if ( xattr_size || errno == ERANGE ) Surely this should be 'if (flistxattr (src_fd, NULL, 0) < 0 && errno == ERANGE)'. If you agree with this direction, I can continue, addressing other

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

On 4/12/20 1:51 PM, Drake Jacovian wrote: Obviously, removing trailing zeroes will changes it value. %-N is intended to be used after a decimal point, so removing trailing zeros does not change its value in its intended use.

bug#40540: Faster sort with locale

On 4/10/20 6:19 AM, Ole Tange wrote: But would it be possible to convert the input string1 into a string in a generalized format, which would sort the same way as the localized sort, but using a simple compare? I tried doing that a long time ago by using strxfrm, but it made 'sort'

bug#40509: Use of fsetxattr() in cp tickles an EXT leak (possibly unnecessarily so)

On 4/8/20 7:15 AM, Gregg Leventhal wrote: rsync doesn't make set/get xattr calls and purports to preserve ACLs with -A. I'm not quite following your bug report, but it appears that you're saying that cp could somehow discover that it needn't use fgetxattr and fsetxattr on files that lack

bug#40220: date command set linux epoch time failed

On 3/29/20 9:32 PM, Bob Proulx wrote: Both calls from GNU date are returning EINVAL. Those are Linux kernel system calls. Those Linux kernel system calls are using CLOCK_MONOTONIC. OK, I think I understand now. For some reason Linux prohibits you from setting CLOCK_REALTIME to a value less

bug#40220: date command set linux epoch time failed

On 3/28/20 9:12 AM, Bob Proulx wrote: By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2): GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant to this bug report? Is this some busybox thing? If so, user 'shy' needs to report it to the busybox people,

bug#40220: date command set linux epoch time failed

On 3/27/20 11:52 PM, Bob Proulx wrote: I tested this in a victim system and if I was very quick I was able to log in and set the time to :10 seconds but no earlier. Sounds like some sort of atomic-time thing, since UTC and TAI differed by 10 seconds when they started up in 1972. Perhaps the

bug#39929: coreutils-8.32 fails to build on aarch64

:00:00 2001 From: Paul Eggert Date: Sat, 7 Mar 2020 10:29:51 -0800 Subject: [PATCH] ls: improve removed-directory test * tests/ls/removed-directory.sh: Remove host_triplet test. Skip this test if one cannot remove the working directory. >From a suggestion by Bernhard Voelker (Bug#39929). --- te

bug#39929: coreutils-8.32 fails to build on aarch64

On 3/5/20 1:43 PM, Paul Eggert wrote: Why is this code even there at all? If readdir(3) says that the current directory has no entries, shouldn't 'ls' just say that? Why should ls report an error simply because the current directory isn't reachable from the filesystem? Whether the current

bug#39929: coreutils-8.32 fails to build on aarch64

On 3/5/20 9:39 AM, Pádraig Brady wrote: Ah well. Does the attached address this for you. Eeeuw. Why is this code even there at all? If readdir(3) says that the current directory has no entries, shouldn't 'ls' just say that? Why should ls report an error simply because the current directory

bug#39850: "du" command can not count some files

I don't see a bug there, as the files you say "du" is not counting have counts of zero.

bug#38627: uniq -c gets wrong count with non-ascii strings

On 2/23/20 11:43 AM, Pádraig Brady wrote: #include "hard-locale.h" #include "posixver.h" #include "stdio--.h" -#include "xmemcoll.h" Please also remove the '#include "hard-locale.h"' line. Thanks for fixing this.

bug#39693: Sv: bug#39693: Any chance of fixing --rfc-3339 to conform to the standard?

On 2/20/20 11:56 PM, Mads Bondo Dydensborg wrote: Your statement is in conflict with the message exchange, referenced by the bug I linked to, with, as I understand it, the authors of the standard: Not really. In that email exchange one of the authors of the RFC mentioned a goal of the RFC.

bug#39693: Any chance of fixing --rfc-3339 to conform to the standard?

On 2/20/20 4:39 AM, Mads Bondo Dydensborg wrote: As have been established in 2006 and again in 2010, the rfc-3339 mandates the use of "T" in a single field timestamp. No, RFC 3339 explicitly allows the use of space. It says: NOTE: ISO 8601 defines date and time separated by "T".

bug#39611: coreutils v8.31 fails to compile with -Ofast

On 2/14/20 3:21 PM, zsugabubus wrote: $ export CFLAGS=-Ofast # Works with -O3 $ ./configure && make Coreutils (and many other programs) is not compatible with -Ofast, which is not surprising as -Ofast is documented to not work in many cases. The obvious workaround is to not use -Ofast.

bug#39236: [musl] coreutils cp mishandles error return from lchmod

:00 2001 From: Paul Eggert Date: Fri, 7 Feb 2020 16:34:12 -0800 Subject: [PATCH] fchmodat: AT_SYMLINK_NOFOLLOW fix for non-symlinks Fix lchmod, and fchmodat with AT_SYMLINK_NOFOLLOW, so that they act like chmod on non-symlinks. * NEWS: * doc/glibc-functions/lchmod.texi (lchmod): * doc/posix-functi

bug#39273: unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils

al reserve: 141.11MiB (used: 0.00B) ) = 46 write(1, "\n", 1 ) = 1 ioctl(3, BTRFS_IOC_SPACE_INFO, {space_slots=0} => {total_spaces=4}) = 0 ioctl(3, BTRFS_IOC_SPACE_INFO, {space_slots=4} => {total_spaces=4, spaces=...}) = 0 write(1, "Data

bug#39273: unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils

On 1/29/20 5:42 AM, Wismerhill wrote: i tried to replicate the error, but i couldn´t do it exact the same procedure, the Disk was all ready filled up to 70%, and was not empty like when the error appeared. I couldn´t move the files away due a space problem. I tried with my Musicarchiv (ca.

bug#39273: unwanted behavior in the combination of an scenario regarding btrfs, ssh, borg, and 'df' from the core utils

On 1/24/20 11:50 AM, Wismerhill wrote: 'df' reports a wrong space calculation What's wrong about the space calculation? Please give the 'df' command that you ran, its faulty output, and also the output of 'strace' applied to the 'df' command that you ran. For example, on my machine, 'strace

bug#39236: [musl] coreutils cp mishandles error return from lchmod

On 1/22/20 7:08 AM, Florian Weimer wrote: I think you misread what I wrote: lchmod*always* returns ENOSYS. Even if the file is not a symbolic link. Likewise, fchmodat with AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP. That's too bad, because coreutils (and many other applications, I

bug#38627: uniq -c gets wrong count with non-ascii strings

On 12/15/19 11:40 AM, Roy Smith wrote: > With the following input: > >> $ cat x >> "ⁿᵘˡˡ" >> "ܥܝܪܐܩ" > > > Running "uniq -c" says there's two copies of the same line! > >> $ uniq -c x >> 2 "ⁿᵘˡˡ" Thanks for the bug report. I expect this is because GNU 'uniq' uses the equivalent of

bug#38299: A bug while trying to decode a non encode base64

On 11/20/19 6:22 AM, Martin Schulte wrote: vardhamanbn1 is a valid encoding Thanks for explaining; closing the bug report.

bug#38168: shred vs. SSD

, it would be a good thing to have (if only to discourage even more users from using 'shred' :-). In the meantime I'll take the liberty of closing the bug report. >From adf41d7c1e8adf11857ee53d51419e218dcd8804 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 11 Nov 2019 16:52:47 -0800 Subj

bug#37961: Bug report of date commond

On 10/28/19 12:34 AM, zhangzhi...@mail.iap.ac.cn wrote: ~>date -d "1940-06-01" +"%Y-%m-%d" date: invalid date ‘1940-06-01’ Presumably your TZ setting is Asia/Shanghai, as I see the symptoms as follows: $ TZ=Asia/Shanghai date -d "1940-06-01" +"%Y-%m-%d" date: invalid date ‘1940-06-01’

bug#37893: fixes for 'shuf -n 0x' and similar issues

Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 22 Oct 2019 11:34:56 -0700 Subject: [PATCH 1/5] build: re-enable type-limits checking * configure.ac: When --enable-gcc-warnings is used, omit -Wno-type-limits. The need for -Wno-type-limits has passed, now that intprops.h uses builtin primiti

bug#37877: Fix 'shuf -n 0x' and similar problems

used-parameter]) # Too many warnings for now gl_WARN_ADD([-Wno-format-nonliteral]) -- 2.21.0 >From 6778871f67c6a66aacc76b0a63ff26c8b72dce87 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 22 Oct 2019 12:52:52 -0700 Subject: [PATCH 2/5] =?UTF-8?q?build:=20don=E2=80=99t=20worry=20about=20lo?= =

bug#37859: [PATCH] shuf: fix bug with ‘-r -n 0’

‘shuf -r -n 0 file’ would mistakenly read from standard input. Problem reported by my student Jingnong Qu while reimplementing a shuf subset in Python as an exercise in UCLA Computer Science 35L: https://web.cs.ucla.edu/classes/fall19/cs35L/assign/assign3.html * NEWS: Mention the fix. Also,

bug#37702: Suggestion for 'df' utility

On 10/14/19 1:01 AM, Kamil Dudka wrote: This is not an excuse to introduce new problems. I'm not looking for an "excuse". df (through no fault of its own) has evolved into a bad program that needs fixing. Backward compatibility concerns are real and we should take them into account, but they

bug#37702: Suggestion for 'df' utility

On 10/13/19 3:00 PM, Assaf Gordon wrote: I'm not sure if it's easy to find a set of criteria that would work well while having minimal unexpected side effects of hiding entries people in other systems do expect to see. No matter what we do (even if we do nothing), there will be problems. But

bug#37702: Suggestion for 'df' utility

On 10/13/19 2:11 PM, Assaf Gordon wrote: This thread originated by a request to "clean up" the output on newer ubuntu machines which use "snap" packages as /dev/loopN . Let's not turn that into a drastic change It could certainly be multiple sets of patches. But let's face it, df's utility

bug#37702: Suggestion for 'df' utility

On 10/13/19 2:41 AM, Pádraig Brady wrote: I wonder could we key (also) on used==0||available==0. Yes, looking at the sample output I gave earlier, I'd say we could by default drop filesystems where usage is 1% or less. That would solve the problem for my workstation. This is roughly akin to

bug#37702: Suggestion for 'df' utility

On 10/11/19 11:20 AM, Pádraig Brady wrote: if you want to exclude nested file systems like that, you could try:   alias df='df -x squashfs' On my Fedora 30 workstation that option doesn't make any difference. Regardless of whether '-x squashfs' is used, I see this output from 'df':

bug#37696: Compile Coreutils without xattr but i installed

On 10/10/19 11:57 AM, Wei MA wrote: I compile the source code. And when i ran tests/cp/capabiliy.sh, cp preserves attr failed without xattr support . Then i installed xattr. I deleted coreutils and downloaded it again. The problem still exists. I use Ubuntu 18. When i

bug#37650: Fw: Possible bug.

On 10/7/19 9:12 PM, George R Goffe wrote: The intent of the configure directive "--enable-gcc-warnings" that states, "turn on many GCC warnings (for developers; best with GNU make)" is, I guess, to warn developers of situations they need to be aware of. Sorry, it looks like I misunderstood

bug#37650: Fw: Possible bug.

On 10/7/19 2:31 PM, George R Goffe via GNU coreutils Bug Reports wrote: I guess the builds would succeed if it weren't for the "-Werror=cpp" flag. I can try removing this flag if you'd like. Yes, please do that. It's generally not a good idea to build with different flags than you configured

bug#37585: Undefined behavior in nl, print_lineno

:00:00 2001 From: Paul Eggert Date: Thu, 3 Oct 2019 12:35:44 -0700 Subject: [PATCH 1/4] cp: simplify integer overflow checking * src/copy.c (sparse_copy): Use INT_ADD_WRAPV instead of doing overflow checking by hand. --- src/copy.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --gi

bug#37060: bug in date / coreutils

I think that bug was fixed in 2017, and your coreutils version 8.23 predates the fix. I suggest upgrading to the current version (8.31) of coreutils, as 8.23 is pretty old anyway.

bug#36739: [PATCH] maint: fix issues in syntax-check

Thanks, I installed that.

bug#36739: maint: fix issues in syntax-check

Thanks, I installed that.

bug#36887: coreutils-8.31: printf chokes on \u0041

Ulrich Mueller wrote: Except for the surrogates U+D800...U+DFFF, it looks like an arbitrary restriction It's not entirely arbitrary. Because of the restriction, coreutils printf doesn't have to worry about what this command should do: printf '\u0025d\n' 1 2 Does this print a single line

bug#36831: enhance 'directory not empty' message

Assaf Gordon wrote: An explicit error explicitly saying "cannot move", and mention the source and destination, and also "blames" the target directory seems the most user-friendly and least ambiguous. Sure, but that handles only the ENOTEMPTY/EEXIST case. How would you handle the EDQUOT,

bug#36831: enhance 'directory not empty' message

On 7/29/19 1:28 AM, Assaf Gordon wrote: + if (rename_errno == ENOTEMPTY || rename_errno == EEXIST) +{ + error (0, 0, _("cannot move %s to %s: Target directory not empty"), + quoteaf_n (0, src_name), quoteaf_n (1, dst_name)); Although this is an

bug#36718: uniq treats distinct Korean characters equal

uniq just calls strcoll, and if strcoll (A, B) returns 0 then uniq assumes the lines are equal. So my guess is that your problem has something to do with strcoll, not with coreutils per se.

bug#35939: version sort is incorrect with hyphen-minus

Thanks for looking into this. Sorry about my confusion between strverscmp and filevercmp. As this bug report appears to be about filevercmp, glibc is not involved; it's only Gnulib and the utilities using Gnulib's filevercmp module. As I now understand it, Gnulib filevercmp is intended to be

bug#35939: version sort is incorrect with hyphen-minus

GNU sort uses the same algorithm as glibc strverscmp, and this algorithm has changed only once since strverscmp was added to glibc in 1997. The change was made in 2009, to fix this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9913 Has the Debian version-comparison algorithm changed

bug#36291: od --skip-bytes reads everything from the very beginning

ea353844d8642b5533cbc713e0cec46addbf3907 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 19 Jun 2019 18:46:57 -0700 Subject: [PATCH] od: use fseek on non-regular files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Szőts Ákos (Bug

bug#36220: ls -l: maddening mixed left right justifications with numeric ids

:00 2001 From: Paul Eggert Date: Tue, 18 Jun 2019 00:31:43 -0700 Subject: [PATCH] doc: mention ls -l user/group justification * doc/coreutils.texi (What information is listed): Document justification of user and group columns in ls -l output (Bug#36220). --- doc/coreutils.texi | 8 ++-- 1 fi

bug#36220: ls -l: maddening mixed left right justifications with numeric ids

On 6/17/19 8:12 AM, Pádraig Brady wrote: Patch attached to do as described above I prefer the current ("maddening") behavior, as it gives the reader a useful signal that the user is numeric rather than textual. This is particularly important when a user name consists entirely of digits,

bug#35291: [PATCH] split: fix incorrect suffix length computation

Johannes Altmanninger wrote: Does anyone have time to review this? I think it's an evident bug. I can try to improve the clarity of the patch if needed. It's not clarity that needs fixing, it's also correctness. A quick look suggests that the proposed fix can go into an infinite loop due to

bug#35713: /dev/stdin problem in cp on Solaris

jakub.ku...@oracle.com wrote: I tested the patch on both intel and sparc platform and all seems to work without any problem. So I guess this can be closed as solved. Thanks for checking; closing.

bug#36044: shuf -r 1 -i 1-10 segment fault on centos 7

Emmanuel Gelati wrote: rpm -qf /usr/bin/shuf coreutils-8.22-23.el7.x86_64 shuf -r 1 -i 1-10 Segmentation fault That's fixed in the current coreutils (8.31).

bug#36007: double close() of of=file if receiving SIGINT during fdatasync()

rom 2c9f67e21aadbcf455ba8f9467202cc6ae8ad99d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 30 May 2019 13:53:54 -0700 Subject: [PATCH] dd: be more careful about signal handling Problem reported by Hans Henrik Bergan (Bug#36007). * NEWS: Mention this. * src/dd.c (iclose, ifdatasync, ifstat, ifsync): New functions, wh

bug#35713: /dev/stdin problem in cp on Solaris

rom e7461441325a6edca01b6d6b48a73a2445d9803b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 29 May 2019 16:44:52 -0700 Subject: [PATCH] maint: fix version number in NEWS --- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index c9f2eff57..5db95b1c4 100644 --- a/NEWS +++ b/NEWS @@ -

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